Sunday, September 20, 2009

Agile and Fixed Ship Dates

A common impression about agile is that it does not allow games that use it to ship on a fixed schedule. The impression is based on the idea that agile teams don’t plan, but simply iterate with a very short horizon - they just don’t know when the project will end!

Although most games have a ship date, many of these are considered “firm” rather than “fixed”. Firm ship dates are established by publishers to fit portfolio or budget projections. A firm ship date will drive the project, but if it desperately needs another month or so of work to achieve far better results, it won’t be a disaster to slip the date. Fixed ship dates, on the other hand, are critical for the success of some games. Examples of games with fixed ship dates are those that must ship simultaneously with a movie release or games like Madden Football, that must be on shelves by the start of each NFL season. The penalty in lost sales for missing these dates is major.

How is a project with a fixed ship date managed differently from one that is not? Mainly it is the way risk is handled. Risk is uncertainty about what a team is creating and how it is going to build it. For example, if we want to dedicate 20% of our project budget to creating a cooperative online deathmatch mode with AI opponents for our game, a few of the uncertainties might be:
  • Will the AI work online?
  • Is 20% of the budget budget enough to create a fun and complete experience?
  • Will problems in other areas delay work or take people away?
The list can go on. Any one of these can threaten the project’s schedule and result in the feature being dropped after almost 20% of the project’s budget has been spent on it.

So how is risk handled? Developers often try to plan and schedule their way out of risk by creating exceedingly detailed plans that attempt to identify the solution to every foreseeable problem. Unfortunately, since the danger lies in what a team does not know, it’s certain that the tasks required to overcome risk will not be identified up front. The best way to handle risk is focus on answering the unknown: creating knowledge.

Creating knowledge and value is important for any project, regardless of the ship date. For projects with fixed ship dates, the prioritization of work to reduce risk is a bit higher. For example, if a movie-based shooter game with a fixed ship date has to decide between shipping six months after the movie’s release or dropping online gameplay, they will be more likely to drop online. A game that is not based on such a license, which instead has a firm ship date, is more likely to be delayed to ensure the feature is included.

So back to the original question: Does agile aid or impede a project’s ability to achieve a fixed ship date? Executed properly, an agile project has significant advantages over other methods. There are two core principles behind this advantage:
  • Prioritizing to create knowledge and reduce risk. Focus on delivering high value and addressing risk early. Fixed ship dates only allow a project’s staff or the scope to vary. Increasing the number of developers on a troubled project usually doesn’t help. Brook’s Law says that “adding manpower to a late software project makes it later”. The same applies to game development. The best option is varying the scope, or feature set, of the project. Identifying the best features that fit within the schedule is critical for the success of a game with a fixed ship date.
  • Not postponing debt. Frequent integration, immediate defect correction and maintaining target performance will prevent late surprises that require rework and delay. When projects with fixed ship dates postpone critical work to post-alpha, they often meet with disastrous results.
The tools for applying these principles are the product backlog and the “definition of done”. The product backlog clearly lays out the order of work to be accomplished. The order is determined by the priority of features on the list. Usually this priority is determined primarily by the value of each feature to the consumer, but for a game with a fixed ship date, the element of schedule risk must often take precedence over value. An example of this is having a team do an early spike to mock up a full level. This would create early knowledge about the level dimensions to better refine the production requirements and resources. Doing this constrains some of the options for emergent gameplay, but for a fixed ship-date it might be necessary to know this information sooner than later.

The “definition of done” is the agreement between the developers and the product owner about how much each feature must achieve before it is considered done for the sprint. If a game must ship on all platforms on the same day as a movie release, a product owner might include “running on all the platforms” as a part of the definition of done earlier in the project than they normally would. While these additional criteria may slow teams down, especially if the platform technology isn’t fully mature, it will accelerate improvements there and create more knowledge about the risks of those platforms earlier.

Agile and long-term planning
Agile methods don’t attempt to plan away uncertainty with large documents, but they also don’t ignore it. They simply tailor the practices to the different level of uncertainty over time. Planning for the short term , such as sprint goals, are done at a far higher level of detail than most. Planning for medium range goals, such as release planning, is less detailed, but receives continual refinement. Long range planning for ship dates, production scheduling, etc are also continually refined and influence short-term planning. For example, an agile plan won’t say “production will start on September 14th” a year in advance. It will refine a range of times over the course of pre-production. The reason is that not only will we gain knowledge about production in pre-production, but the debt itself will actually change! As we discover or even change some of the features of the game, they will alter the amount of time assets will cost to be produced. I have an entire chapter in my book dedicated to long-term project planning, so make sure you buy a copy in early 2010! ;)

Too many times, fixed ship dates result in little innovation or a poor game that must be shipped before it’s been properly polished. Games released with movies have long had a reputation for low quality. This doesn’t need to be the case. By eliminating the waste of dropping features at the 11th hour, after months of work has been dedicated to them, is a good place to start.

Sometimes a fixed ship date is impossible to achieve. A risk-based approach for developing completed features will not work miracles, but it will expose the bad news sooner than later.

1 comment:

Agile Project Management - PM Hut said...

I have to say that I was never involved in games development myself, but what's interesting is game development is a perfect fit for Agile development (constant changes).

This is an excellent article and I would definitely like to publish it on PM Hut. Please contact me through the "Contact Us" form on the PM Hut site if you're OK with this.