Book Review: Implementing Lean Software Development

Implementing Lean Software Development: From Concept to Cash

We've been applying some lean principles to game production recently during production. The results have been great and I have been returning to this book time and time again.

Lean
I've been reading about Lean for several years. It doesn't have as much of a defined set of practices like Scrum or XP. It has a very solid set of principles that can drive a wide range of practices over any type of product development and manufacturing effort. This made it particularly appealing for game development. Developing a game involves not only product development but also a production line effort to create the content for 8-20 hours of gameplay.

I’ve enjoyed reading anything that Mary and Tom Poppendieck write or say about Lean. Their writing is dense with value but easy to read. Their lean books tie in all the principles with great examples and historical perspective.

Overview
I’ll go over the main sections of the book. Although the book addresses software development, there is a lot there for people who want to work with content creation as well (producers, art and design leads, etc).

History of Lean
The book starts with the historical background of Lean in manufacturing, how the efficiencies created in the United States to ramp up war production met the philosophy of Sakichi Toyoda and his decedents as their family business evolved into Toyota Motors. The resulting Toyota Production System created a “just-in-time” workflow and “autonomation” or “automation with a human touch”. Toyota has extended this system to their product development side as well. The result is that Toyota, using their development and production systems, has become the world’s most successful car manufacturer.

Coined “Lean” in 1990, many of Toyota’s methods have been copied world-wide. There have been a number of books about the "Toyota Production System".

Principles
The chapter starts with a definition of principles: “principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation”.

Any book on “Implementing Lean” has to start with the principles. Mary and Tom define seven:

• Eliminate Waste - Not only work done wrong, but work that shouldn't have been done at all.
• Build Quality In - Don't fix it at the end. Build quality in as you create features.
• Create Knowledge - In your organization, about your product and your market.
• Defer Commitment - Make irreversible decisions as late as you can. Keep your options open.
• Deliver Fast - Give your customers something quickly. Continually iterate.
• Respect People - The people building the product know best how to improve the process. Create a culture where continual improvement comes from everyone.
  
• Optimize the Whole - Local optimization actually makes the whole less effective. Use tools such as "Value Stream Maps" to visualize how everything flows and optimize there.

From there the book's chapters focus on the following key aspects of implementing Lean Software Development. I'll briefly describe each.

Value
How do you align your development progress and decision making closely with the value you are delivering to your customer? This chapter has a number of stories about companies and products that continually succeed at delivering value. Towards the end of the chapter it touches on leadership, team and development principles for doing this.

Waste
This chapter is one of the core chapters of the book. It covers the seven wastes as defined by the Toyota Production System (and their parallels in software development) and introduces "Value Stream Maps" which are an effective tool in mapping out your process and identifying waste.

You'd think that "waste" is pretty easy to define, but the seven wastes show that it can come in many forms. Focusing on waste and eliminating it is the core of Lean.

Speed
Speed is about delivering fast. It is defined by the absence of waste. If you practice Scrum, this chapter is an especially good read to see how the underlying theory of Scrum and Lean have the same roots.

People
The book Peopleware by Tom Demarco is one of the bibles that anyone working on games should read. This chapter reflects much of the wisdom and common-sense of Peopleware as applied to Lean.

Knowledge
One of the most valuable assets that you have is knowledge:

• Knowledge of your technology
• Knowledge of your tools and process
• Knowledge of your market
• Knowledge of what you are making

The question of "how we build knowledge in a company" is a big one, especially to a game development company: How do we make decisions about features? How do we decide which technology to pursue? This chapter is focused more on specific examples and practices that have worked for other companies. The key is to finding own practices for your organization. Anyone familiar with the principles of XP (Extreme Programming) will be familiar with the principles being expressed in this chapter as they apply to building knowledge.

Quality
How is quality built into a lean development effort? It's built by addressing it continually using an iterative process and by being disciplined in doing the extra work required.

This chapter starts with the example of the Polaris Submarine Project. The Sputnik launch convinced the US that the Soviet submarine missile threat was imminent. As a result the US successfully moved a deadline to build the first US missile carrying submarine from 9 years to 2.5 years. How was this done? By abandoning the big plan and then using vertical slices and iteratively prioritizing features that the customer (the US) valued the most. Although the Admiral in charge of the project knew nothing about Lean, he applied many of the same principles to the project. Unfortunately these lessons were lost on most subsequent defense projects and are still not applied today.

The chapter discussed some of the Japanese practices that have been adopted for quality and how team discipline is critical to making sure that quality is part of the daily effort. Once again as you read about this you see the strong roots of practices in Scrum and XP.

Partners
This chapter addresses how the lean organization works with partner organizations (such as Boeing and its suppliers). The information here was interesting when you apply it to how the game industry is using more and more outsourcing. The best point made was that the value stream needs be simplified as much as possible before outsourcing parts of it (or all of it). It seems as though the game industry outsources a lot of work that is done the wrong way. If you address the value stream first, you may not need to outsource at all.

Journey
The final chapter summarizes the book, takes a look at some of the other initiatives that have been used (Six Sigma and the Theory of Constraints) and ends with some solid advice on how to start using Lean.

Recommendation
I'd highly recommend this book to anyone who has been using agile to develop a video game. The principles of Lean are directly applicable to all aspects of development and production.

As we explore fitting game development under the agile umbrella, we find that different practices have different coverage. Scrum has a great set of multidisciplinary practices that cover preproduction very well, but may not have complete coverage for production. XP practices are great for all of the development cycle, but only for the programmers on the team. Lean inspired practices for preproduction and production hold the potential of covering much of what we may lack in content production. It makes sense based on the production roots of Lean with Toyota.