Chapter 7. Video Game Project Planning

In Chapter 2, “Agile Development,” a major challenge identified with adopting agile for game development was matching phase-less agile practices with the needs of game development stages, such as pre-production and production.

A typical Scrum project is always kept in a near-shippable state. The reason for this is that the work traditionally separated across multiple phases (design, coding, testing, optimization) is part of every sprint. By doing this, agile projects keep the debt of late project work, such as fixing bugs, to a minimum.

Agile game development follows the same model of combining all phases into each sprint. However, game project stages create a different form of debt, or necessary work that must be accomplished, such as production assets, which requires some new practices to be introduced over the course of the project.

This chapter addresses the needs for stages and the challenges they create. It focuses on production—the most expensive stage that derails many Scrum teams. By introducing lean ideas, Scrum teams manage complex asset production pipelines while maintaining the benefits over traditional preplanned methods.

Midnight Club Story

Of the score of games that I have worked on, only a few have shipped on time and within budget. Of these, Midnight Club was the most successful. Midnight Club was a PlayStation 2 (PS2) launch title where players illegally race in the large open cities of London and New York. The project was a grueling 18-month struggle with a new platform and new publisher.

The game was originally designed to include six cities. We considered two major risks to delivering a good game in time for the launch of the console. First was the uncertainty of developing for the PS2. Early on, its capabilities were compared to those of supercomputers, but over time we learned that it was a challenging platform that had some significant performance bottlenecks. Second, we were uncertain about the effort to produce six large cities in the time we had before launch.

We focused pre-production on creating one city that would run well on the PS2. This effort took four times longer than we anticipated. Armed with this knowledge, we were forced to scale our plans down to three cities. Our publisher, Rockstar Games, took these cuts in stride. They knew how hard we were working.

During production, we slowly realized that we had a crucial decision to make. The time to create the necessary polish for shippable cities was taking even longer than we had planned. We had to choose between shipping three low-quality cities or two polished ones. After much teeth gnashing, Rockstar Games decided to ship with two cities.

In the end, it was the best decision and contributed to the game shipping as a PS2 launch title that sold millions of copies. A major reason for maintaining the schedule was the constant attention to the production costs of creating and polishing the cities. For many game projects—especially those with fixed ship dates—the production costs and schedule pressures create the greatest risks.

Minimum Required Feature Sets

Many projects outside the game industry are challenged with an obligation of delivering on certain expectations from the start. For example, a word processor would have to have undo, printing, font management, and so on. This minimum feature set might require a year or more of effort before a product can be released.

Similarly, video games are challenged with a minimum set of requirements, including the following:

• About eight to twelve hours of single-player gameplay content

• Fixed ship dates such as the Christmas season or movie corelease dates

• Minimum required feature sets—such as online multiplayer for a first-person shooter—that must be shipped with the game

These requirements require budget and staff planning for the long term, beyond releases. For example, production costs are refined over the course of pre-production releases to identify the number of content creators and the time needed to produce eight to twelve hours of gameplay.

Minimum required features sets necessitate similar long-term plans. For the first-person shooter example, the following is a minimum required feature set:

• Single-player gameplay

• AI

• Weapons

• Online multiplayer gameplay

These features create a debt of work, much like the production debt, that takes multiple releases to deliver. Often, stakeholders demand that resource management plans be developed to support a predicted ship date for these features.

How does resource management planning work with agile planning? A proven approach is to identify a range of resource needs to implement epic-level stories and continually refine both through sprints and releases.

This is a balancing act of cost and value. Imagine you are buying yourself a new PC, but you have only $2,000 to spend, not a cent more. You’d start with a breakdown of the parts of the PC and the cost of each:

You might decide later to buy the latest graphics card that costs $100 more. This money has to come from another part of the computer. This is how long-term planning works with epics. Large epics are defined and thought about to produce a cost of time and resources. If any budget item is wrong, the time has to come from another bucket. That needs to be a deliberate and visible decision and needs to be publicly proclaimed.

For each item, the first estimate might be largely based on experience with previous games, which is not very accurate. For the first-person shooter example, a product owner identifies the large online multiplayer epics that a team of eight might complete in six to eight months. Some of these epics are not disaggregated until more is known. For example, cooperative online gameplay with AI may or may not be valuable or even possible within this resource plan until more is known, so the epic that might contain that feature is not disaggregated until more is known and a team is available to work on it.

This provides the flexibility necessary as more is discovered about the challenges, velocity, and opportunities for online as the game emerges. It does not ensure that every minimum required feature will be completed within budget and schedule—no planning process does that—but it enables decisions to be made earlier that help steer the project in the right direction.

The Need for Stages

For many games developed using agile, there is still a need to separate some of the development activities. There are three major reasons for this:

• Publishers require concepts: To gain publisher approval (which includes marketing and often franchise or license owner approval), developers need to create a detailed concept treatment at the start of a project. They are unable to stray too far from this vision throughout the project.

• Games need to deliver eight-plus hours of gameplay: Games typically deliver eight to twelve hours of single-player gameplay. Games tell stories that need a great deal of production content to be created using mechanics discovered during pre-production.

• One ship date: For large-scale games, there is only one ship date at the end of a 24+ month development cycle. Intensive hardware compliance testing is often delayed until the end.

The Development Stages

Agile game projects spread activities such as concept, design, coding, asset creation, optimizing, and debugging more evenly throughout their life. This doesn’t mean that the project is a homogenous string of sprints.

Most game development projects have stages regardless of whether they are agile or not. These stages change how teams develop the game:

• Concept: This stage occurs before pre-production. Concept development is almost purely iterative. Ideas are generated, possibly prototyped, and thrown away on a regular basis. This stage is usually timeboxed to deliver one or more concept development plans to a green-light approval process required by the publisher or a license holder.

• Pre-production: Teams explore what is fun and how they are going to build assets to support it during production. They also create levels and other assets that represent production quality. This stage is fully iterative and incremental. Teams iteratively discover what is fun and incrementally adapt development planning with this knowledge.

• Production: The team focuses on creating an eight- to twelve-hour experience using the core mechanics and processes discovered during pre-production. This stage focuses on efficiency and incremental improvements. Teams iterate less on core mechanics discovered during pre-production because they are building a great deal of assets based on them. Changing those mechanics during production is usually very wasteful and expensive. For example, consider a team in production on a platformer genre game. Platformer games challenge the player to develop skills to navigate treacherous environments (such as Nintendo’s Mario series). The production team creates hundreds of assets that depend on character movement metrics such as “how high the character can jump” or “the minimum height that the player can crawl under.” If these metrics are changed in the midst of production, it wreaks havoc. For example, if a designer changes the jump height of the character, hundreds of ledges or barriers would have to be retrofitted. This creates a great deal of wasted effort during the most expensive phase of development. It’s critical to discover and lock down such metrics during pre-production.

• Post-production: With the content brought to shippable quality, the team focuses on polishing the whole eight- to twelve-hour game experience. This stage improves the game incrementally. Following this, the game is submitted to hardware testing. Although much of this testing is spread throughout the entire project, some of it cannot be. For example, Microsoft and Sony hardware testing is expensive and only occurs in the months prior to shipping the game.

Mixing the Stages

Stages aren’t isolated to distinct periods of time. For example, although a great deal of concept work is done up front, concept development needs to be refined as the game emerges over the entire project.

Figure 7.1 shows a typical distribution of efforts on an agile game project. Note that although more design and concept is done up front and more tuning, debugging, and optimization is done at the end, many overlap with one another. For example, rather than an official “production start date,” teams see a gradual buildup of production activities and a drop-off of pre-production work in the middle of the project.

Figure 7.1. Overlapping stages

Managing Stages with Releases

Releases are a series of sprints linked together to deliver major features and assets. Similarly, a game project is a series of releases that deliver a finished game to the consumer. Figure 7.2 shows a typical series of two- to three-month releases that make up a two-year project.

Figure 7.2. Releases in a multiyear project

Each of these stages requires a different emphasis on the practices used. The transition between stages such as pre-production and production can be gradual, with various asset types transitioning at different times.

The reasons for the change in practices are illustrated by an enhanced version of the Stacey diagram shown in Figure 7.3. As the game progresses from concept to post-production, the level of technical and requirements uncertainty drops. As the Stacey diagram indicates, the practices should reflect these levels of uncertainty.

Figure 7.3. Stages of decreasing uncertainty

Source: Schwaber, K., and M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall. Reprinted by permission of Pearson Education, Inc.

The framework used is still Scrum, but teams adjust the practices for the current stage:

• Concept: Sprints are shorter, and most of the stories in the very small backlog are spikes. The main goal of the conceptual stage is to create knowledge for the team and stakeholders, not value for the consumers. Release goals are concept treatments and perhaps a prototype to demonstrate to stakeholders.

• Pre-production: Scrum is used to discover the fun of the game and incrementally and iteratively build value and knowledge about production costs. Development is paced by sprints and releases. Release goals are major features.

• Production: Teams produce assets that were identified in pre-production and incrementally improve the asset pipelines. Although sprints and releases are still used, the pace of asset production becomes the metric for measuring velocity.

• Post-production: Teams focus on tuning, polishing, and bug fixing tasks they identify daily. Although sprint and release reviews are held, the goals are driven more by the daily backlog (which includes bug fixes and polishing tasks) and upcoming key dates such as submission. Post-production starts on the alpha date and includes the beta and shipping dates.

Production on an Agile Project

Production is the most challenging and expensive stage. It represents a large debt of work that is dependent on pre-production decisions and timing.

For Scrum teams, the complex pipelines of asset creation don’t fit perfectly with the iterative flow of work in a sprint. Because of this, many teams entering production abandon Scrum in favor of waterfall practices. The problem in doing this is that they abandon many of the agile benefits.

This section addresses the issues with production for an agile team. It introduces some lean concepts that allow teams to continually improve their production rate and the quality of the assets they produce.

Production Debt

Have you ever seen a schedule for a game project that picks a day for production to begin? A date is chosen, a year or so in advance, that predicts when the team is to begin creating production assets (usually levels).

Where does this date come from? How do we know how much time is needed for pre-production and production? How do we know whether the time given is enough? How many times have you entered a nine-month production stage with twelve months of work? Many games enter production too early because the schedule says they need to do so. The problem is that the core mechanics and budgets that production depends on are still being iterated. This creates wasted work, because large numbers of assets must be reworked as this information emerges.

The work that needs to be done in production to create the eight to twelve hours of content many games need is called production debt.

Measuring Production Debt in Pre-Production

One of the goals of pre-production releases should be to measure and refine knowledge about the size of the production debt. During the first few releases, that debt is uncertain. For example, a project early in development might estimate its production debt to be 1,000 people-months of work, plus or minus 20%. Changes to the feature set may impact those ranges as well. Toward the end of pre-production, it should be more accurate, such as 1,050 people-months, plus or minus 5%. Figure 7.4 shows how this range of estimates will change over time. Although this estimate will never be perfect, it is always better than the first guess made at the start of the project.

Figure 7.4. Production cost estimates over time

These estimates are refined with sprint and release goals that call for assets with increasingly higher quality. By developing these assets, the team learns more about the actual cost required to create them. These estimates aren’t frozen in production either. During production, the team should be finding ways to improve how assets are created to further reduce costs.

Why Measure Production Debt?

Measuring the cost of production during pre-production is important to help make decisions about the features that impact that cost. If the product owner does not know the cost impact of such features, they are inclined to accept them on face value.

Imagine you are working on a first-person shooter game that has twelve months of production scheduled to build ten levels. During development, the team implements technology that enables every part of the world to be destroyed or have holes blown in it. This is a great new addition, but it doubles the amount of work required to build a level.

If the product owner knows this, they can make an early decision. The following are some choices:

• Drop the feature because the project can’t afford it.

• Drop half the levels.

• Start production earlier.

• Extend production and the ship date.

• Scale up the production resources.

Some of these choices are better than others, but they are all better than the one taken if production debt isn’t measured: trying to stuff 24 months of production effort into 12 months of schedule.

The Challenge of Scrum in Production

Production is dominated by an assembly-line approach to asset creation characterized by sequential steps of specialized work. These asset production streams are easily stalled or starved of work at various points within by impediments.

When Scrum teams fit asset production streams into sprints, they discover that some of the benefits they’ve enjoyed in pre-production, such as ad hoc iteration and transparency, are somewhat reduced.

Scrum Task Boards and Production Streams

At the start of a sprint, a team commits to completing the tasks they estimated they could complete by the end of the sprint. Those tasks are placed on a task board that is reviewed every day. Many of the tasks are worked on out of sequence or in parallel. If someone is held up waiting for another task to complete, then they work on something else. This organic flow of task execution fosters communication among the team and prevents impediments from stopping them cold. Scrum task boards are great for supporting this.

However, for a long series of asset production steps that must be completed in order, the team loses much of this benefit. Tasks must flow in an ordered and steady pace to ensure that the specialists on a production team are not waiting for work. Scrum task boards don’t clearly show this flow.

For example, consider the asset production stream for a single character to be produced in a sprint in Figure 7.5. The team estimates they will complete this work before the end of the sprint. As this stream shows, each task has to occur in order before it is handed off to the next one.

Figure 7.5. A production stream in a sprint

When this stream of work is placed on a task board, it looks like Figure 7.6.

Figure 7.6. A character production stream visualized on a task board

This task board shows that the character model is being created first. One problem with displaying streams on a task board is that the flow rate of the stream is not sufficiently visualized. This lack of visualization fails to alert a team to problems.

For example, what happens if modeling takes longer than estimated? Figure 7.7 shows the likely result. The modeler, rigger, and animator are able to finish their work, but the last person in the chain, the audio designer, does not have enough time to do their work before the end of the sprint.

Figure 7.7. What happens if modeling is delayed

The team needs to see the impact of delays within the stream while they are occurring at any time.

Keeping Everyone Busy

Another problem with fitting asset production streams into sprints is keeping all the specialists busy. In the previous character production stream example, what is the audio designer doing before the animation is completed?

Scrum teams address this problem in a number of ways. One way is to share the composer with another team that needs audio. The other is to pool the audio designers into a team that has its own backlog. Another is to batch up the audio work for a number of characters until the audio designer joins the team for a sprint. None of these solutions is ideal because each increases the separation between an asset’s creation and its appearance in the game. For example, suppose modelers are pooled together where they create a dozen character models ahead of time. If a problem is revealed the first time one of the characters appears in the game, it might require major rework of all 12, which is a big waste of effort. Shortening the time between a model’s creation and its appearance on the screen creates more opportunities to “do it right” the first time.

Less Use of Iteration

Asset production pipelines are similar to assembly lines. In this sense, a Scrum team completely empties the assembly line by the end of every sprint, which doesn’t make sense for assembly lines. They have to be continuously filled because each step in the line only works on what was passed from the previous step. An assembly-line run like a sprint creates many gaps in the line that leave team members waiting.

This is the reason that many Scrum teams abandon agile when they enter production. However, production is never 100% efficient. The team cannot foresee every potential problem. They need to seek improvements in pipelines right up until the game is shipped. For this reason, the agile values should be maintained in production. If production is driven by fixed schedules and deadlines, the best the team can hope for is to meet those deadlines, but unplanned problems will continue to appear and threaten them. Practices that are still agile are needed—practices that anticipate change, that encourage continuous efficient flow, and that focus attention on continually improving how assets are produced.

This is where “lean” thinking can help. Lean is a set of principles applied to production environments that have more certainty about what is being created but still want to introduce improvements continually. The remainder of this chapter will describe what lean is and how it and practices like kanban can help a team remain agile during production.

Lean Production

Discovering what lean means is challenging. It seems that every month someone is branding their own version of lean. Still, some common threads run through most of these lean brands, which I refer to as lean thinking.

The origins of lean thinking precede World War II. Large-scale manufacturing industries were beginning 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 paid dividends.

Since then, lean thinking has found its way into every industry. It helps teams focus on continual improvement, deliver fast, and improve the entire flow of product creation.

Lean thinking lends itself to the challenges of production (refer to Figure 7.3). Its practices, like XP programming practices, are a good complement to Scrum. They help teams create transparency within asset production streams and wring out the highest amount of quality and efficiency.

It’s outside the scope of this book to explain every lean principle (see the “Additional Reading” section at the end of the chapter). Instead, the chapter introduces some lean thinking concepts and practices through a level production example.

Visualizing Flow with Kanban

A kanban board is a bit similar to a Scrum task board.² In Japanese the word kan means “card,” and ban means “signal,” so kanban refers to “signal cards.” Kanban represents a “pull system” for work. A kanban card is a signal meant to trigger action, such as “work on this next” or “I need an animation.”

² Some call this board the Heijunka board.

A team employs a kanban board to visualize an asset production stream and provide the transparency that a Scrum task board cannot.

We’ll use an example level production stream to demonstrate how kanban and lean thinking are applied to production. Figure 7.8 shows a simplified level production stream, from concept to tuning.

Figure 7.8. A simplified production stream for levels

The first step is to represent the stream on a kanban board, which uses columns to represent individual workflow steps and capacity. Figure 7.9 shows a simplified kanban for the level production stream.

Figure 7.9. A simple kanban board

There are six columns, which representing the steps of this production stream, including the product backlog. The cards within the columns represent individual levels in production. As the work for each step of a level is completed, a card for the next level to work on is pulled from the column immediately to its left, if that level is ready.

Leveling Production Flow

Now that the team has a kanban board representing the level production stream, the team members can start applying lean tools to smooth out the fluctuations of production. This allows them to create production assets at a more constant and predictable rate.

There are two basic tools for leveling production flow. The first is establishing timeboxes for each step of the production stream. Following this, the flow is leveled by balancing the resources supporting every step.

Timeboxing

Every developer who uses Scrum recognizes that a sprint is a two- to four-week timebox. Teams don’t change that timebox. The benefit is to create a measurable cadence of value being added to the game.

In lean production, this is taken a step further. Each step of a production stream is timeboxed. For example, audio design for a level might be timeboxed to ten days. This is different from a similar Scrum task in pre-production that the audio designer independently estimates and commits to. This changes for production because the team has established, during pre-production, the ideal timebox for a level’s audio design. This timebox is based on the trade-off of time (cost) of creation and quality desired by the product owner.

Timeboxing does not mean content creators are forced to meet a set quality within a fixed amount of time. The quality is determined by what the content creator is able to provide within the time limit.

The key to timeboxing assets is balancing quality and cost, measured in time. If the timebox chosen is too short, then the quality of the asset will be too low. For example, if the timebox for a section of high-resolution level geometry is set to one day, an artist might only be able to create a section filled with untextured cubes! On the other hand, if the timebox selected were two months, the artist might deliver a section with too much detailed geometry. It would be absolutely beautiful, but that beauty would come at too great of a cost to the stakeholder compared to the value it provides to the player.

Balancing asset quality and cost is the job of the product owner. They have to judge what the player values. Figure 7.10 demonstrates a notional curve of the trade-off between cost and value to the player.

Figure 7.10. The cost/trade-off curve of assets

It’s not a straight line, because of diminishing returns; a player driving past a 10,000-polygon fire hydrant does not experience 50 times the value of a 200-polygon fire hydrant.

Figure 7.11 shows the area of the trade-off curve where the timebox selection is made. Pre-production refines the shape of this curve and the best range for a production timebox.

Figure 7.11. Selecting a timebox for an asset

Timeboxes are not absolutely precise. Some levels take more time than others. The timebox chosen is an average of best- and worst-case times. The team uses small buffers, described next, to avoid underflow or overflow of work that this might cause.

Leveling Flow

Each step in the stream usually requires a different-length timebox. This causes gaps and pileups of work, which is to be avoided. For example, in Figure 7.12, if level design takes a week but the high-resolution geometry takes two, then the design work piles up. Conversely, if conceptualization requires two weeks for each level, the level designer eventually runs out of work and has to wait.

Figure 7.12. A kanban board showing starvation and overflow

Workflow needs to be balanced so that everyone always has work to do and that large amounts of work in progress don’t pile up at any step. One way of doing this is to balance the amount of time each step takes, called its cycle time.

For example, if the team wants a ten-day cycle time for each step, they start by examining the timeboxes for each person working on the stream (see Table 7.1).

Table 7.1. The Starting Cycle Times for an Unbalanced Stream

Concept art and audio design already have a cycle time of ten days. However, the other steps have different cycle times. For example, tuning takes less than ten days per level. This means the designer who tunes levels runs out of work from time to time and has to find other things to do. This could mean helping out another team, level design, or QA.

For steps that require more than ten days per level, the team needs to add people or find improvements to the process. For example, since the high-resolution artists require thirty days per level, the team could dedicate three high-resolution artists to balance the flow. Artists can work together in a number of ways, but each has challenges:

• Have all high-resolution artists work on the same level. This may not be an option if the editing tools do not support simultaneous editing on the same level.

• Break up the high-resolution step into a specialized flow (for example, texture artist, prop artist, static geometry artist). It may be hard to balance these specialties.

• Have the high-resolution artists working on multiple levels in parallel. This solution might pose challenges with creating consistent quality and pace.

Each member of the team adds capacity, represented by a kanban limit for each column as shown in Figure 7.13. This number defines how many cards (levels) should reside in each column. When the number of cards in a column does not match its limit, it signals to the team that there is a potential problem.

Figure 7.13. A kanban board showing balanced flow

Our kanban board now looks like Figure 7.13.

The team has now balanced the level production stream and established the rate at which levels are completed, called the takt time (see the sidebar “Takt Time and Cycle Time”), which is also ten days. They apply lean tools to maintain and even reduce takt time so to continually improve the cost and quality of the levels.

Continual Improvement

One of the main advantages of using lean production is that teams maintain the drive to continually improve what they are making and how they are making it. This is a benefit over fixed production schedules, where teams concentrate on keeping pace with deadlines.

In production, teams apply the same agile planning paradigm of using velocity measurements to forecast the pace toward achieving a goal. This allows fixes and improvements to be quickly appraised.

This section uses the level production example to describe some of the ways lean thinking enables teams to continually improve how they work together to increase the quality and production pace of assets.

Improving Cycle Time

The pace of iteration has a direct impact on quality. For example, if the iteration time on changing a texture and seeing it in the game is reduced from ten minutes to ten seconds, an artist iterates on textures more, and the game looks better.

The same principle applies to asset production streams. We want to shorten a stream’s iteration time to allow improvements to be introduced as quickly as possible. These include pipeline, tool, workflow, and teamwork improvements. Shortening the iteration time of such changes enables more of them to be implemented and seen.

In lean production, we focus on improving the iteration time, or cycle time, for the entire stream rather than the individual steps. The following factors influence a stream’s cycle time:

• Asset size: Large assets, such as full levels, have large cycle times. If a team completes portions of a large asset, they reduce its cycle time.

• Batch size: This is the number of assets processed at one time at any individual step. The larger the batch size, the longer the cycle time. An example of this is completing a dozen character models before handing them all off to the rigger.

• Waste: This is the effort spent on things that don’t add value to the final asset. For example, the time spent waiting for an approval is non-value-added time, or waste.

• Knowledge, skill, and empowerment: The greatest factor in determining cycle time is the knowledge and skill of everyone who adds value along the stream and their ability to influence change. For example, knowing when and where to reuse an asset rather than building one from scratch has a large impact on cycle time.

Smaller Assets

By breaking large assets into smaller ones, teams receive faster feedback. There are three types of feedback:

• Gameplay feedback: Very large assets, such as levels, can have monthlong cycle times and, despite how detailed their design, deliver uncertain gameplay. This long cycle time provides little opportunity for feedback to influence the asset. As a result, levels are shipped based on their initial design assumptions. By breaking levels into smaller areas, teams are given valuable feedback about the gameplay emerging and use this knowledge to influence subsequent portions of the level.

• Production feedback: Improvements to the production flow are applied more quickly and cheaply. For example, if the team discovers that a particular piece of static geometry interferes with character motion in the first section of the level, they fix that section and change their standards of work to apply the improvement on every subsequent section. This is a big time-saver.

• Velocity feedback: It’s very difficult to gauge the effectiveness of individual practice changes or tool improvements when the cycle time is measured in months. If the cycle time is reduced to weeks, then changes to the pace of work from improvements are more apparent.

One level production team I was working with did this by breaking up their levels into seven smaller “zones.” Zones were the sections of levels that were streamed in and out of memory as the player moved.

Once they began building zones, their cycle times became one seventh of what they were before. Zones were completed every few weeks, and each one added improvements in quality and production that fed into subsequent zones. This team eventually reduced their cycle time by more than 50%.

Smaller Batches

Traditional production pipelines focus on the efficient utilization of resources, rather than the flow of asset production streams. The imbalance of disciplines often causes project managers to level resources so that nobody runs out of work to do. Since “resource leveling” predictions are never too precise, large inventories of works in progress are built in, between the steps.

For example, if a project has dozens of levels to ship, it may start producing batches of concept art or level props well before the end of pre-production. To a certain degree, this is necessary, but it often goes too far. For example, a half dozen levels of concept art created before gameplay is fully understood leads to waste if the concepts have to be redone or, worse, levels are produced using these obsolete concepts.

With lean thinking, teams try to reduce or eliminate batches of work. Because of the uncertainties within the timeboxes for each step, they often need to create small buffers of works in progress between the steps of an asset production stream. They choose the smallest possible buffer size, because buffers increase the cycle time. The buffers should prevent waiting but not excessive pileups of work between each stage of work.

Figure 7.14 shows how buffers are represented on a kanban board. Buffers have limits, like every other step, that signal when the buffer is overflowing or underflowing.

Figure 7.14. A kanban board with buffers

Reducing Waste

A good portion of the time spent in production is wasted on work or activities that don’t add value to the final product. Examples of this are the time waiting for exports, waiting for asset approvals, or syncing with the latest assets. Reducing these wastes greatly benefits productivity and cycle times.

Many of these wastes are identified and corrected by the team itself. The subtle pressures of takt time and timeboxing largely drive this. Timeboxes exert a pressure on the content creators to use their time wisely. As a result, it encourages them to seek ways to be more effective in how they work and point out the problems that were not so impactful when they had more time (see the sidebar “Lean Thinking and Boats”).

One production team I was working with had a ten-day takt time for level sections. This pace was challenging and exposed many problems with the flow of work. The biggest problem was with the concept art step. The team had only one concept artist available who was sitting with the other concept artists in another part of the studio. It often took more than ten days to create a dozen drawings for each section. The team recognized this as a bottleneck.

In team discussions, it turned out that the level designers and high-resolution artists didn’t really need all the drawings created. Because the concept artist was separate from the team, much of the concept art was based on poor assumptions about the level and gameplay. For example, gameplay was linear, but much of the concept art represented open areas. The concept artist was surprised to hear that much of his work was useless. The solution the team created was to move the concept artist next to the level designer and high-resolution artists. This enabled them to discuss the layout of levels as concept art was created. As a result, far fewer drawings needed to be created, and the quality of the levels improved.

This is an example of reducing the waste of handoffs. By applying this practice to other handoffs, the team was able to create similar improvements across the entire production stream.

This is one example of dozens of changes the team made. By the end of production, they had improved takt time by more than 50% while significantly improving quality.

Knowledge, Skill, and Empowerment

Like Scrum practices, lean practices create transparency in the production pipeline, which makes quality, velocity, and waste visible. One of the first things revealed is the variation of quality and velocity between separate teams. This visibility enables leads to know where to focus mentoring. In many cases, all that is required is to help a struggling content creator use a tool correctly or understand how they reuse assets to improve their effectiveness.

Lean thinking focuses skills on the final product, rather than on individual steps. Part IV, “Agile Disciplines,” discusses this in greater detail.

Many of the lean tools described require the team to be empowered to make decisions and take ownership of their practices. In the previous example, the team decided to move the concept artist with the rest of the team. In many studios, teams are not allowed to make such decisions. It comes back to the lack of transparency. With transparency, teams are entrusted to make greater and greater decisions because of the performance metrics that ensure their decisions demonstrate higher productivity and quality. The difference in the number, quality, and frequency of beneficial changes increases as ownership of them is spread. Leaders might be skilled and insightful, but they can’t be everywhere. They need to rely on empowered teams to recognize and solve issues daily.

Outsourcing

Outsourcing has established its benefits for asset production. However, many studios have found that outsourcing limits the amount of iteration that takes place in the creation of large assets such as key characters or levels. This limited iteration impacts quality or introduces expensive rework that limits outsourcing’s cost benefits.

Lean production outside the game industry evolved to work with external suppliers. Suppliers to lean companies need to become lean themselves. Lean suppliers deliver smaller batches of parts to the main production line. This is done to allow quality improvements to be introduced more frequently and at lower cost.

How does this translate to game asset production? With our example, we don’t want to outsource the entire level production stream. The key is to outsource parts of the production stream that don’t require larger iterative cycles that should remain in the studio. For level production, studio teams retain large layout tasks and outsource the component assets used in these layouts. An example of this is environment sets, or collections of assets, common throughout a level. If a project needs a large city level, they outsource all the props such as light posts, mailboxes, vehicles, building components, ambient sounds, and so on. These environmental sets are brought into the layout steps (high-resolution art and audio layout). This enables continued iteration of the layouts at the studio.

Figure 7.15 shows a production stream with the environmental art outsourced.

Figure 7.15. Outsourcing a portion of the stream

The outsourced assets are identified in level concept and design to give sufficient lead time. These assets are delivered as they are developed, rather than in a single batch.

Working with Scrum

When the project enters production, asset production teams may not use practices such as sprint planning and tracking. However, these practices are still used by other teams to continue innovating new features.

Sprints are still valuable in production. Asset production teams demonstrate the assets that have been completed since the last sprint review. Production teams don’t plan sprints. Instead, they periodically fill a backlog buffer with a set of prioritized assets to work on next. The team selects a backlog buffer size limit and fills it to that limit every time it is emptied.

Teams might also mix production and feature development work. For example, consider a level production team that has a few programmers adding effects, enhancing AI, and improving tools. The programmers plan typical sprints with user stories and a sprint backlog, while the level creators use a kanban workflow. Figure 7.16 shows how the two task boards are combined using a Scrum “swim lane” added to a kanban board.

Figure 7.16. A kanban board with a sprint swim lane

Retrospectives and daily scrums are still essential practices for production teams to address impediments and to improve how the team performs together.

Transitioning Scrum Teams

Scrum teams exploring gameplay in pre-production don’t instantly reorganize their workflow into asset streams overnight. They gradually build up to them by iterating on assets that approach production quality and refining each stage or workflow. Each team approaches this transition differently, but the common set of steps is as follows:

1. Explore what is correct (fun and cost).
2. Refine the timeboxes.
3. Understand how much content is needed and who is needed to create it, and refine the production budget.
4. Establish the asset streams.
5. Start adding columns to task boards with kanban limits.
6. Level the flow. Adjust the teams.

As the teams level the flow of an asset stream, their size might far exceed ten members. Some teams might break the team into two, but more often they maintain themselves as a single team. This allows them to “see the whole” asset stream as one continuous flow. The downside is that it makes team meetings, such as daily scrums and retrospectives, less productive because of the communication overhead.

Summary

The additional challenge of stages with game projects doesn’t diminish the value of agile or require complex plans or project management structures. It requires product owners to be aware of impacts that features have on production costs and for teams to adapt their practices as they enter production.

Additional Reading

Poppendieck, M., and T. Poppendieck. 2006. Implementing Lean Software Development: From Concept to Cash. Boston: Addison-Wesley.

Ladas, C. 2009. Scrumban: Essays on Kanban Systems for Lean Software Development. Seattle: Modus Cooperandi Press.