Scrum Task Boards and the Production Team

At the start of a Sprint, the Scrum team will commit to completing a set of tasks that they estimate. Those tasks are placed on a task board that everyone reviews every day. Many of the tasks can be worked on out of sequence, or in parallel.

If one task is held up waiting for another task, then work can continue on other tasks. This organic flow of task execution fosters communication among the team and prevents impediments from stopping them cold. Scrum task boards are great for showing a large number of tasks that can be executed out of order for a number of Sprint goals.

However, when we have a long string of sequential tasks that must be completed in order, then we lose some of the benefits of parallel execution of tasks. Tasks have to be finished in order and work must flow though in a predictable way to ensure that the many specialists we have on a production team are not starved for work. Scrum task boards fail to represent this flow of work through long assembly lines of production.

Scrum task boards represent three or four states of a task:

- Not started yet
- In progress
- Needs approval
- Done

This is sufficient for many tasks in preproduction. There is a lot of back-and-forth between different disciplines behind the scenes that occurs while a task is in progress, and that's fine. However, when we enter production, we can have a long chain of tasks that need to occur before we see some production assets in the game. Take, for example, the steps that need to occur for a single level to appear in the game.

This is a simplification of the large number of tasks and hand-offs that need to occur for every level in the game. Each task in this stream has to occur before it is handed off to the next step.

If one step in the stream fails or is delayed, the repercussions will travel through the rest of the stream. Let's apply this to a Scrum task-board as a set of tasks:

This task board above tells us that the script is done and concept art needs to be approved before level design can be started. One problem immediately appears -- the visibility of the entire stream cross-dependency isn't shown task board. Perhaps the concept art approval is stalled.

What does this mean to the other tasks? It means that they are all delayed! Who pays for this delay? The person doing the tuning pass, perhaps even the audio design. The main benefit of task boards is to provide visibility to the team about the work they are doing. In this case this visibility is lost due the inherent dependencies in the stream. They just aren't visible here.

Another problem with representing streams on the Scrum task board is: what are the disciplines at the bottom doing while the first set of tasks are being worked on? What are the audio designers doing while the concept art is awaiting approval?

They could create environmental sounds or some other filler work, but that isn't the most efficient use of their time. Scrum task boards empty at the end of every Sprint. In production, we don't want to empty the production line. We want it to be continuously filled so that everyone in the stream has work to do every day.

So What Use is Agile During Production?

We need to remove some of the iterative nature of development and become more prescriptive during production. We don't want to abandon the ability to react to change, however. Production is never 100% efficient.

We are never able to predict every potential problem. We can find massive improvements in our pipelines right until we ship the game. For this reason we don't want to abandon agile entirely.

If we establish fixed schedules and deadlines, the best we can hope for is to meet those schedules. Unplanned problems will continue to appear and threaten those schedules. What we need are practices that are still agile; practices that anticipate not only change but focus our attention on continually improving how we produce assets.

Lean Production and How it Applies

Lean Development and Production has roots going back to Toyota in the 1940s. During the 1990s, many car manufacturers and other manufacturing industries adopted the principles of lean thinking.

This past decade has seen its adoption in many industries that aren't considered in the traditional manufacturing arena, including software development. Lean principles concentrate on eliminating waste, delivering fast, empowering the team and seeing the whole (Among others benefits -- see the book references at the end of this article).

We can apply these principles to game development as well. Like automobile manufacturing, in production we have long chains, or streams, of work that need to be performed by specialists in order.

Like automobile manufacturing, the cost of labor and mistakes are by far the greatest costs. We need to employ the full skills of everyone "on the line" to improve what we do and how we do it. The automobile industry discovered decades ago that assigning everyone on the line a fixed set of tasks does not achieve the best results.