Sunday, August 20, 2006

Delaying Commitment

There are a number of ongoing areas of confusion about Agile planning and execution. Resolving this confusion is important to avoiding major areas of risk and properly iterating on the game an not a plan.

Some of the questions raised are:

  • I know the Wii [or insert big risk here] is a major risk. Why not plan for it and write stories off the plan?
  • We have a game mechanic that might take a month or two to build. Why not plan it out and write stories off the plan?

There are things you plan for; there are others you don’t. How do customers decide that we need to add Wii stories a year before we ship or that we want to take two-week baby steps on a game mechanic?

It’s confusing to the team as well. It’s an inconsistency unless the underlying principles are understood. One of those principles is:

- Decide as late as possible: keep your options open as long as practical but no longer. In other words: “Delay Commitment”.

The customer and the team know that the Wii SKU is a major unknown and it’s of high value. It can’t be fit into a single increment. We have a fixed ship date, which means the scope is the main variable. I suspect that if we delay our commitment to it much longer we may end up with our backs against the wall (schedule). So I would like to learn more about what we’re in for. I would like some goals for the next release to include having the game running on the Wii (a shippable demo) and knowing more about the work that needs to be done to ship the final version.

For the game mechanic, I’m not so concerned about thinking it through and discussing it beyond the iteration time frame. We do that for releases. Where it breaks down is when we commit to the plan from the start. Commitment then takes the form of executing on the components of the plan in parallel to save time when some of those components are dependent on one another. The symptom of what you see when this occurs is what our Chief Design Officer, Chris Ulm, calls “Parts on the Garage Floor”. We’ll see these parts lying around in an iteration review: components of a future working mechanic that add no apparent value to the game. An example of this would be a HUD element that someone thinks the mechanic might need when it gets fully implemented (don’t get me started on the topic of “why HUD elements are admissions of defeat”). It’s an extra part on the floor that we are not sure of. If you put yourself in the position of the consumer looking at it every two weeks and not the developer with a plan in your hear it becomes more apparent. The effort that we put into making that before we know we need it in a working game might have been wasted.

Delaying commitment on a HUD element is good when the mechanic doesn’t need it yet. Delaying commitment on the Wii to the point where the schedule will decide for us is not good.

No comments: