[If you've discovered the value of Scrum agile development while making your game, expert Clinton Keith outlines Lean and Kanban, two ways you can be agile during all phases of the game development process.]

Many games teams that adopt Scrum quickly discover its value. The improved velocity of introducing value, or fun, to the game at a regular iterative pace shows where the project is heading and allows the team and customers to react by improving the game frequently. However teams find that when they enter production, the value of Scrum diminishes.

Many teams abandon some Scrum practices late in a project's life cycle and return to more traditional waterfall practices. They call this approach "a blend of Scrum and Waterfall". This article explains the reasoning behind this and introduces the concepts of Lean Production and Kanban as an alternative to adopting waterfall practices.

Lean and Kanban can answer the issues with Scrum that many teams face, but they don't require the team to abandon agile methods. These practices are based on real world production experiences which showed a 56% improvement in the cost of level production.

In most agile projects outside the game industry, there are no phases of development. There are no concept phases, pre-production phases or production phases. These projects start with releases, and every release delivers a version of the product to customers. Think of applications like Firefox that release a new version every month or so. Most games have a single release that requires years to achieve.

Eliminating phases is a big benefit of agile; waterfall phases such as the 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 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. Sixty-dollar games must deliver eight to 12 hours of gameplay. This represents the major portion of the cost of development and occurs after the gameplay mechanic is discovered. This requires a pre-production phase to discover fun and a production phase to mass-produce the assets for the eight to 12 hour experience.

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 during a concept phase at the start of a project. Developers are then unable to stray too far from this vision throughout the project.

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 during production.

For example, consider a team in production on a platformer genre game. Platformer games (such as Nintendo's Mario series) challenge the player to develop skills to navigate treacherous environments. The production 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.

Sprints and Production

Asset creation is deterministic and sequential work that does not fit the Sprint iteration cycle very well. If we think about production as a factory assembly line, then the two to four week iteration cycle doesn't make as much sense. Factories don't empty the assembly line every four weeks and determine what to build next.

Assembly lines have things rolling off much more frequently and require incremental improvements instantaneously. The rate that completed assets roll off the line becomes the new heartbeat of the production team.