Chapter 2
Agile and Lean 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.
The Solutions in This Chapter
This chapter will describe, in general terms, what Agile and Lean thinking are and how they address the enumerated problems in game development. It outlines the principles and values of that thinking and connects it with the challenges facing the industry as a whole.
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 and Lean thinking help meet the challenges faced by this game.
What Is Agile?
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,”1 which summarizes the values and principles of these lightweight methods.
1. http://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 and XP to share a common philosophy and principles. This book describes how to apply these frameworks to game development.
What Is Lean?
Game development has more challenges than most other software products. We explore and add features that our players might like, but we also have to mass-produce a lot of content that will tell stories or provide many hours of online entertainment.
The mass production of content can benefit from the lessons learned from manufacturing industries that have adopted Lean practices and principles that outperform the “assembly line” approach that is mirrored in waterfall methodologies.
The origins of “Lean thinking” precede World War II. Large-scale manufacturing industries began to understand that the greatest untapped resource was the brains of the assembly-line worker; encouraging them to take more ownership for improving workflow and quality resulted in huge improvements.
Since then, Lean thinking has found its way into every industry. It helps teams focus on continual improvement, fast delivery, and improving the entire flow of product creation.
Lean thinking lends itself to the challenges of production. Its practices are a good complement to Scrum practices. They help teams create transparency within asset production workflows and wring out the highest amount of quality and efficiency.
Lean thinking also applies to live support. Teams that need to respond to issues with the games they support or the urgent needs of players have to streamline how they work and prioritize their work daily. The transparency and tools that Lean practices such as Kanban provide help them do that.
A Lean Thinking Metaphor
“Lean thinking is a proven system that applies to product development and production, as evidenced by Toyota and others. And although most often applied to products, it is also used in service areas—both within Toyota and in domains such as health care. The image and metaphor we like to convey a key thinking mistake—and opportunity—is the sport of relay racing.
“Consider the relay racers standing around waiting for the baton from their running colleague. The accountant in the finance department, looking aghast at this terrible underutilization ‘waste’ indicated in some report, would probably mandate a policy goal of “95% utilization of resources” to ensure all the racers are busy and ‘productive.’ Maybe—he suggests—the runners could run three races at the same time to increase ‘resource utilization’ or run up a mountain while waiting. Funny…but this kind of thinking lies behind much of traditional management and processes in development and other domains. Of course, in contrast, here is a central idea in Lean thinking:
“‘Watch the baton, not the runners.’” (Larman, Vodde, 2014)
Lean approaches benefit various aspects of game development by
Eliminating wasteful practices such as rebuilding assets that weren’t ready to be built because we committed to specific start dates too early
Building quality into production rather than testing it at the end of development
Treating developers not as cogs in a machine, but as craftspeople who can improve the production process by applying skill and knowledge
Optimizing the entire production pipeline by moving work quickly through it so that we can frequently iterate on improving the workflow
This book describes how Kanban, a set of tools for implementing these Lean principles, is used for game development.
Definition: Is Agile Lean or is Lean Agile?
Many of the practices and principles of Agile and Lean are similar to one another. There are arguments about which came first or which is the foundation of the other. In practice I find blending the principles and practices most useful, so when the book uses the word “Agile” here it means “Agile and Lean.”
Why Game Development Is Hard
Beyond the technical and creative challenges, game development presents studio cultural, team, and management challenges, which are overwhelming. 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 and Gamasutra.com since they started publishing. 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 are 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 Quintessential Postmortem
Quintessential is a sci-fi shooter released by Hypothetical Studios. Although the project tested the endurance of everyone—from quality assurance (QA) to publisher—it shipped to critical acclaim. This postmortem describes what went right with the development of the game and what went wrong.
What Went Right?
The things that went right had to do with the studio’s culture and employees, the prototypes, and the license.
Studio Culture
Hypothetical Studios is a great place to work. The studio was founded by game development veterans who wanted to create the best possible environment in which to develop games. Everyone has their own office, a convenience for those late nights when you need a little peace and quiet. The kitchen is stocked with free beverages and snacks. Our game room has pool tables, foosball tables, and classic arcade machines for blowing off steam. No one works late alone. The entire team commits to working hard together. Hypothetical promotes team-work. We’re all “in it” together.
Talented Employees
Hypothetical Studios hires the best people for every discipline. Our programmers are top-notch; they are constantly exploring new areas of technology. Hypothetical doesn’t rely on any middleware; we exert full control over every aspect of our engine. Our creative group has lofty goals and the talent to match.
Great Prototypes
The early prototypes of Quintessential demonstrated a great deal of promise for the game, and we were able to develop them very quickly. For example, we demonstrated a system that allowed every part of the visible world to be destroyed. Although this feature wasn’t shipped with the game, it showed the capabilities of the technology early on.
Great License
Quintessential was based on the popular movie that was a summer block-buster six months before the game shipped. This drove considerable interest in the game.
What Went Wrong?
The things that went wrong had to do with the ship date, the timing of going into production, when people were added to the project, and the technical challenges.
Unachievable Ship Date
Quintessential was supposed to ship simultaneously with the movie. Hypothetical, a small studio with only two projects, was under a great deal of pressure to meet the original ship date, but in the end, we were unable to do so. Part of the reason was that the game’s features continued to change during development. These changes were not accounted for in the schedule, and they added time.
Going into Production Too Soon
The project was originally scheduled to start level production 12 months before the release date. Unfortunately, when the time arrived, we weren’t far enough along with the game mechanics to lay out the levels properly. For example, the player was given a jet pack that allowed them to fly through the air after production started. This required us to add more vertical spaces than we had planned. Nonetheless, the schedule forced us into production on the originally scheduled date; launching the game on the same date as the movie was considered very important. As a result, many of the levels had to be reworked when the game mechanics were figured out.
Adding People Late to the Project
As we fell behind in production, the studio brought more people over from the other project to increase the pace. These new additions to the project team needed a lot of handholding to come up to speed, however. When they did come up to speed, they merely created more assets that had to be reworked later. In the final tally, merging the two project teams actually slowed us down.
Underestimating the Technical Challenges
The original destructible prototype showed so much promise that it was added to the design with few questions asked. It was going to be the killer feature that would make the game a hit. Unfortunately, the programmers discovered—too late—that the destructible system didn’t work on a large majority of smart-phones. We were forced to make the painful decision to drop the feature and replace all the destructible geometry in the production levels with the static geometry as originally planned.
Ignoring Monetization Until It Was Too Late
As a free-to-play game, we were counting on making money by monetizing the game through in-game purchases of advanced armament, shielding, and spaceship enhancements. Unfortunately, because we didn’t add and test the integration of such add-ons early, we had to throw out and rebuild many of the systems to accommodate add-ons and to rebalance the game after its initial release. Many players didn’t like this and bailed on the game.
Conclusion
We are proud of our efforts to produce a good game that is worthy of the license. Although we had some challenging times, that’s the nature of making games. The lesson we learned is to plan a little better at the start of the project. Had we explored the monetization system a bit earlier, we could have had it ready for the initial deployment of the game.
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 stakeholder 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 the game.
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.”
Terminology
Studios use the words “deploy” or “ship” when a game is released into the market, and this book uses both. Commonly, live digitally distributed games use “deploy.” and disc-based games use “ship.”
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 and more plausible 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 greatly 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 how 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.
Responding Quickly to Players
Many, if not most, games being played are continually being updated. These games are monetized not only from an initial sale, but also from adding content or selling upgrades and other things that players want.
As a result of this, the increased competition in online marketplaces, and the lower initial purchase costs,2 today’s players are much more fickle and likely to “jump ship” to a competing game that offers a desired feature sooner.
2. Such as the free-to-play games
Live game developers who take months to design, plan, develop, test, and deploy versions of their games can be upstaged by competitors who deploy every few weeks.
Experience
I was hired to work with a team that was supporting a popular agriculture-simulation social network game that had been around for years. They had been seeing their daily active user counts declining steadily since a competing game, developed by a startup after three months of initial development, had appeared and was deploying new versions of their game weekly. Despite the clear evidence to the contrary, this established game team didn’t see the benefit of increasing their cadence of deployments.
Applying Both Agile and Lean
Just as carpenters wouldn’t settle on just using a hammer or a saw for their work, game developers can’t settle on one set of tools for all development. The most successful teams will continually explore and refine practices on a regular basis.
Figure 2.2 shows the areas of uncertainty for pre-production and production. Game developers find that when they are exploring ideas and core mechanics for games, using the time-boxed approach of Scrum, where cross-discipline teams “swarm” on a problem and deal with emergent issues daily, works best. However, when the uncertainty of what is fun is reduced and the vocabulary of the mechanics is refined, then producing the content for the game is best served by using Kanban practices. Similarly, when a game is deployed, then a combination of Scrum and Kanban practices often serves the team well. Chapter 22, “Live Game Development,” explores this in detail
Agile and Lean are complementary and overlapping in principle.
Agile vs. Lean
This book’s primary focus is to help game developers make great games and enjoy doing it. The first edition of this book received criticism from Scrum and Kanban purists who said it “broke the rules” of their favorite brand.
It doesn’t make sense to me to adhere to some strict rules of a framework that promotes exploration and ownership. Process doesn’t determine which games are great. People, talent, and creativity have more impact.
Why Use Agile and Lean for Game Development?
What has driven the industry towards Agile and Lean? Primarily, market forces for higher quality, lower cost, and faster cadences are driving us. As discussed in Chapter 1, “The Crisis Facing Game Development,” the cost of creating games continues to grow. While the market expands and diversifies, the long-term stability of any studio or team has diminished. Competition has increased, and the news is filled with announcements of studio closures or large-scale layoffs.
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!
Developers are trying to keep costs down on development by doing the following:
Seeking opportunities to outsource asset creation and code development
Relying on middleware3 solutions
3. Middleware is technology purchased from a vendor or another developer.
Reducing the amount of content (releasing a game with 8 hours of gameplay rather than 16)
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
Seeking to monetize games in questionable ways
Taking fewer chances on new ideas
These steps can reduce the quality of games on the market and discourage players from buying games.
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 player in the fastest and most economical way. 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 The Electronic Entertainment Expo (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
Question
How many times have you been in alpha or beta and wished for a few extra months to improve the game?
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.
Iterate More, Fail Fast
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.
Note
A kill-gate model of development is where a number of prototypes are started with the intention of funding only one to completion. The prototypes are narrowed down as they demonstrate their value. The ones that are not proving their value are stopped at the “gate” and are “killed” rather than allowed to continue. This is different from the stage-gate model, which is discussed in Chapter 17, “Working with Stakeholders.”
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 processes and tools to support the Agile team, but having individuals solving problems with their colleagues on a daily basis is more valuable.
Creating Value
“It is not just problem solving that Agile helps—it also creates an environment of creating value that would not otherwise be created if the direct communication between developers was not there. An example is a programmer exposing some unrequested values of a feature of their own volition (and communicating this) because they better understood what the designer was trying to do—making a better product for it. This is some of the ‘magic’ that happens with the top game teams in the business.”
—Scott Blinn, Vexigon, Inc.
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 because 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.
Note
I’ve seen a game design document for a fantasy shooter game that contained details such as the number of bullets per magazine! How can we really know how many bullets per clip we should have in the design phase? Why do we need to plan for that detail before we have the knowledge of what we need? This is an example of the problem that detailed plans can create: They can create work that is not necessary. If all the assumptions about the weapon system were implemented before discovering what was fun about it, much of that work is wasted. If the project sticks to the detailed plan, then it won’t be the best game possible.
Customer Collaboration over Contract Negotiation
Our ultimate customer for games is the player. They decide where they spend their time and money. For live games, we find ways to communicate with them and measure what they do to help guide what we develop.
Another type of customer to an agile team is the stakeholder. Stakeholders have a “stake” in the game, such as money invested in its development and outcome, or even their jobs. Examples of stakeholders are:
Publishers
Studio leads and executives
Franchise owners
Often, the stakeholders of a game will insist on having the team produce a game as defined in a contract, which includes design, schedule, and cost goals.
Agile teams address work differently. Instead of following the specifications of a contract to the letter, they work with stakeholders to adjust the goals of the game as the game emerges and they learn more about its value. Chapter 17, “Working with Stakeholders,” explores this topic in more detail.
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 that 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.
Lean Principles Applied to Game Development
Lean has a number of underlying principles that apply to game development.
Eliminate Waste
Lean practices focus on finding and eliminating waste everywhere. This is especially useful in content creation where many games generate two to three times the number of assets. They eventually ship due to either creating the assets before the mechanics and technology they depend upon are known or the costs for creating them are fully known.
Build In Quality
Don’t fix it at the end. Build in quality as you create features. Many games postpone creating a quality experience until the end when they throw large numbers of testers at games filled with bugs and performance problems. A lean approach addresses these issues throughout development.
Create Knowledge
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 a PlayStation. 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 and rebuild 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 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.
Defer Commitment
Make irreversible decisions as late as you can responsibly make them.4 Keep your options open. If you defer making such decisions until you have more knowledge, you’ll make better decisions. Examples:
4. Deferring an engine choice for half the game’s development would be irresponsible.
Defer specifying level and character polygon budgets until your renderer can demonstrate the necessary performance.
Defer creating a camera management architecture until you have built up a number of cameras that work in the game.
Defer story design until you have the core mechanics in place that the “story beats” require.
“We Don’t Know”
Saying, “We don’t know enough yet to make a decision” can be challenging in some studio cultures.
Deliver Fast
Give your customers something quickly. Continually iterate. In these time of highly competitive live game updates, beating a competitor to the market with better features is measured in days. Lean encourages an optimized pipeline to streamline the time it takes from concept to delivery. Chapter 22, “Live Game Development,” explores this topic in detail.
Respect People
The people building the product know best how to improve the process. Create a culture where continual improvement comes from everyone. The people closest to the work will come up with the best ideas about how to improve that work. That doesn’t come from telling them to do it. It comes from empowering them to be more than “task monkeys.”
Game development requires craftspeople. Craftspeople grow their skills over time, which requires continual learning and practice. Lean organizations invest in their people and protect that investment by creating cultures that make people want to stay.
Optimize the Whole
Local optimization actually makes the whole less effective. Use tools such as “Value Stream Maps” to visualize how everything flows and optimize there. A development pipeline that very quickly iterates on a design that’s been sitting in a queue for months and months isn’t very effective. Lean examines where the “pile-ups” are occurring and streamlines the whole (see Chapters 10 and 22).
Reminder
The use of the word Agile in this book refers to both Agile and Lean values and principles.
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 one to three 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.
Note
Some studios use the term release to mean the game is released into the market. In this book, releases mean “potentially deployable or shippable.” Releases are described in more detail in Chapter 3, “Scrum.” User stories are described in Chapter 8, “User Stories.”
The “inspect and adapt” principle is the cornerstone of Agile practices. Teams and stakeholders 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.
Note
The first iterations of a project will often focus on building the minimum necessary infrastructure, if one does not exist, before any valuable gameplay is seen.
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
After 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, players and stakeholders 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 that is ordered by the Product Owner. These features are written to communicate their value. Small cross-functional teams of developers focus on completing one or more of the most important features from the Product Backlog in a time-boxed iteration called a sprint and demonstrate their progress through an improved version of the game in a review with the stakeholders. A Scrum Master assists each Scrum team by helping them remove impediments to progress, ensuring that they are following the agreed-upon process and exploring ways to improve that process.
Projects Versus Live Development
Most game development used to be project-based. Projects have discrete beginnings, middles, and endings aimed at developing a game to be shipped. Following this, a team would then move on to another project. As a developer, I always felt a bit of sadness at leaving a game I had worked on for many months.
With the spread of the Internet in the ’90s, PC games had the advantage of allowing upgrades and expansions after a release, and a few developers stayed with a game for its entire life. Some popular massively multiplayer online games (MMOs) have support crews fixing bugs or making sure the games keep up with the latest operating system changes a decade after their initial release! Digital distribution platforms such as Steam have built on the PC’s strength of connectivity and openness to allow many developers access to popular online marketplaces with incrementally released games.
As consoles gained Internet connectivity and local storage, we started seeing a similar pattern. Often, it wasn’t a good thing for players. Day-one patches became a way for game developers to push off bug fixes and optimizations. This forced players to wait hours for updates to be downloaded before they could play a stable and polished version of the game. Digital marketplaces have also emerged on consoles and offer a way for smaller developers to reach console players directly.
Mobile games have revolutionized the live game model and open marketplaces by offering cheap or even free versions of their games, which are monetized through advertising or by selling add-ons that enhance the value of the game. Console and PC games have been slower to catch up with this model, but players are becoming accustomed to these monetization patterns on every platform.
As games and teams transition to live models, the term project has less meaning. Schedules, budgets, and feature specifications become more fluid based on the day-to-day key performance metrics rather than fixed up-front profit and cost projections (also known as guesses) from a marketing group. Rather than the approach of stuffing every conceivable feature into a single shipped version and hoping that some of those features will drive sales, many AAA game developers are approaching a “Games as a Service” (GAAS) model of releasing a minimally playable game (MPG, a variation of the minimally viable product approach) and keeping teams together to release add-on features based on how the market reacts.
Pre-Deployment Releases
Many live games deploy a version of their game on a frequent basis. Before the first deployment, Agile games use releases, which are sets of sprints, to produce deployable versions of their products, as described in Chapter 9, “Agile Release Planning.” For them, releases are like milestone deliverables that bring the game to a “near-shippable” state (see Chapter 9).
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 10, “Video Game Project Management.”
Figure 2.9 Agile project flow
The Challenge of Agile and Lean
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 and Lean approaches such as Scrum and Kanban 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.
What Good Looks Like
Whenever I visit a studio that embodies Agile and Lean values and principles, I always experience the following:
Discovery: They’ve created unique practices that solve problems exclusive to their process and games.
Engagement: Developers are engaged in evolving the process and are able to contribute to their games in a creative way.
Challenging: They don’t accept anything as gospel, but question every new practice.
Safe: There is safety in running experiments that often fail without blame. Developers are able to point out the problems in their process or studio without fearing retribution.
Summary
Acting with transparency is the key to the success when applying Agile and Lean practices. These methodologies 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 provides 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.
Larman C., and B. Vodde 2017. Large-Scale Scrum: More with LeSS. Boston, MA: Addison-Wesley.
Taylor, F. W. 1911. The Principles of Scientific Management. New York: Harper Bros.