Chapter 2. Agile Development

In the eighties, the backlash against waterfall methodologies was growing. Large defense and IT projects were failing with growing frequency. This led to numerous books and articles defining better practices. Some of these methodologies, such as evolutionary delivery, promoted incremental development of products using iterations. Each iteration contained a slice of all the phases of development instead of development being spread out over an entire waterfall cycle. The iterations could be as short as a week but included analysis, design, coding, integration, and testing within that time frame rather than spreading each of them out over years as they could be on a waterfall project.

Many emerging iterative and incremental methodologies were referred to as lightweight methods until 2001 when a group of experts gathered and decided to refer to them as agile methodologies. The result of this gathering was to create the “agile manifesto,”¹ which summarizes the values and principles of these lightweight methods.

¹ www.agilemanifesto.org

The agile manifesto reads as follows:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

These simple values have enabled agile frameworks such as Scrum, Lean, and XP to share a common philosophy and principles. This book is about applying these frameworks, mainly Scrum, to game development.

In this chapter, we’ll look at some of the typical problems that face game development projects, as illustrated by a hypothetical game postmortem. We’ll see how agile helps meet the challenges faced by this game.

Why Projects Are Hard

This section uses the postmortems from game projects to help establish why projects are so hard. We’ll begin by looking at a hypothetical but typical postmortem and then extrapolate from it the three most typical areas into which game project problems fall.

Learning from Postmortems

I’ve been a fan of Game Developer Magazine since it started publishing in 1994. My favorite articles are the postmortems of game projects. Not only do they show how different studios work, but they also show that none of us is facing such challenges alone. Some postmortems are brutally honest about the overwhelming challenges developers face. Reading these postmortems feels like passing a car wreck; you shouldn’t look, but you do anyway.

These postmortems are a good starting place to reveal the reasons for adopting an agile framework for game development, so I’ve concocted a short postmortem based on a hypothetical game called Quintessential. It encompasses the more common issues seen in published postmortems and my own project experiences.

The Problems

This postmortem tells a story familiar to many experienced developers. Why do projects start out so full of hope and end up in a spirit-numbing crunch of overtime and wasted effort? Is this the best way to make games? I hope not.

So, why do projects run into trouble? There are three major reasons: feature creep, overoptimistic schedules, and the challenges of production.

Feature Creep

Feature creep is the term given to features being added to a project after the original scope is defined. There are two main reasons for feature creep; the first is when the stakeholders see the game in progress and request new features. This is referred to as emergent requirements. The second is when the feature doesn’t live up to its expectations so more work is added.

Feature creep isn’t a bad thing unless the budget and/or schedule remain unchanged as work is added. It happens so gradually that management accepts it without much question. Why do they allow this? It’s usually because they have little choice; troubled projects often agree to changes that the customer requests to avoid cancellation.

Opportunities to add value to the game are identified throughout the project, but with a tight schedule and workload, they either have to be ignored or have to be added at great peril to the deadline. Unfortunately, swapping out planned features for new ones that require the same amount of effort is not an option. Feature creep tends to expand the total scope.

Feature creep and change are inevitable. Have you ever gone back and read the original game design document for a game you just shipped? Often it seems that the title page is the only thing that doesn’t change.

This is often the main problem with writing big designs up front (BDUF): The goal is to answer all questions about the game. In reality, we can’t really know everything about a game at the start. Knowledge comes only when we have the controller in hand and are playing the game at a decent frame rate on the target machine. The only way to recognize fun is to play it.

In the early stages of the game, we have the greatest range of uncertainty. We may be certain that we’re making a first-person shooter, but knowledge of exactly what types of weapons are best is lacking. We learn more when we can shoot characters in the game.

Figure 2.1 demonstrates how uncertainty diminishes over the phases of a game or feature’s development. Uncertainty is highest at concept definition and slowly drops as a product or feature set is testable on the target machine.

Figure 2.1. Reducing uncertainty

A waterfall project carries hundreds of uncertain features forward to the testing phases—called alpha and beta—just before shipping. An agile project eliminates the uncertainty in small iterations that include every part of development.

Overoptimistic Schedules

Task estimation is not an exact science. Even when we estimate simple things in daily life, such as running an errand at the store, unanticipated problems crop up and throw off our estimates. Traffic will jam, or the lines at the store will be long. The accuracy of estimates drops when more complex tasks are estimated, such as those for making games. Many things throw off the estimated time to complete a task:

• The difference in experience and productivity between two people who have a task assigned to them. Studies have shown that the range of productivity will vary by a factor of ten.

• How many other tasks a person is working on at a single time (multitasking).

• The stability of the build and tools used to complete the task.

• The iterative nature of a task: It’s never certain how many iterations are going to be necessary for tuning and polishing a feature to “find the fun.”

The Challenge of Production

The challenges for pre-production and production are quite different. Pre-production is the exploration of what the game is. The challenge of pre-production is to find the fun of the game that drives the goals of production. Production is the stage where the team builds a dozen or so hours of content, such as characters and levels. Production fleshes out the story and surroundings to leverage the mechanics created in pre-production. The challenge of production is to maximize efficiency, minimize waste, and create predictability.

Predictability is more important during production. Production represents a great deal of work. Dozens of characters and levels have to be built before a game is shipped. Production often accompanies a major staffing increase or engagement of an outsource company. Mass-producing assets such as characters and levels shouldn’t start early. The game mechanics and asset budgets must be established to create proper assets on the first pass to avoid expensive rework.

Production should begin when the uncertainty about the game mechanics and the uncertainty of the technology and tools to make the game have been reduced. Figure 2.2 shows how a project should pass through the prototype, pre-production, and production phases based on the level of certainty about technical solutions, asset budgets, and quality and design knowledge.

Figure 2.2. Uncertainty of design and technology

Most game projects cannot afford the luxury of entering production when they are ready, but pre-production is difficult to predict. The exploration of what is fun and the range of mechanics to mass-produce are difficult to schedule. When pre-production takes longer than expected, projects are often forced to enter production by the demands of a schedule. Figure 2.3 shows how the transition from pre-production to production should happen.

Figure 2.3. Scheduled vs. actual production transition

Some assets are ready for production earlier than others. Our knowledge of the budgets and quality of what the game should ship determines the timing of when an asset enters production. If these things are unknown, the asset should not be in production.

When teams enter production too soon, they do so without the proper knowledge of what to build. By the time the team discovers the true requirements, they may have created a good chunk of production assets based on false assumptions. If the requirements have changed—for example, removing the destructible geometry or adding the jet pack in Quintessential—then those assets need to be reworked. This creates a lot of wasted effort and time.

Why Use Agile for Game Development?

What is driving the industry toward agile? Primarily, market forces for higher quality and lower cost are driving us. As we saw in Chapter 1, “The Crisis Facing Game Development,” the cost of creating games is growing much faster than the market for games. We’re coming to a crossroads that will determine the future of the industry. Are we facing another fallout such as 1983, or will we discover new markets and new demographics of people we’ve never reached?

Knowledge Is Key

Imagine that after two years of effort, you have just shipped the gold master version of your game. The project was challenging; it was a genre new to the studio, so a lot of technology had to be created. It was the first title that the studio has shipped on the PlayStation 3. There were a lot of false starts and dead ends.

Now imagine that you and the entire project team could go back in time to the beginning of the project and start all over again. Would you do anything differently? Of course you would! You wouldn’t repeat all the mistakes you made the first time. You would work far more effectively to reimplement code you knew would work or build levels you know are fun. With this increased knowledge, you would ship a better game far earlier.

This thought experiment demonstrates four things about knowledge:

• Its creation is something that occurs during the project.

• It has a great deal of value.

• Creating knowledge has a high cost.

• Knowledge is the greatest asset your studio can create.

A fundamental problem with the waterfall approach to games is that our crystal ball BDUFs are not entirely clear. As we develop a game, we are learning. We learn what plays well with the controller, what looks good on the target platform, and how to make the game run fast enough with enough artificial intelligence (AI) characters to make it challenging. We create knowledge every day.

This knowledge is impossible to fully embed in a BDUF or schedule. Game development is primarily about learning what to make and how to make it. It’s about reducing uncertainty over time. Agile development focuses on building knowledge about value, cost, and schedule and adjusting the plan to match reality.

Cost and Quality

Let’s take a quick look at the economics of the game market for “AAA” console or PC games. With a retail cost of $60, a game that sells half a million copies grosses $30 million. After licensing, distribution, marketing, and publishing costs are subtracted, about one-fourth of the gross sales, or $7.5 million, is left to pay for the development of a game. Many game development projects cost more than $7.5 million, and the largest majority of games don’t approach sales of half a million units. Most games fail to break even!

Publishers and developers are trying to keep costs down on development by doing the following:

• Seeking opportunities to outsource asset creation and code development

• Relying on middleware² solutions

² Middleware is technology purchased from a vendor or another developer.

• Reducing the amount of content (releasing a game with eight hours of gameplay rather than sixteen)

Publishers are also trying to reduce the number of games that lose money for them by doing the following:

• Relying on a greater proportion of licensed properties such as movie-based games

• Relying more on sequels and older franchises that have been successful in the past

• Taking fewer chances on new ideas

These seem to be logical steps to take, but they also reduce the quality of games on the market.

Now let’s look at how agile addresses quality and cost issues. We’ll see how agile helps us “find the fun” and eliminate some of the most notorious sources of wasted work common to game development.

Finding the Fun First

A benefit of iterative development is to develop a product in small steps and incrementally add features that satisfy the customer in the fastest and most economical way. For video games, our customers are the people who purchase and play our games. A fun game is more appealing to players and results in more sales. “Find the fun” is the mantra of any iterative and incremental game development project. Fun is only found with the controller in your hand.

Figure 2.4 shows a notional representation of when the fun or value was discovered during a waterfall-developed game. Waterfall projects typically show minimal progress in finding the fun in the first two-thirds of the project. Except for occasional prototype or E3 demos, much of the work is spent executing to a plan and not demonstrating value. It’s not until the end of the project—when all the pieces come together and the game is being tuned and debugged—that the project team has a clear idea of what the game is and can identify improvements. Unfortunately, the end of the project is the worst time for this to occur. The project is facing an impending deadline, and any significant change for the sake of increased value is often rejected out of consideration for the schedule.

Figure 2.4. Finding the fun

The agile project value curve approaches development in a value-first approach. This happens when the project iterates on bringing features to a near-shippable state in a value-prioritized order. The publisher expects value to be demonstrated early unless the core idea is not good or the developers are not up to the task of making a great game. This enables the stakeholders and project team to avoid wasting years of effort and cost on projects that won’t be fun. The “find the fun” mantra forces us to focus our efforts on making the game better every iteration. A game that is not fun must be questioned at every step.

Eliminating Waste

Agile practices focus the project on eliminating waste in many ways.

By “finding the fun” first, the project team finds the value early in the project rather than trying to retrofit it at the end. The same principle applies to the development of assets and technology within a game. Making changes at the end of a production cycle that affects every production asset is a lot more expensive than discovering the change before most of the assets are created. On the technology side, fixing a bug minutes after it is created can be magnitudes less expensive than fixing it in an alpha/beta phase.

Simple iteration enables game developers to explore more ideas. By delivering working software iteratively, a project can prove whether an idea is viable earlier in development. This makes it possible to enact the kill-gate model where a dozen ideas are launched and narrowed down until the best remain.

Iteration enables the project team to easily measure the cost of development and improve the efficiency of how groups of people work together. It creates a culture of continual improvement that can reduce the cost of developing games.

Agile Values Applied to Game Development

Let’s look at the agile values from the agile manifesto and see how they apply to video game development.

Individuals and Interactions Over Processes and Tools

Our processes and tools to manage ever-growing projects have grown dramatically. Large teams have driven the creation of management hierarchies. Project schedules and design documents—which attempt to predict every requirement and task necessary to make a fun game—require expensive databases to manage. All of these are considered necessary to tackle the complexity that arises from having upward of 100 people working on a multiyear project.

Game development requires developers from widely different disciplines. Take, for example, a cutting-edge AI character who needs to walk around an environment and challenge the player in the game. The creation of this character requires the participation of animators, designers, character modelers, texture artists, programmers, and audio composers, among others.

It’s important that these disciplines collaborate as much as possible to be effective. For example, it is important for an animator who discovers a bug in the animation technology to work with an animation programmer as quickly as possible. Processes and organization can add delay. In this example, the programmer may be working on a series of tasks that were assigned by a lead. This may prevent that programmer from helping the animator without permission from their lead. This leads to a chain of communication, as shown in Figure 2.5

Figure 2.5. A chain of communication

The animator has to pass the request up through the chain of command; the request then has to make it back down to a programmer who can solve the problem. In this example, the request involves five people and four requests! This flow is prone to failure and delay.

So, what is happening in the big picture?

• More than 100 people from various disciplines on one team

• Thousands of unpredictable problems that can introduce wasted time and effort

• Inflexible plans and tools to manage people who can’t predict and quickly react to these problems

• Hierarchies of management that can lead to further waste

Agile methodologies address these issues from the bottom up. One way is by promoting teams able to solve many of these problems on their own. They manage the smallest level of details but not the highest levels. They unburden leadership of the role of managing minor details. They enable leadership to focus on the big picture.

Teams start taking on larger problems as they discover they can take a small amount of ownership to solve the smallest problems. They begin asking for more ownership in other areas:

• In creating better team structures that can solve more problems by reducing external dependencies and improving focus on problem solving

• By identifying risks early and addressing them before they become problems

• By identifying and growing leaders among themselves

Agile values are preferences and not binary decisions. We still need process and tools to support the agile team, but having individuals solving problems with their colleagues on a daily basis is more valuable.

Working Software Over Comprehensive Documentation

For game development, we’ll use the following redefinition for the second value:

Working game over comprehensive design

I’ve substituted game for software since a game is more than software.

Some form of design documentation is necessary. Publishers, licensors, and other stakeholders want a clear idea of the project goals and vision. Portfolio planning and franchise or licensing requirements may create constraints on the project. Communicating what is known about the project up front has great value.

Customer Collaboration Over Contract Negotiation

The typical game development contract has a series of defined milestones. Each milestone is associated with a specific date and features that need to be delivered on that date. If the developer delivers those features on schedule, they are paid for the milestone. Milestone payments are the lifeblood for most independent developers; they will do almost anything to avoid missing a milestone. This includes avoiding change that would improve the game if it threatens the milestone with additional work. Who can blame them? Many developers who miss a milestone payment miss payroll; that is a very bad thing for them to do. The contract is an impediment to change.

On the other side, a publisher doesn’t have the full freedom to add features or change the milestone definition when they think the game would benefit from the change. The contract impedes working with the developer to fix the game.

Fixed-milestone deliverables have led to an adversarial relationship between developers and publishers. Both recognize the need for change to improve the game but lack the necessary level of trust to allow the change to occur.

Collaboration between developer and publisher should be valued more than a fixed contract. However, very few publishers allow a developer to work without a detailed contract. Outside our industry, many contracts in an agile environment follow the time and materials form, which is where the client pays for the cost of the last iteration. This style of contract requires greater trust between both parties. The client has to trust that the developer is spending money wisely. The developer has to trust that the client won’t cancel the ongoing contract without good reason.

Although most Western publishers don’t support this model, many have adopted flexible milestone definitions that allow some level of collaboration with developers every few months. As the use of agile spreads, we will see more collaborative business arrangements as trust is built through greater collaboration.

Responding to Change Over Following a Plan

Was there a detailed schedule on your last project? Did development follow that schedule? If development departed from the plan, was the detailed schedule updated to reflect the changes? The agile approach is to plan for what is known and to iterate against what is not known.

Expanding project teams and ever-increasing feature and hardware complexities have driven managers to turn to increasingly detailed planning. As we saw in Figure 2.1, defined processes are best applied when we have certainty about the technology required by a project and well-understood requirements we know will develop into a hit game. These two criteria are rarely seen. Not only do our platforms change frequently, but creating a fun, innovative game is always challenging.

What an Agile Project Looks Like

An agile project is composed of a series of iterations of development. Iterations are short intervals of time, usually two to four weeks, during which the game makes progress. Developers implement individual features that have value to customers every iteration. These features are called user stories. Iterations include every element of game development that takes place in an entire game project:

• Concept

• Design

• Coding

• Asset creation

• Debugging

• Optimizing

• Tuning and polishing

The game is reviewed at the end of every iteration, and the results influence the goals of future iterations. This is an example of using the “inspect and adapt” principle. Every four to eight iterations, the game is brought to a release state, which means that major goals are accomplished (like online gameplay) and the game is brought to a near-shippable level.

The “inspect and adapt” principle is the cornerstone of agile practices. Teams and customers inspect the progress of a game every iteration and adapt the plan to address what is valuable and what is not. Teams inspect how they are working together every iteration and adapt their practices to improve their effectiveness.

Agile projects don’t avoid planning. They adopt planning practices that allow for change as the project is developed. In most waterfall projects, milestones lead the project toward the goal defined in the BDUF, as illustrated in Figure 2.6.

Figure 2.6. Milestone steps toward a goal

Once the project has achieved the goals foreseen in the BDUF, everyone realizes that they really want to be somewhere else. Unfortunately, as we’ve seen, the project is usually out of time and money here.

Agile projects also make steps toward a goal. However, using the “inspect and adapt” cycle, they achieve better results sooner through the ability to steer the plan toward a more desirable goal, as shown in Figure 2.7.

Figure 2.7. Iterations toward a goal

The constraints on the project sets limits on how much the goal can change. A driving game won’t slowly morph into a golf game over time.

Agile Development

Figure 2.8 shows the high-level flow of an agile game project.

Figure 2.8. Agile development flow

Starting on the left, customers and stakeholders (see Chapter 3) identify features and other requirements (such as tools and infrastructure needs) for the game. These features are placed on a list called the product backlog (Chapter 3) that is prioritized by the product owner (Chapter 3). These product backlog items (PBIs) (Chapter 3) are expressed as user stories (Chapter 5) that communicate the value of each PBI to the customers and stakeholders. Small Scrum teams of developers (Chapter 3) commit to completing one or more user stories from the product backlog every iteration (or sprint in Scrum; see Chapter 4, “Sprints”) and demonstrating them in an improved version of the game. A ScrumMaster (Chapter 3) assists each Scrum team, helping them remove impediments to progress and ensuring that they are following the agreed-upon process.

The Entire Project

Many agile developers outside the game industry ship versions of their products every several months. To do this, they use releases, which are sets of sprints, to produce shippable versions of their products.

Agile game projects use releases, but most don’t ship a version of a game every three months. For them, releases are like milestone deliverables that bring the game to a “near-shippable” state (Chapter 6, “Agile Planning”).

Most larger-scale agile game projects execute a series of releases through concept, pre-production, production, and post-production stages of development, as shown in Figure 2.9. The need for these stages and how agile practices are modified for them are described in Chapter 7, “Video Game Project Planning.”

Figure 2.9. Agile project flow

The Challenge of Agile

The challenge of applying agile isn’t in merely adopting the practices. The practices are simple. The real challenge arises in the collision between the culture of a studio, their publisher, and agile. Agile methodologies such as Scrum create transparency. Every deficiency that obstructs the best flow of work is singled out for examination. Rather than putting faith in a design document, a game needs to stand on its own merit every iteration.

Acting on transparency is the key to the success of applying an agile methodology. Scrum will merely show where and what the problems are. It is up to the individuals, teams, and leaders to solve those problems and thereby realize the benefits of Scrum. The remainder of this book addresses how agile is applied to game development. The next chapter will provide an overview of Scrum, which is the core set of practices for an agile game team.

Additional Reading

DeMarco, T., and T. Lister. 1985. Programmer performance and the effects of the workplace. Proceedings of the 8th International Conference on Software Engineering in Washington, D.C. Los Alamitos, CA: IEEE Computer Society Press.

Taylor, F. W. 1911. The Principles of Scientific Management. New York: Harper Bros.