Rather than being a top-down "manager," a Scrum master's primary function is to remove obstacles from the team. In a daily "scrum" (or "scrum meeting"), the team gathers - usually standing in front of whiteboards or posters that chart the product's development across the sprint - and each team member has two minutes to state A) what he worked on yesterday; B) what he's working on today; c) what, if anything, is blocking his production. The Scrum master then works to remove any blockages in the system.

Because management with Scrum is driven from the individual team member up, with the manager almost in a service role rather than an authoritarian one, the result is, ideally, process ownership and the creation of process by the actual people who will be using it.

Not a Silver Bullet
Early skepticism toward Agile methods came down to a fundamental question: Sure, Agile might be great for morale and a smooth production process, but without the pressure inherent in Waterfall development, can you make a hit title? Many developers believe the heat of a deadline results in catalyzation of "fun factor," and any emphasis on team morale over end product is inherently dangerous. Frequently, individual developers will mistrust anything that will result in long meetings - and, particularly in the early phases of a project developed with "full" Scrum method, there are a lot of long meetings.

Other challenges to the Agile methodology come from a practicality standpoint: Much of the pain that comes out of the development process occurs in the communication between publisher, licensor and developer, which can result in massive changes to a product dangerously far along in its development cycle. Which is to say, making games is hard.

Keith remains adamant that Scrum, like any other production methodology, is not a silver bullet for product development of any kind. He maintains "there is no 'right way' to make a game." In a recent blog post, he cites the success of previous projects - not using Agile - in his experience being due to traditional factors: quality of the team, experience of the team, effective marketing and effective technology. Intense scrutiny of High Moon's specific success with Agile, Keith says, is the wrong way to approach analyzing the effectiveness of the methodology.


Neither Scrum nor any new production methodology provides a complete recipe for a successful game; there is no such thing. Making games is hard. What these new methodologies do, and perhaps more importantly, what they indicate, is responsiveness to the development process, and working smart as well as working hard. Ultimately, what remains fascinating about Scrum is its simplicity and common-sense approach as a toolbox for managers, the same way compilers and libraries are tools for programmers. Scrum, in addition to being its own method, in recent years has become the gold standard for attentive process. That there is great interest in this new batch of tools, and great interest in advancing process in the way we advance technology, may be a sign we're growing up.

Erin Hoffman is a professional game designer, freelance writer, and hobbyist troublemaker. She moderates Gamewatch.org and fights crime on the streets by night.

Comments on