At the University of Advancing Technology, we have been transitioning our student game projects from using traditional waterfall project planning techniques to using agile methodologies.

Waterfall

Waterfall is the way that most projects were run in the earlier days of the game and software industries. Waterfall is a sequential “relay-race” model of development broken into stages and usually charted out on a Gantt chart. Most project management courses teach waterfall instead of agile project management.

I’ve written previously that waterfall is preferable to scrum in a school environment because it plans everything out in advance and gives the students much needed structure and predictable task assignments each week. It was an understandable mistake – almost everything about how education is structured is a waterfall.

Unfortunately, I have since learned that I have fallen for a myth. Detailed documentation and planning is deceptive. It leads us to believe that we know more about the game we’re making than we really know. Mark Cerny gave an excellent presentation on his development method at D.I.C.E. in 2002 that covers this (and other) myths.

The last few times we’ve worked on projects, we’ve actually used waterfall with scrum jargon. We’ve still started with large design documents at the beginning of our projects and we

Agile

The principles of agile software development are much better suited to creative pursuits than waterfall. Waterfall assumes that everything about the game is known at the beginning of the project, but that’s actually when the least amount is known about the game.

The first several sprints of development are likely to be focused entirely on creating knowledge. This is a different way of doing pre-production than you probably first learned. Instead of writing comprehensive documentation and then trying to execute that plan, we conduct small inexpensive experiments during pre-production to discover how much developing the full game will cost and what makes the game we want to make fun. The fun of a game can’t be determined by reading a design document.

We can’t know if the game is fun until we put a controller in our hands and try it. By doing rapid prototypes, we can determine what makes our game fun and throw out the experiments that don’t make the game fun. This requires short development cycles, frequent builds, and frequent play testing.

Scrum

Scrum is an agile development method that has actually been around since 1990 but hasn’t caught on in the game industry until relatively recently.

There are a lot of practices and meetings that are specific to Scrum, but in this article I want to focus primarily on the sprint.

Sprint

A sprint is a two-week to four-week iteration. Each sprint begins with two meetings: a sprint prioritization meeting and a sprint planning meeting. Shorter sprints are more common in pre-production and longer sprints are more common in production.

At the sprint prioritization meeting, the team meets to review the high priority items on the product backlog and commits to a sprint goal. The team doesn’t commit to any work during this meeting, but they break down approximately two sprints worth of prioritized features into user stories and tasks.

At the sprint planning meeting, the team pulls features and tickets that support the sprint goal from the product backlog into the sprint backlog. At the start of the meeting, the ScrumMaster helps the team identify their constraints for the sprint. The team then begins pulling in features and tasks that meet this goal without violating the constraints. The sprint backlog shouldn’t be filled to the very last hour – there will be testing and bug fixing that will need to be done during every sprint and we’d either always be in crunch or always putting bug fixes off until later if we didn’t leave room for them each sprint. Every sprint should create a vertical slice that shows a complete build including debugging and optimization. Testing and fixing bugs should happen now rather than being put off until later.

Every day of development during a sprint begins with the daily scrum. At the daily scrum, the development team has 15 minutes to perform a stand up meeting to say what they did since the last day of work, what they plan to do today, and what impediments are slowing down their development. This meeting isn’t for solving the problems – it’s for making them visible to everyone on the team. Solving these problems will take place during the rest of the work day.

At the end of each sprint is a sprint review. This is what we typically refer to as a build review in the production classes, but we haven’t run them as actual sprint reviews. This meeting begins with an explanation of the sprint goal and a summary of the sprint’s results. Any features or tasks that did not get completed are discussed. At the sprint review, the development team and the stakeholders (i.e. your instructors) come together to play the game and discuss the work accomplished. During this meeting, the product owner accepts or rejects the results of different features the team worked on. If a result is rejected, it may end up back in the product backlog or it may end up cut from the project entirely.

It’s important that everyone on the team plays the game at the sprint review meeting and makes their opinion of the game’s progress heard. Comments and discussions about the direction the game is moving in during the sprint review are an important part of the game’s design process. Rather than everything being planned out at the beginning of the project, the game’s design emerges from the results of these iterative builds. If a feature isn’t working out, then it should probably be cut from the game even if the team invested a lot of time into it.

The final meeting of the sprint is the sprint retrospective. This is similar to the daily scrum but it is focused on the team rather than the individual. The team answers three questions during the sprint retrospective:

The sprint retrospective meeting for our student projects shouldn’t take longer than 30 minutes to complete. This is another point in the process where the team members can make their voices heard and offer feedback to help accelerate the development of the game.

I hope this helped you learn a bit about transitioning from traditional waterfall to agile development. I’ll be writing a few more articles about this topic and the transition our student teams are going through.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-Wesley.