"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.

Comments on