Saturday, May 07, 2005

How Agile should production be?

It's been a while since the last post. Rather than little happening in the AGD arena, there's been so much happening that I haven't had time to post.

Although the dividing line isn't hard cut, a game development project can be divided into two phases with very different characteristics. These phases are pre-production and production. Much discussion has recently occurred on some Agile lists about the unique requirements of game development. The question is "How Agile can we be during production?".

Mark Cerny's Method presentations and articles describe a great method of an incremental and iterative pre-production phase followed by a more classical (higly planned) production phase.

Cerny's Method is an answer to the problem that "you can't be completely Agile in production". E.g. you should define "character height" at the start of production, but you definitely need to know the best character height by the time you enter production and start making levels that depend on it. You shouldn't iterate on character height and all the other values that levels are dependent on after you start making the levels.

Cerny's Method also promotes heavier documentation and planning for the production phase. As you can imagine, such an approach for production doesn't sit well with some of the Agile methodologists out there. I don't see that there is a conflict. Agile is an answer to uncertainty in requirements, tech and resources.

Preproduction is the Agile phase that tries to remove uncertainty from technology and create agreement in requirements so that we can enter production with good game-play. The idea that this chart demonstrates is that the level of chaos guides the process chosen. High complexity&uncertainty drive the need for Agile methods. However pre-production removes technical uncertainty and creates requirement agreement. After pre-production you can choose a different method if it's better.

If you still have technical uncertainty and lack of requirements agreement, you have no reason to be in production (other than trying to get paid for a publisher milestone ;)

The "Simple" area of the graph is actually the area where more detailed planning works well. Write the big script and level design documents. Create the complex Gantt charts. Schedule the details. Some Agile practices still work well. Pair work, daily meetings, burndown charts are all still valuable.

This approach potentially answers some of the uncertainty of doing long-term planning. I'll have a number of future posts addressing this.