Scrumming It

“Making games is hard.” – Microsoft XNA Product Unit Manager Boyd Multerer

It’s true: making games is hard.

When it comes to finding an effective management paradigm, the game industry is still young. That youth is a double-edged sword: Game companies appear (and disappear) so rapidly that new methodologies can be fully implemented and tested in a short time-frame, leading to faster innovation and open-minded approach, while simultaneously insisting rebelliously that no previously described method from predecessor industries in either entertainment or software science could fully apply to game development. They just don’t understand us, man!

To some extent this is true. Game development, especially at the AAA level, mixes some of the most difficult elements of software design and development with the uncertainty and volatile creativity that drives every other entertainment business. It doesn’t help that games did not gradually or gracefully develop, they exploded.

We’re Gonna Need a Bigger Boat
In the earliest days of game development, the average team was 2.5 people, and most of the early games for the Atari 2600 were one-man bands. Some of the earliest mid-’80s hits by familiar names such as Namco boasted development teams of four or five.

By 1988, teams expanded; Sierra’s King’s Quest IV had 17 names on its credits, many appearing more than once. A transition in a single decade from teams of five to teams of 20 doesn’t seem like much, with single developers still covering multiple bases, but it was the first critical step in differentiating between old-style development – work designers like Howard Scott Warshaw called “authorship” – and modern development, where people management and communication became essential not just to the success of a game, but to its basic completion.

By 1995, team sizes had doubled again; Descent II lists a core team of 35, not counting QA or voice actors. Deus Ex, in 2002, saw team size spike up to over 80, and current team sizes for AAA titles on the PS3 and Xbox 360 can easily reach a terrifying 200 in developer population. At these levels, and even at the earlier thresholds, development becomes a new game entirely, where some of the same principles apply, but the sheer economics are entirely different. Where a team of five can get away with design-on-the-fly and rapid creativity iterations, teams of 40 require rigorous planning and entire support staffs employed strictly for the purpose of organizing talent. And while conscientious game managers – most of whom came directly from development and not out of any particular management training background – did their best to study management techniques and come up to speed, the legacy of the one-man band carried over into team sizes where the rules were entirely different.

These challenges, and the death marches that frequently resulted, had many developers thinking there had to be a better way, a way more flexible and responsive; a way that could stabilize production without sacrificing maneuverability. A way more Agile.

Enter Scrum
In 2004, at the Game Developers Conference, the discussion toward new game-specific management tools had already begun. Wolfgang Hamann of Koolhaus Games presented a new methodology he called critical stage analysis, in a presentation titled “Goodbye Postmortems, Hello Critical Stage Analysis.” The basic principle was an evolution of the postmortem process, long a tradition in the aftermath of game projects.

The problem, Hamann said, was by the time the postmortem hit, the place where it could have been maximally useful – during the project it’s discussing – is already gone, its team most likely moved on, even fractured or dissipated depending upon the project and the developer. Why not, he asked, actually try this during the development cycle?

What he found through his process, which emphasized feedback from the development team itself – even anonymous feedback, if necessary to break the ice – was that not only did it result in more efficient process and better results, but its impact on team morale and company morale was huge. Developers were taking ownership not just for what they did, but how they did it.

CSA is itself a sort of common sense evolution with the Agile methodologies conceived in mainstream software development, and it is employed by numerous teams across many studios. But its basic principles of morale-building, communication, collaborative management and flexibility of production methodology also exist at the core of the new method that has been sweeping the industry over the past year: Scrum.

Named for a rugby formation, Scrum, the very sound of which calls up a kind of goofy camaraderie and joie de vivre, started as an idea presented at management conferences in the mid-’80s. Since then it has taken hold, and Ken Schwaber, one of its core founders, now runs a consulting company, Advanced Development Methods, focused solely on instructing in Scrum practices. Often paired with other methodologies, Scrum focuses on the lightweight application of team-driven management and iterative development – meaning evaluating your process and changing your tactics if one method isn’t working.

Two years ago, the word “scrum” started to buzz in game management circles, a buzz that in the interim has turned into a roar. Developers in producer positions are becoming Certified Scrum Masters (to the hefty tune of $1,200), a title that is now starting to show up in job headers at companies like BioWare.

The industry focus point for the effectiveness of Scrum was the team at High Moon Studios. The two Scrum gurus were the studio’s CTO, Clinton Keith, and then-Chief Architect Noel Llopis. Keith joined High Moon midway through its debut title’s production, Darkwatch, and the studio was having a rough time. The introduction of Agile methods brought the game to ship, and High Moon has been a case study for Agile and Scrum ever since.

We Can Do It
Scrum follows the Agile manifesto and emphasizes responsibility and ownership by individual team members. The details come out in Ken Schwaber’s book on Scrum, but on a basic level, Keith says, Scrum emphasizes: self-management, iterative development (meaning each short phase of development, called a “sprint,” is analyzed after it is completed) and engineering tools that facilitate this flexible process. Scrum also emphasizes stability of the product and what Keith calls “stop-the-line” culture and tools.

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.