|
The
concept art and audio design zone takes 10 days, which is perfect for our
cycle time of 10 days per zone. However the other stages have different
times. Scripting and tuning take less than 10 days per stage. The script
writer might have to help two teams. The designer who does the tuning pass
can help out with some of the level design tasks or even testing.
For
the stages that require more than 10 days per zone, we need to start adding
people in parallel. For example, we would add a second level designer. The
two levels could then effectively finish one zone every ten days.
Since the hi-res
artists require 30 days per zone we might have to have three total hi-res
artists to balance our flow. There are three different ways to add people to
help out:
-
Have multiple hi-res artists work on the same zone
simultaneously.
-
Break up the hi-res stage into a more detailed specialized flow
(e.g. texture artist, prop artists, static geometry artist).
-
Have multiple hi-res artists working on multiple zones in
parallel.
Any
of these solutions will work under different circumstances. Solution number
one wasn't best because our level editing tools did not support simultaneous
editing on the same zone. Solution number two wasn't best because the
specialized flow wasn't balanced.
We already had most of our textures and
props finished. We chose solution number three. Each hi-res artist still required
30 days per zone, but the work was staggered to allow hi-res zone work to be finished
every 10 days.
Our
Heijunka board then looked like this:
Each
person has one zone of capacity. By adding level designers and hi-res
artists, we can add more cards per stage because we have added more capacity.
We
have now established a clock rate that is the same for every stage of level
production. This clock rate (10 days in our example) is called the "takt
time". By maintaing and even improving our takt time across the entire
stream we can level production and effect real improvements as we address
waste.
Reducing Waste
We
might be happy stopping here. We have a balanced and predictable production
pipeline in place. Many developers would enjoy getting here. However the
tools of lean production allow us to take things a lot further!
The
first principle of Lean is to reduce waste. We have addressed many of the
wastes identified by lean in setting up our Heijunka board, but I want to
highlight some of the others that particularly to game production.
Many
of these wastes can be identified and corrected by the team itself. This is
the ideal way to eliminate waste. The main tool for this is the time-box. The
time-box will exert subtle pressure on the team to find ways to become more
effective. In our example above, we identified a cycle time of 10 days and
balanced the entire stream to achieve this.
What happens when the product
owner challenges the team to reduce their cycle time to 9 days? Will we lose
10% of the value of the assets? Surprisingly we don't! The first reaction to
tighter cycle times if for the team to remove inefficiencies in how they
work.
Let's use a real world example. One project in production
had 10 day cycle times for the zones in their level. When they wanted to
reduce that cycle time by 20% they exposed some bottlenecks.
The biggest
bottleneck was the concept art stage. They only had one concept artist
available and that artist was sitting across the building with the other
concept artists. The concept artist took 10 days to create a dozen drawings
for each zone. There was no way to get these drawings any faster.
In team discussions it turned out that the level designers
and hi-res artists didn't really need all these drawings. Because the concept
artist was separate from the team, much of the concept art was based on wrong
assumptions. The concept artist didn't like hearing that much of his work was
ignored.
The solution was to move the concept artist next to the level
designer and hi-res artists. This allowed them to discuss the layout and
quality bar of the work being done. As a result, there were far fewer
drawings that needed to be created and the quality of the final product
actually improved.
This
is an example of the waste of handoffs (one of the seven wastes defined by
Lean). Documentation is a major source
of handoff waste. Documentation has its place for recording knowledge, but it's
not a replacement for face-to-face conversation. By applying this practice to
every handoff in the stream, the team was able to apply similar time savings
across every stage. The team seating area ended up resembling the arrangement
on the Heijunka board itself.
In
the example above, the team went from producing a level every 16 weeks to
producing a zone every week. With seven zones per level, the ultimate
improvement to level production was 56%.
|
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