Time-boxing
Time-boxing
is something that every developer using Scrum recognizes. A Sprint is a two
to four week time-box. We hold firm on the amount of time in a sprint and
only vary the functionality we can deliver. The benefit of this is to create
a predictable heartbeat of value being added to the game.
In
production we take this a step further. We start time-boxing each stage of
the value stream. For example, we might give the audio designers 10 days to
add audio to a specific zone. This is different from tasks in Scrum where the
audio designer would estimate their own work and tell the customers what they
are willing to commit to.
In
production this changes, because we have learned in pre-production how long
audio design for a zone should take. Quality becomes the variable you control
with time-boxing assets. We are not forcing artists to meet a set quality
with a fixed amount of time.
The input is the time-box (which is the cost we
are willing to pay for the asset). The output is quality that the artist is
able to provide within the constraint of time.
The
key to time-boxing assets is to find the correct time box size. If you choose
too short of a time-box, then quality will suffer. For example, if the
time-box for hi-res level geometry is set to one day, the artists would give
us a level filled with untextured cubes!
This would be a lower quality than what the customer wants.
On
the other hand if the time-box for the zone were two months, we might end up
with a zone with intricately detailed geometry everywhere. It would be
absolutely beautiful, but that beauty would come at too great of a cost to
the customer. It's the job of the customer (the product owner in Scrum) to be
responsible for the Return on Investment (ROI) for the production assets
being created.
The
product owner has to consider what the player expects from the assets in the
game. When I was working on driving games, I would tell our artists to focus
on making "90 mile-per-hour art". The quality bar should be set
based on what the player sees when they are driving at full speed. If we sink
40 hours into creating a picture perfect fire-hydrant, the extra cost would
be wasted on the player passing it at 90 miles per hour!
The product owner must keep the cost/value curve in their
mind at all times:
This shows that the value to the customer is not a straight
response to the cost of creating the asset. When you spend too little on an
asset (e.g. cube city) the value to the customer will be too low. The driver
might notice yellow cubes on the side of the road pretending to be fire
hydrants.
Beyond a certain cost, the ROI will diminish (e.g. 1000 poly fire
hydrants in a racing game). We are not relating quality to cost. We are
relating value to the customer (player) to the effort we spend. We don't want
to "deliver caviar to customers who want Big Macs".
Leveling Workflow
Time-boxing
allows us to employ a very powerful aspect of Kanban. The cards in each
column represent capacity for each stage of the value stream. As we see
above, each stage can only handle one zone at a time. That is the capacity of
each stage, if we have one person working at each stage.
Time-boxing
is the first step in beginning to find a balanced flow for our value stream
as visualized on our Heijunka board. However, one problem exists. Each stage
of effort in the stream will require a different length time-box. This can
cause gaps and pileups.
For example, if our level designer can lay out a
level in a week, but the high res artist requires two weeks, then a lot of
work can pileup for the high res artist. Conversely, if the concept artist
requires two weeks to complete the concept art for each zone, the level
designer might be waiting for work with nothing to do:
We have to find ways to balance this workflow smoothly so
that everyone has work to do every day. One way of doing this is to balance
the effort on each stage to achieve the same flow through the system.
For
example, if we want to get a zone through the stream every 10 days, we start
be looking at the time-boxed effort for every stage for each member of the
team working on each stage:
| Stage |
People days per zone
|
| Script |
5 days
|
Concept
|
10 days
|
Level design
|
20 days
|
Hi-res art
|
30 days
|
Audio design
|
10 days
|
Tuning pass
|
7 days
|
|
Printer-Friendly Version
Can we have more like this, please :) Implementations of quantitative software engineering and such in the game industry are always wonderful to read.
The first question is how a team would transition to Kanban production from pre-Production Scrum.
Logicaly I would assume you would move each group over incrementaly from the heijunka board, transitioning them from pre-production to production. Yet I didn't pick up on you stating anything about the transtion. I have missed things before, but I think you should elaborate on that, as it seems like it would be a prime area to find waste.
I'm also wonding a little bit in regards to the skills and responsibilities each of the groups had. For me the 'Script' group causes the most confusion. Are they Programmers or are they Writers?
Also, if I have software engineers developing new technology or I'm implementing middle-ware, how would that affect my project's heijunka board?
Ken - Agreed! Continuous improvement is a cultural change. Sometimes you can't even get near enough to the horse to saddle it;)
Tommy - I'll try to answer your questions:
Preproduction is partly about designing the value stream that will produce the assets. You build your heijunka board based on the value stream. This can transition at the end of a sprint.
For this example, the script referred to the story since it came before even concept art. I should have clarified that!
Ideally you develop tech that production is dependent upon before you enter production. If you have programmers within the same Lean team, they can work with their own Scrum task board, but they mainly support the production team. Outside the team, they can still be doing standard Scrum Sprints.
Hope that helped...thanks for the great questions and comments!
It's been used in a wide variety of projects. Time-boxing tends to allow for smoothing over volatility a bit, but you are right that volatility can occur. It can also occur on scheduled tasks as well, correct? Isn't it better to deal with it using an empirical pull system?
Also I didn't spend a lot of time on reducing other wastes in the value stream that is also quite effective.
Clint
Clinton, keep the articles coming!
In my head, I’ve been battling with the process conflicts of applying Agile to games development for years. Finally, it seems like someone is getting a good stab at the whole thing. A lot of pieces have fallen into place for me over the last couple of days, and reading this article certainly helped. I also read your blog on Alan Cooper’s Agile 2008 keynote. I’ve been a big Cooper fan ever since I first came in contact with Interaction Design, and that he now is focusing some energy on our industry, is really good news.
As I see it, one of the most fundamental issues still remains: Often we don’t know if what we’re building will really work until we can experience it in a greater context. Most elements of traditionally software is successful if it’s technically sound and user friendly, but with games we also have to get the fuzzy and elusive elements of aesthetics and gameplay right. Often that require us to go back and change things over and over again even when we’re in production. Sometimes that far exceeds what we can comfortable label as polish and tuning.
To avoid excessive waste, that would logically call for a more iterative process. I guess the confidence in our level designs could maybe be improved if they were mocked up or prototyped in pre-production. Expanding this part of the project, however, comes with it’s own drawbacks and might not even be possible. Another option would be to add some sort of flexibility to the suggested production process, but I can’t really see how to do that without messing up the fine-tuned Lean process.
Anyway, great read. I need to think some more about it.
How would you deal with using Kanban methods for dealing with multiple software projects that change regularly? Is there any way a more dynamic team can combine Scrum with Kanban to identify waste?
>Another option would be to add some sort of flexibility to the suggested
>production process, but I can’t really see how to do that without messing
>up the fine-tuned Lean process.
We didn't see that. The one week takt time allowed some iteration within the co-located team.
Dennis,
That's a good question. I know that people are dealing with this in the Kanban space. I don't quite believe that Kanban is better for more iterative software development, but not everyone agrees.
Clint
A couple of things:
- The example in the article suggests some kind of hard requirement from left to right, whereas often there are 'branches' to the pipeline, where multiple streams of work can be carried out at once. How do you elegantly describe these scenarios in diagram and 'signal card' form?
- How do you introduce elements such as qa passes, or external feedback passes (say in a outsourcing context). Do you add extra loops into the board? Do you feed 'failed' stuff back into the beginning?
Branches and loops can be represented in the vertical space of the kanban board. You can also draw lines for the handoffs on the board as well. These are all implied in the simple example from the article.
Clint