Improving Quality
The
focus on quality is a principle of Lean Production. Lean Production minimizes
the inventory of unfinished work between each stage of a value stream. This
allows change to be introduced much more frequency because the debt
of unused components is keep low.
This
is key to how companies like Toyota have improved the quality of their cars
and dominate the market. If you find that you have a defect in a part of your
car in production, it becomes a lot easier to introduce a new improved part
when you don't have a million of the old parts sitting in a warehouse.
This
philosophy translates to the assembly line as well. On the Toyota factory floor,
if any assembly line worker sees a defect in the cars being produced they hit
a big button nearby. If that problem isn't fixed in the next 20 minutes, the
entire factory assembly line comes to a halt until the problem is fixed.
This dedication to quality is unmatched in any other company and it is made
possible by using Lean Production principles.
Additionally,
as we reduce the cycle time by finishing batches of product, we improve our
iteration cycle. Using our example, we can play finished zones every week as
they "roll off the line".
We don't have to wait 16 weeks for entire
level to be finished to play it. This one week cycle allows us try the level
much sooner and introduce change before we have spent much time creating the
remaining zones of the level.
If we build all of our levels in parallel and
don't discover problems until 90% of the work is done (such as rendering or
memory budgets or gameplay quality) we are faced with having to throw out a
great deal of work or ship the lower quality work to meet the deadline. It's
the same problem that car companies face when they decide to throw out the
million potentially defective parts in the warehouse.
Outsourcing
Outsourcing
has its benefits and place in asset production. However many studios have
found that outsourcing limits the amount of iteration that can take place in
the creation of large assets such as key characters or levels. This limited
iteration can impact quality or introduce expensive rework that limits the
cost benefits of outsourcing.
Lean
Production evolved to work with external suppliers. These are indispensable
for manufacturing industries such as car production. Suppliers to Lean
Production companies have to become Lean themselves. The key difference with
Lean suppliers is that they deliver smaller batches of parts to the main
production line. This is done to allow quality improvements to be introduced
frequently and at lower cost.
How
can this translate to game production? With our example, we don't want to
outsource the entire value stream. They key is to outsource parts of the
value stream that don't require the high skill level that you want to retain
in house. Generally in level production, you want to be able to keep large
the layout tasks within the studio and outsource the parts that are used in
layout.
Examples of this are environment sets or collections of assets that
are common throughout your level. If you were creating a large city level,
you would outsource all the props such as light posts, mailboxes, vehicles,
building components, ambient sounds, etc. These environmental sets are
brought into the layout stages (hi-res art and audio layout). This allows for
continued iteration of the layouts in the studio where they belong.
The value stream for our outsourced level production would
now look like this:
The
outsourced assets can be identified in early level concept development to
allow for sufficient lead time for outsourcing. Many layout tools support
asynchronous introduction of outsourced components. An example is the Unreal
Engine 3 editor. The packaging system allows for proxy assets that can be
replaced one at a time which automatically replace all instances of the asset
throughout the game.
What if the Rest of the Team is Still Using Scrum?
During
production, not all iteration is useless. The team is still innovating the
game in areas that don't affect production. Sprints are still valuable for
these teams. How do these teams work with the teams using Kanban?
Scrum
teams can still use Kanban to drive production. If we have one week cycle
times inside of four week Sprints, the production teams can still show the
result of four cycles every Sprint review. The production team won't have to
do Sprint planning, but they should still conduct regular retrospectives.
Additionally Daily Scrums are still a useful practice for the production
teams. Impediments will still arise that need to be addressed by the team.
Conclusion
In
using this step-by-step process for creating level assets we had taken the
cost of producing a single game level from 16 weeks to seven weeks (seven
zones times one week per zone). This represents a 56% improvement in the cost
of creating a level and required very little new tools or technology to
achieve.
This is just a start. Lean production demonstrates improvements that
can replace or supplement the need for outsourcing large key assets that a
studio may prefer to keep in house.
Like
Scrum, the adoption and practices of Lean are subject to change based on your
own environment. The key is to achieve visibility on the process and to
create metrics that are meaningful. Time-boxing asset creation can be a
challenge. Most artists don't consider quality a variable in their work. It's
a key role of the product owner to communicate their vision for not only the final
product but the responsibility for ROI that they control.
References
1
http://leansoftwareengineering.com/2008/05/21/coffee-cup-kanban/
I consider the two books by
Tom and Mary Poppendieck to be the bibles of Lean Development: Lean Software
Development: An Agile Toolkit and Implementing Lean Software Development: From
Concept to Cash
I also pay close attention
the to writings of Corey Ladas and David Anderson of Modus Cooperandi for
inspiration and knowledge about Kanban: http://www.moduscooperandi.com/
---
(c) 2008 Clinton Keith
Title photo by Gregg, used under Creative Commons license.
|
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