One of the keynotes at Agile 2008 was by Alan Cooper on his views on agile. Alan is an agile proponent who has differences with some of the other popular "agilists". Alan a more design and interface driven approach to product development. I feel that Alan's approach to design and construction as necessary stages of product development, surrounding an iterative and incremental core, mesh well with what I have experienced in game development.
When we talk about the waterfall methodology these days, we're usually not talking about the original definition of waterfall defined by Winston Royce in 1970. We're talking about projects that are mostly planned up front (using BDUFs) and designed/optimized/tuned at the end. The issue we have with this is that the documents & schedules created up front are usually wrong and we end up with a poor product or blown schedule and budget.
Conceptually, waterfall looks like this:
The arrows are hand-offs from one stage (or phase) to another. Alan refers to these as not only hand-offs of work, but hand-offs of responsibility. The difference with agile is that responsibility is not handed-off, but continues throughout the project.
The popular opinion is that agile does away with these stages or at least mixes them up every iteration. While this may work for mostly software driven projects that have regular and frequent releases to customers, I don't believe it's ideal for games. A typical console game has one release in 2+ years and has a large content component that must be mass-produced at the end.
In 2002, I read about the Cerny Method for making games. This was a major inspiration for how games should be developed. Later, when reading about agile, I felt that an agile model for development could support the Cerny Method very effectively.
The Cerny Method identifies that the goals of preproduction and production should be entirely different and managed differently. Preproduction should be exploratory and minimally planned up front. The goal of preproduction is to find the fun of the game and produce a few shippable levels which would answer all the major questions of cost and quality for the production phase. The production phase would be entirely planned against the knowns from preproduction and executed to that plan.
What agile does is provide a framework for these stages. Preproduction is iterative and incremental and can be based more on the Scrum practices. Production is mostly incremental and can leverage the lean production practices. Production is less iterative due to the cost of iterating on a large number of produced assets. For example, we don't want to iterate on the jump height of a platform game after we have created a dozen level with hundreds of platforms based on the previous jump height!
I've left concept phase in to represent the idea that we don't start creating incremental value on day one. Concept is purely iterative phases where we develop our "big ideas" about the game before pre-production. A opposed to production, concept is where we are meant to throw out most ideas. Concept could be very short, but the responsibility of the designers in concept does not end when the project moves to preproduction.
If we look at the stages with Cooper and Cerny in mind, the responsibility for the concept of the game continues throughout the entire project. This doesn't mean that the concept will iterate throughout the project, but that there will be collaboration and overlap between the the groups. It also means that the boundaries are a bit fuzzy. The same goes for preproduction. We're not going to finish pre-production on Tuesday and start production Wednesday on all assets. We're also going to encourage refinement and incremental improvements during production.
In the next part, we'll look at how the tools and techniques differ for each of the three stages.