In Part One, I described Alan Cooper's model on how agile fits in with his Goal Driven Design process. It made a lot of sense to me and it bears examining if it can be applied to game development.
As discussed, Cooper doesn't shy away from applying phases to product development...something that many agilists do. However his phases are more integrated and overlap their responsibilities throughout the entire project. So rather than calling them phases, he refers to them as "stages".
Comparing this to games, we typically have two distinct "stages" that be identified in game development: preproduction and production. I added the concept stage in part one since games do not start iterating from a blank slate on day one.
To better apply the Cooper design principles, I'd now like to divide up the pre-production stage into two stages: design and engineering. These are not phases divided by time. Both are intertwined, but they are answering two different questions. Design is focused on "what" we are building. Engineering is focused on "how" we are going to build it. This would include the tools as well as the engine. They are really both design stages, but the goals of what they are designing are a bit different, so I'll separate them here.
Here are the four stages we are going to talk about:
We ask questions of the first three stages and make a statement at the production stage:
The stages that ask questions seek correctness. They want the right answers. In the production phase, we seek to maximize efficiency while we are building. We know the answers from the previous stage. Entering production without these answers is one of the most common reasons for cost and schedule overrun.
The "toolsets" for each stage are different. In the concept stage we use our intuition to determine which path to take. In the design stage, we're focusing on player and stakeholder needs. The engineering stage focuses on how these ideas are going to be realized and if it's possible to produce with the resources we have . The production phase focuses on efficiency; how can be build things faster, better and more inexpensively.
There are three different states of mind that for the four stages. The two middle stages are where collaboration occurs among mixed discipline teams. The concept stage is more solitary. It's driven by vision and insight. Consider visionaries such as Miyamoto. Their major contribution comes from their vision and concept of game ideas. You can't take a group of non-Miyamoto (lesser) game designers and expect them to scale their vision to his level.
The production phase is not as collaborative either, especially in cases where we are trying to outsource production assets. It's more about the flow of productive work and improving the flow. This does require some collaboration, but it's not the same. We shouldn't stop to discuss and change the goals with the customer at this point. Changing genres when half your levels are produced is a bad thing.
Finally, let's look at the procedural approaches we use in each stage. In the concept stage, it's pure iteration. New ideas are tried and old ones are discarded. We have total freedom to explore in any direction necessary. Insights are not incremental.
The design and engineering stages are iterative and incremental. We increment towards production through time-boxed iterations that improve value toward customer value (humans) and the means to provide it (technology).
The production phases is incremental. We are not iterating on things we discovered in preproduction. We're mass producing the assets and finding ways to incrementally improve how we create assets.
Where does agile fit in?
The two center stages are the agile stages. This is where fully collaborative cross-discipline teamwork takes place to push the product forward and achieve the best results.
The other stages Cooper refers to as the "fragile stages". The concept stage is "magical" and unpredictable. It's hard to know when it is successful. You can't create a large team do it faster. The production state is fragile because of its size, length of time and potential for waste.
However with the production stage, we can apply Lean principles which are largely derived from product manufacturing (e.g. Toyota). These focus on eliminating waste and focusing on where value is added. It focused on a constant set of incremental improvements that do support collaborative work but also work standards for larger groups of people.
I feel this model has some value. Over the past five years, I've considered & discussed a couple of the issues with adopting agile for video game development:
- Game development is a combination of product development (preproduction) and manufacturing (production). Applying the same Scrum practices to both is not ideal.
- Our one release model for large scale games isn't an ideal fit with the regular release model of other products where agile is more commonly applied. We can't get proper customer feedback for our iterations. Focus/play testing is not enough. We need visionaries.
Stages seem a good fit to describe what we do on an agile game project. Cooper's breakdown adds value in discussing the practices, tools and goals of each stage. Stages also address the problems of phases by not handing off responsibility between them.
Scrum is a good fit for the design/engineering stages. Based on production experiences, Lean is an ideal process for the production stage. Many studios do the concept stage, but as Cooper says: "it's magical". How did Apple create the concept for the iPod? What practices do we create for the concept stage that allows many ideas to be inspired and filtered? How do we know when we are done?
Cooper's model is a step forward is defining that.