Leveling Production
Leveling
production is a Lean technique for reducing waste and smoothing out the fluctuations
of production. This allows us to create production assets a constant a
predictable rate.
Much of the time we spend in production is wasted on work
or activities that don't add to the final product. By making these wastes a
focus of our effort, we can get a huge increase in productivity.
Kanban
Anyone
that has used a Scrum has used a simple Kanban system. In Japanese the word
Kan means "signal" and "ban" means "card".
Therefore Kanban refers to "signal cards". Kanban represents a "pull
system" for work.
A Kanban card is a signal that is supposed to trigger
action. You can see Kanban everywhere. The next time you order a barista
drink at Starbucks you can see a Kanban system in place. The coffee cup with
the markings on the side is the Kanban! (1)
With
Scrum, a team member "pulls" a card across a board on a daily basis
as accomplish work. No one is pushing the work at them in at a predefined
rate.
We can employ some of the
practices of Kanban that are not used in Scrum to visualize a complex
production stream and allow us to apply lean principles to make that
production stream as effective as possible.
Heijunka Boards
A
Heijunka board represents the Kanban systems that use cards that represent
the capacity and workflow across a value stream.
As mentioned, when you use a
Scrum Task board, you are using a very simplified Heijunka board that
represents a three or four stage value stream. We can expand this in
production by adding the steps to our level production value stream example:
Now
we have eight states for each level to be in, which represent the six stages
of our value stream, and states at either end that contain levels not started
or levels completed. This rotates the typical tasks of the stream into states
on our Heijunka board.
This board communicates the flow of work in a level
production stream more clearly than a Scrum task board.
Applying Lean Principles
Now
that we've represented our value stream for level production, we can begin to
apply some of the Lean principles to incrementally improve level production.
The first step we can take is to look at the cycle time of our value stream.
Cycle time is the amount of time that it takes for a level to enter from the
left in script treatment to the end when the tuning pass is done. In our
example above a level takes 16 weeks of cycle time. By reducing cycle time we
can be more efficient:
- Faster cycle times means more productivity.
- The more frequently something comes "off the line", the more we can
fix problems with the production line.
- We can identify waste more easily and address it.
There are a number of ways to reduce the cycle time. The first
way is by finding ways to reduce the size of things in the stream. For our
level production example, we can do this by splitting levels up into
sections, or "zones".
Each zone takes approximately 12 days to pass
through the value stream -- as opposed to 16 weeks for each level. As a
result, our Heijunka board looked like this:
A
Heijunka board shows the progression of a zone through each stage of the value
stream. In the example above, Zone 1 has stepped through each stage and been
handed off to the final Tuning Pass stage at the end. This board represents a
perfectly balanced flow of work across every step of our value stream.
It
won't initially happen this way. There will be gaps that appear in some columns
and pileups of work in others, but that's the point of doing this: those
problems will be visible as soon as they occur. When we achieve transparency,
we can start to fix the problems that we clearly see.
How to Improve the Flow
Now
that we have a Kanban up and running, we have to work on making it as
effective as possible. The Heijunka board will show us daily where there are
gaps or pile-ups in our flow. We not
only want to keep things balanced, but we want the flow to be as quick as
possible.
In our example, if each zone
takes 12 days to pass through the entire stream, we want to find ways of
reducing that as far as we can without sacrificing quality below the level
the customer will accept.
There are a number of tools we can use to improve the flow:
- Time-boxing
- Leveling workflow
- Reduce waste
|
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