Back in the early nineties, I had the privilege of working at a game studio occasionally visited by Shigeru Miyamoto. Miyamoto arrived every few months to play the game we were developing for Nintendo. He didn't care about a schedule or budget. He only wished to know if we had "found the fun" yet.
Finding the fun is one of the most significant areas of uncertainty in a new game's development. Shipping a game that isn't fun is always a considerable risk.
Risk is the impact on your plan caused by uncertainty. Uncertainty is also an essential part of game development. Think of all the great games you've ever played. Did many of them do something that you'd never seen before? For every successful game that does something new, there are many more that embraced uncertainty and failed. This was key to Miyamoto's approach: find the fun or fail fast.
Many other stakeholders attempt to avoid risk by coming up with ways to minimize uncertainty. Often this is done through:
- Detailed design documents that try to answer every design question upfront in an attempt to reduce scope uncertainty.
- Comprehensive schedules that identify work to be done, in an effort to minimize schedule and cost uncertainty.
A detailed set of practices for embracing risk is too long to describe here, but is detailed in the next edition of "Agile Game Development."
Here is an overall view of how risk can be managed:
The steps are:
- Identify risk. There are a number of activities that can identify a broad set of risks based on what you know is uncertain and what might surprise you.
- Classify areas of uncertainty that we can plan for and other areas we can't. Knowing which can help us figure out how to handle them. For example, you can plan to port to a new platform, but can't really know if the game is fun until it is.
- Prioritize. Risks have different levels of likelihood and impact on our game. We need to sort those out and prioritize which we deal with first.
- Find a root cause. Most risks have root causes, like purchasing that piece of middleware that was "supposed to be ported" by a specific date. By identifying root causes, we can come up with better ways of avoiding the impact of that risk, if it comes true.
- Identify a trigger condition. What is the earliest we can know whether a risk has materialized? In the case of the undercooked middleware, we might have a trigger that says, "it fails to do so-and-so on our target by this date." Triggers should be testable and binary.
- Create a mitigation strategy. What are you going to do if the risk triggers? Are you going to buy the source code license to the middleware and port it yourself? Having a plan in place helps sell this approach and resolve risks.
- Evaluate your triggers regularly. Make this a part of backlog refinement. If a risk is triggered, it'll probably change your next sprint, and the backlog refinement is where that is best handled.
One of the best tips I received from a former boss of mine was, "don't come to me with problems. Come to me with solutions".
Sometimes the hardest thing to do is admit that you "don't know" to your boss or publisher. Going to them with a list of risks is even harder. That's why the mitigation strategy above described above is valuable. It has a solution associated with every prioritized risk. It might take a development cycle to prove the value, but I've found that with most well-developed risk management lists, at least 20% of them come true. Because those risks are triggered with enough time to solve them, the value becomes apparent.
A publisher once accused my risk management list as a CYA ("Cover Your Ass") document. I agreed with him that it was partly that, but added that it covered his as well since everyone has a boss that they answer to.
Where to Start
- Brainstorm risk. A favorite practice of mine is called a "PreMortem" (see the GearUp book). Gather all potential risks and prioritize them through the mapping practice described above.
- Come up with triggers and mitigation plans for the higher priority risks
- Set aside a regular time to identify new threats, evaluate the triggers, and retire any risks that have been mitigated or have otherwise been resolved.
- Document and share the risk mitigation plan with your stakeholders. Involve them in the regular evaluations.
- Reduce your existing planning practices to move away from "documenting away uncertainty." This is a "cultural security blanket" that may take a few development cycles to wean stakeholders off of.
- The second edition of "Agile Game Development". As mentioned, there will be a lot more about this approach in the next edition of the book, coming out in summer.
- Gear Up, 2nd edition. Over 100 practices for team, game, and development improvements you can immediately implement. On Amazon and LeanPub.
- Me. I teach courses on improving game development, including integrating debt management into your existing process. Visit www.ClintonKeith.com and contact me.