Lean Production: first steps

One of our projects is approaching full scale production of levels for the final release version. As mentioned before, we can't be fully Agile here. There are dependencies in levels on functionality than cannot be changed. We cannot "decide to ship or not" every three months unless we have enough gameplay to justify the $50 cost of the game.

At the same time, we don't want to create a huge production plan and blindly commit to it. We have a fixed ship date and we want to know what the quality bar is for the X number of hours of gameplay we want to ship with. Are there any empirical and iterative processes that can help?

Seems so. About a year ago I read: Lean Software Development: An Agile Toolkit for Software Development Managers. The book outlined some of the practices or tools that developers can use that are derived from manufacturing processes (such as 3M or Toyota) called lean production. Lean production is about creating production pipelines that can react to change, defects and improvements very rapidly. Much of lean production derives from Toyota's Production System called Kaizen.

Kaizen directly applies to a level production pipeline for games. Elimination of waste, just in time delivery and a focus on value stream management applies to any production pipeline.

So I was anxious to try this out. Over the past few weeks I've been learning about Value Stream Management. I've found some great materials online as well. However, the best source of information was from Michel Allard, the new "Chief Process Officer" for Vivendi Games. He actually had a great deal of experience with Value Stream Management and came down for a day to help us map out our level production value stream map (VSM).

One rule of thumb for VSMs is that you'll discover that 85% of the work done does not add value! This means that theoretically you could reduce 85% of the cycle time for producing a level. This doesn't necessarily mean you can produce ~six times as many levels, but it points out where you can work on getting the biggest improvements. There are some obvious ones, such as division of labor and reducing the time of one step through an improved tool. There are others, such as approval iterations, that can be improved through better education and communication.

By the end of the day, we had identified steps to achieve a 50% reduction in the amount of cycle time per level. Not bad. Going forward, the benefit for the VSM is to produce a great deal of transparency in each of the dozens of steps and give a great deal of ownership for improvements to the people doing the work. Those are very "Agile" improvements!