[Industry veteran Miller looks at the leading Agile methodology for game development, suggesting the ten top pitfalls - and ways to overcome them - for those using Scrum to manage a video game project.]

There has been some hype about using Scrum for game development, including presentations at Game Developers Conference. There are books and many internet resources that describe Scrum, and this article assumes the reader is familiar with Scrum and Agile methodologies for product development.

Scrum can be a beneficial for some kinds of software projects. There are, however some pitfalls that are easy to run into when employing Scrum to manage a video game project.

Some hazards can occur because the importance of well-established, existing best practices is ignored. There can be consequences when Scrum is used as a replacement for existing best practices. Here are 10 pitfalls that were experienced on a recent project while employing Scrum methodology.

10. A Game Design Document (GDD) isn't needed anymore because the backlog spreadsheet replaces it.

While maintaining both a GDD and a backlog, the team is drowning in an overwhelming amount of paperwork every day. The ScrumMaster or Producer responsible for the backlog ends up spending less time writing or maintaining the GDD and as a result there is a lack of product design specification. Team members are left guessing what code to write or what components or assets need to be constructed in order to make the game that is going to ship.

Lesson Learned: Backlog spreadsheets are not a replacement for printer-friendly game design documentation. Team collaboration is not a substitute for someone putting the product design specification in writing.

It's hard to see up front that the lack of printer friendliness of the backlog spreadsheet is actually going to inhibit everyone's ability to communicate. Before backlog spreadsheets, it was possible to print out the GDD and bring it to the team meeting and scribble notes on it. It was also easier to provide feedback in writing. By printing out the GDD and bringing it to the meeting, you could talk about the design and refer to it without sitting at a computer.

While using a backlog spreadsheet as a replacement for design documentation, one issue team members realized is that after a meeting they walk back to their desks, start to concentrate on tasks and have forgotten seven of the eight points that were discussed during the meeting. The solution proposed was that everyone needs a laptop to bring to the team meeting so team members can type into the spreadsheet simultaneously. Imagine the team meeting is like a LAN party and everyone can see each others' cursors on their own view of the spreadsheet.

Unfortunately spreadsheets do not have a multiplayer mode, and the company is not going to buy everyone a laptop just for Scrum methodology. The obvious solution is everyone brings a notepad and pen to the meeting and takes their own notes, but why didn't the designer put the design in writing in the first place? Why is the design done on the fly and everyone has to take notes like an executive dictating a letter to multiple secretaries at a time?

In multiple team project review meetings the ScrumMaster has remarked "We need more communication on our team." All the developers then roll their eyes and ask "where is the design specification in writing? Wasn't the printer-friendly GDD a form of communication?"

Best Practice: Before there was Scrum, writing the GDD in Microsoft Word and putting it in source control was a best practice. A wiki as the GDD is perhaps better than a Word document in source control.