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?
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 “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.