Search

Sunday, April 08, 2007

Prototypes

Thoughts on the best way to prototype using agile practices.

Pre-Production & Production


One of the major differences with using agile for game development is the separation of activities during pre-production and production. In the past I have shown this using a version of Ralph Stacey's Agreement and Certainty Matrix:


This argued for more iterative and exploratory development during preproduction. One of the goals of preproduction would be to gain certainty of the game's technology and come to agreement on the requirements for all production assets. This would likely be done by creating a number of final quality levels and characters, for example, that would demonstrate the scope of the full game.

Once in the "simple" area of certainty and agreement, you can apply production methodologies (some prefer "lean production", others more traditional waterfall like methods) to complete the set of assets to ship the game. If you are using Scrum, then you might change some of the practices in production in the following way:
  • More is scheduled and preplanned. Less planning occurs in Sprint planning.
    • Smaller backlog, bigger Gantt charts
  • Sprints and Daily Scrums address support for the production crew.

Where do Prototypes Fit In?

When you are working on new genre, engine or platform, you're actually in the "anarchy" area. This area is so fluid and uncertain in nature that the standard Scrum practices need tweaking here as they do in the "simple" area.

Prototypes of what you want to do in a new genre, engine or platform environment would live in the state of "anarchy". The main value of prototype iterations is knowledge, so prototype efforts differ from pre-production because you're more likely to throw away what you've tried during the last iteration and try something else.

Scrumming for Prototypes

So how should the Scrum practices change for prototypes? There are two issues that need to be addressed.

The first issue is that even trying to plan for a two week Sprint cannot be carried out with a great deal of certainty. When you can't do that, you can't make a commitment to a well defined Sprint backlog. The team needs to be able to commit to take ownership.

The other issue is focusing on building knowledge through focused discovery. We don't want the team going off hellbent on some open-ended, ill defined goal that could take up too much time.

The answer to this is use more spikes. A spike is a time boxed experiment which is meant to produce knowledge. This knowledge is used to improve technical certainty or requirements agreement.

Spikes usually refer to tasks which produce knowledge for user stories, but in prototypes we use them to refer more to stories themselves or even the entire Sprint.

So getting back the Scrum practices our team has tried a few things that work during prototypes:
  • More fuzzy stories for the Sprint
    • More exploratory
    • Conditions of Satisfaction that are more subjective (e.g. is it fun?)
    • Can be met early in the Sprint, with room left for continual improvement at the back end of the Sprint (iteration within the iteration).
  • Full team ownership
    • The product owner for the feature is on the team doing work and the entire team is creating new ideas (the fate of the PO and team are shared).
  • Larger time-boxed tasks
    • e.g. "iterate with game designers for four days" (you have four days to make it fun).
  • Daily Scrum is different
    • We start by playing the prototype (let's see where we are at).
    • New tasks introduced (inspect and adapt)
      • Time-boxed work is broken down (we get specific when we have the knowledge).
  • Eliminating the burn-down chart
    • When almost everything is time-boxed, what's the point?
These practices have resulted in very rapid progress which is very quick to exploit new discoveries when even two weeks is too long to wait.

Hey! That's not Scrum Anymore!

Yeah it is. See my last entry.