Phases in an agile game project?

In most agile projects outside the game industry there are no phases of development. Projects start with releases and every release delivers a version of the product to customers. Think of applications like Firefox. There is a new release of the browser on a regular basis.

Eliminating phases is a big benefit of agile; phases such as “a testing phase” force the critical activity of testing to be postponed to the end of the project where fixing bugs is the most costly. “Planning phases” at the start of projects attempt to create detailed knowledge about what features will be fun and the work associated in creating them. Unfortunately the best knowledge comes from execution which is why highly detailed pre-planning fails.

For many games however, there is often still a need to have phases within the game. There are two major reasons for this:

• There is a minimum bar to the content being delivered regardless of the quality. $60 games must deliver 8 to 12 hours of gameplay. This represents the major portion of the cost of development and occurs after the gameplay mechanic is discovered.
• Publishers have a portfolio driven market model. This constrains the goals of the games that they fund. In order to gain publisher approval (which includes marketing and often franchise/IP owner approval), developers need to create a detailed concept treatment at the start of a project.

The first reason compels us to separate pre-production and production activities into separate phases. Pre-production allows more freedom to iterate on ideas and explore possibilities. During production, we are creating thousands of assets that depend on what we have discovered during pre-production. These assets create a cost barrier to change. For example, consider a team in production on a platformer genre game. Platformer games challenge the player to develop skills to navigate treacherous environments (such as Nintendo’s Mario series). The team will create hundreds of assets that depend on character movement metrics such as “how high the character can jump” or “the minimum height that the player can crawl under”. Production assets depend on these metrics.

If these metrics are changed in the midst of production, it can wreak havoc. For example, if a designer changes the jump height of the character, hundreds of ledges or barriers would have to be changed. This can create a great deal of wasted effort during the most expensive phase of development. It’s critical to discover and lock those metrics during pre-production.

This doesn’t mean that we can’t be agile during production. How we are agile does change. Instead of using an iterative and incremental process such as scrum, a more incremental process such as Lean is more applicable. More later on Lean....