DDP Best Practices
There are several additional practices that can help you get the most out of discovery-driven planning:
- Test all assumptions: You should never leave any assumptions untested. Ensure that when you build your Checkpoint list, you end up testing every single assumption in your plan. The most important assumptions (those with the greatest sensitivity, i.e. the greatest potential effect on profits) should be tested at multiple Checkpoints, and those Checkpoints should be moved as early in the project as possible.
- 20-by-30 rule: It's a good idea to stay within no more than 20 Checkpoints and 30 assumptions. In practice, you're unlikely to ever re-plan if the DDP exercise grows beyond this scope.
- Keeper of Assumptions: It's recommended to nominate one individual as the "keeper of assumptions" tasked with the primary responsibility for updating all of the assumptions at each checkpoint. This should typically be an individual who is not on the critical path and will have enough time to be diligent in checking these assumptions and discussing them thoroughly with the project's planning team as production proceeds.
- Document learning: It is recommended to document what you learn at each Checkpoint and show how and why the ranges of the assumptions you tested at that Checkpoint have (hopefully) narrowed. If at all possible, this should go in a shared wiki or SharePoint folder for the whole team to learn from and discuss.
Conclusions
The game industry is constantly changing, often with breathtaking speed. In an industry that changes so quickly, the greatest danger comes when we stop learning and adapting. One of the key benefits of discovery-driven planning is that it not only encourages but actively enforces learning at the very highest levels of the organization.
Although change is inevitable and not all risks can be managed or even anticipated, we can only benefit from improving our ability to understand, analyze, and manage what risks we can.
Discovery-driven planning is an immensely useful tool for managing uncertainty and inculcating a risk focus into existing organizations. It forces managers to articulate what they don't know so that they can orient the project toward learning the unknowns and reducing overall project risk. It also ensures that the planning process takes the big picture into account, cleanly separates the knowns from the unknowns, and allows the team to learn as much as possible, as quickly as possible, and at the lowest possible cost.
Once again, to download the DDP spreadsheet, please click here.
The author would like to thank Wharton School Professor Ron Pierantozzi for his contributions to this article.
|
Printer-Friendly Version
I'm sure it could be an article in itself, but could you speak to the issues of bridging the gaps between discovery-driven planning and development methodologies over the SDLC? I understand the connection between driving your development cycles with input from the discovery-driven checkpoints, but it seems to me that this is more geared toward agile methodologies than more front-loaded design schemes. Are there any key factors to integrating DDP with specific design methods that we should be aware of?
DDP is really a very broad project planning and business planning framework that can be used for almost *any* kind of planning, regardless the scale or even what industry it's in.
It's much more of a high-level, big-picture, ten-thousand-foot-view type of planning framework, and you would generally use other software development and planning methodologies inside of the DDP plan you create.
You're right that DDP does lend itself more toward agile methodologies. Non-agile methologies like waterfall tend to assume correctness from the outset (from http://en.wikipedia.org/wiki/Systems_development_life-cycle : "Sequential or big-design-up-front (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results").
And we all know that that certainty doesn't really exist in software, much less in game development, where you combine all the unpredictability of software development with the added unpredictability of creatively-rooted projects.
DDP, on the other hand, is basically taking the opposite approach. It says to the planning team: "Start by admitting how much you don't know and how much you can't predict. Then identify all of those parameters as best you can, figure out the boundaries on the uncertainty associated with each one, and use the DDP system to figure out which uncertainties represent real risks and sort them by risk. Then you can gradually corral those risks over time as you go from one Checkpoint to the next and gradually reduce uncertainty by converting your assumptions into knowledge."
The uncertainty can arise either because we're missing some amount of a priori knowledge (say, we might not know a certain parameter in advance, even though the parameter has a definite value -- for example, we might not yet have done the marketing research to figure out cost of acquiring a user on mobile, even though it is a definite dollar figure that many companies know precisely).
Or it could be because it's something that will happen in the future and there's inherent uncertainty involved (say, we hire 10 programmers and expect them to be done in 2 years, but we don't know if they'll actually get it done, if our design changes will push their schedule to 3 years, if our lead coder will have a heart attack, etc, etc).
In either case, DDP can help you get a handle on where the biggest risks are really hiding and help you build a plan to identify them, quantify them, and manage them.
I've always been pretty agnostic about it, but I definitely think Scrum has its limitations.
There's really nothing inherently wrong with it as a day-to-day planning methodology, but it seems really incomplete to me. Scrum tends to be totally focused on the short term, and there's very little focus on long-term planning.
And that just doesn't work.
Even if you don't have a fixed schedule or feature set, or you're building your game under a huge cloud of uncertainty for whatever reason, you HAVE to do long-term planning at least at some level.
I've worked on a few projects that used Scrum and/or ScrumWorks software at some level, but were actually totally ineffective teams because they ended up chasing their tails rebuilding their own games more or less from scratch every six months.
So an artist would come in one morning and say, "Hey, guys, I just had this amazing new creative idea! We gotta do this!" And the team would immediately throw out the last six months' worth of work to focus on this awesome new idea ... which would then be thrown out itself six months later in favor of something else.
Their planning was only looking at the here and now, and no one was looking at the big picture or holding the team accountable for it.
That really drove home for me that for all its benefits, Scrum by itself is no guarantee that all that task tracking necessarily translates into any actual progress toward a goal.
So, bottom line, I think that combining Scrum with DDP could be a good approach, if you were to use DDP for the overall, long-term planning aspect, and then use Scrum (or some good adaptation of Scrum, or another good agile methodology) for the short-term, day-to-day and milestone-to-milestone planning.