Waterfall vs. Scrum

Waterfall development creates a problem for game designers in that no object can be considered complete until all of the dependencies on that object have also been built and moved into the process. For example, a designer may build a level centering around AI which exists solely in documentation. Using the design document as reference, the designer makes a best guess, has it evaluated by seniors, and hands off the level to an artist to begin building the meshes. The designer and his managers know that no one has actually got to experience the character enough to design a level around it, but in order to keep production flowing the designer and level artist will have to assume the AI will work as promised.. But while the work continues, the questions remain.

What if the programmer for the character determines that getting the AI mechanic to work as documented isn't attainable? What if the AI works, but animation can’t get the mechanic to look right? What if the designer responsible for the character realizes that the functionality isn't fun? Answers in the negative to these questions mean lost functionality, lost person-hours, some portion of the development budget wasted, even a psychological outcome such as loss of faith in the project. Whatever the drawback to the development process, it is best summed up in its most likely outcome: Degraded product quality.

Another substantial problem with Waterfall occurs when departments outpace each other, resulting in a "hurry up and wait" situation.  Everyone is going as fast as they can when their piece of the Waterfall is in their lap, then waiting for the next piece when their portion is complete. Imagine an assembly line where the belts moved at variable speeds, sometimes completely stopped, other times moving at a comfortable pace and occasionally blazing. A chronically irregular pace during production has downsides for producers, financial officers and just about everyone involved. For designers it affects their job at a fundamental level. Inconsistent progress can substantially affect the functionality and quality of essentially any features that require different elements to come together.  

For instance, consider a horror mechanic in a game, such as a moment when the player is surprised by a vicious boss encounter. A mechanic such as this relies on nuances for its success, and for a design team to test, evaluate and, as is nearly always needed, reiterate, they need finished art, sound and scripting. It certainly can’t be tested in a black box.

Waterfall will always put designers at a disadvantage, simply because while the breadth of a game is established at the project outset, the depth that makes up the game’s most important dynamics such as camera, tuned control, A.I., etc., "percolate" slowly and begin to take final shape only near the end of the project. In Graphic02 we can see a demonstration of this for a sample project, where mechanics have been handed off to various departments who are working on individual pieces, with the intention of delivering the finished product several months down the line.

	Graphic02: Progress at eight month mark on a sample project using Waterfall.

The scenario is quite typical of a project at eight months. The team has moved out of pre-production and has laid the ground work for all the mechanics and assets outlined in the design document. The fundamental problem occurs in the assumption that all of these mechanics will be delivered and delivered well.

Another way to depict the progression of a Waterfall project is as a curve representing a product’s finished functionality over time, as depicted in Graphic03. Here, the right side of the timeline on the project is the delivery date -submission to a first party, handing over a master to the publisher, etc. It is immovable, the veritable brick wall. As development progresses, the game’s mechanics begin to take final form and function as promised during the critical final phases of the project.

	Graphic03: Finished functionality over time.

What if as the team nears that brick wall, critical components do not function as promised? The inevitabilities are death marching, or cutting features late in the project along with the all the assets and content dependent on those features. The ultimate result is wasted resources, assets and person-hours, and quite likely, degraded product quality.

The most fundamental difference between Scrum and Waterfall is the level of communication Scrum establishes through daily collaboration towards goals approaching in a span of weeks instead of years. In the Waterfall example, our designer was building a level centering around A.I. using documentation and assumptions on how the character might be delivered. Applying Scrum to the same example, the designer works hand-in-hand with members of the team. For instance, the designer declares the goal: “I need AI to behave in a way that lets me easily iterate on its navigation.” The next step is working directly with programmers.

Together, the designers and programmers investigate options, coming to a consensus on what is the best technology to implement to get the desired behavior. Should the programmers run into impediments, the designer is imbedded in the process and able to have direct input on any alternative solution. The approach is not confined to how designers work with programmers. The same pipeline applies to, for instance, a designer iterating on how a character moves with animators, or how a level is laid out with environment artists. The end result is going to be better solutions, with Scrum ensuring that those who need to be part of the process have input.

Scrum presumes that the people creating and implementing the work are going the most knowledgeable on how to get to a goal and where the landmines are on the way there. Who would know more about the animations needed for a character to move than the animator? Who would know more about how the A.I. moves to a position than a programmer?

By simply declaring the spirit and end goal of the design it opens a dialogue between designers and the individuals implementing the feature or level, which in turn lets all parties involved figure out the best method to achieve the goal. Designers aren’t programmers or artists so presuming we know the best path in all methods of technology and art is foolish.  What we can do is determine a short goal and work with the team over a couple of weeks, then review the product and determine if it’s up to snuff. An emphasis on rapid iterations in small pieces benefits the end product and designers immensely.

Through rapid iteration designers are able to watch whole complete mechanics come online in very short order. This lets designers immediately see the status of a mechanic and where the game is heading. For lead designers and project directors, this let’s them get a status check every few weeks on exactly the destination of the project and have a month to month diagnostic on a team’s progress and whether or not they should meet their end goals.

Because a team is delivering entire vertical slices features can be cut without immediate repercussions to previously made content. No dependent features have moved into development which means that scope can be reduced with a clear conscience and without wasted work.

For level designers this also means that their levels can be built around mechanics that are proven and fun in and of themselves. While a designer can return to a level or area at a later time to layer in new functionality as it comes online, the game can ship without them doing so. Moreover if the level is fun with the things the designer has, imagine how it’ll play when the designer get the things he doesn’t have.

It may seem scary to focus on individual mechanics instead of getting everything to bare bones functionally and then letting it percolate. Yet, note that the fundamental mechanics required to ship the game and build levels are the first out of the door, as determined by the product owner. Additional features which add spice to the game but are not critical can be layered in. Building the most important things first instead of receiving them at the very end means that content creators (such as designers) can directly build levels around a specific functionality.

Moreover, attaining functionality central mechanics early means there are no dependencies on mechanics that may need to be cut; scope can always be cut or expanded to suit the customer’s needs. Additionally, product owners and designers can determine what features are working best and then “hammer down” on them, including more content that uses the functionality to showcase it better in the game. [Agile03]
 
Rapid iterations also minimize an increasing trend in the industry: Risk aversion.
With bloated schedules, more investment and factors such as untried technology and hardware, publishers and investors face far more complications with a mentality of “Let’s try it!” to one of “I don’t know about that.” As costs rise for investors moving into the next generation, this is a perfectly reasonable and expected response.

Using Scrum, product owners and publishers can follow risky goals for a several iterations. If unproven features or game concepts don’t pan out, the team can easily re-evaluate and redirect. If those features are a hit out of the park, the team and the product owner can decide to concentrate on those aspects of the game, and even take the game in a completely new direction.

Also, as development time increases, the product can face a changing market. What may have been a fresh idea can rapidly become stale as competing titles beat your project to market. Scrum let’s publishers and designers separate their title from the competition with very little risk involved. If product features need to be changed, or in a worst case scenario a game has to be completely cancelled, the publisher loses two weeks to two months instead of two quarters to two years.

Conclusion

Within Agile methodologies such as Scrum, game designers gain a tremendous number of benefits. Individuals such as project directors and lead designers can see whole complete pieces at regular intervals, and instead of measuring progress by abstracts they can measure it by putting their thumbs on a controller. For level designers, they are able to build levels that focus around existing mechanics. Using Scrum, those mechanics are online and taken to their fullest extent so the levels the designers do create are part of a complete whole, with a better view of how the mechanic is going to look on disk.

One feature of Scrum that benefits everyone in game development, not just designers, is a minimization of “crunches” and “death marches.” Publishers and project leads are able to get diagnostics on the team’s performance every iteration, meaning they can safely predict how a team will perform. Within a methodology like Waterfall where features percolate, any aspect of the game that isn’t up to snuff has to be “crunched on” to ensure the game is shipped.

Most importantly, using Agile methodologies and Scrum puts designers at the table with the individuals implementing features and technology used to power the game. Conversations are initiated, questions are asked, dialogue and cross department problem solving occurs organically. Assumptions that lead to wasted time and effort are checked at the door, and a collaboration can be reached that gets the best game out in the most efficient way possible.

Footnotes

[Press01]Recent article on Firingsquad.com by Jakub Wojnarowicz regarding Nintendo in the next generation. http://firingsquad.com/features/nintendo_revolution/default.asp

[Agile01] A full definition of the guidelines and principals that were defined by the Agile Manifesto founders can be found at Agilemanifesto.org

[Agile02]Noel Llopis, lead R&D architect at High Moon recently wrote a feature for Game Developer on a “Day in the life.” In that article he describes how a Scrum team meeting is organized and how individuals deal with tasks. It can be found on his blog at:  http://www.gamesfromwithin.com/articles/0602/000104.html

[Agile03]Additional information on Agile development for games, particularly via Scrum, can be found at http://www.Agilegamedevelopment.com/ the personal blog of High Moon’s Chief Technical Officer; Clinton Keith.

Additional Reading on SCRUM and Agile Methodologies

Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle
Agile Project Management with SCRUM by Ken Schwaber
Managing Agile Projects by Sanjiv Augustine
Agile Project Management by Jim Highsmith

Bio:
Rory McGuire is a Senior Game Designer at High Moon Studios where he has worked for 3 years, most recently on Darkwatch. Prior to that he worked as a game journalist. High Moon Studios is located in Carlsbad California and recently received an IT Week award for being amongst the top 50 technology innovators in 2005 for their use of Agile methodologies in game development.