This chapter is from the book

Lean

In 1990 the book The Machine That Changed the World9 gave a new name to what had previously been called Just-in-Time or the Toyota Production System. From then on, Toyota's approach to manufacturing would become known as Lean Production. During the next few years, many companies attempted to adopt Lean Production, but it proved remarkably difficult. Like all new industrial models, resistance from those invested in the old model was fierce.

Many people found Lean counterintuitive and lacked a deep motivation to change long established habits. Quite often companies implemented only part of the system, perhaps trying Just-in-Time without its partner, stop-the-line. They missed the point that, "The truly lean plant…transfers the maximum number of tasks and responsibilities to those workers actually adding value to the car on the line, and it has in place a system for detecting defects that quickly traces every problem, once discovered, to its ultimate source."10

Despite the challenges faced when implementing a counterintuitive new paradigm, many lean initiatives have been immensely successful, creating truly lean businesses, which have invariably flourished. Lean thinking has moved from manufacturing to other operational areas as diverse as order processing, retail sales, and aircraft maintenance. Lean principles have also been extended to the supply chain, to product development, and to software development. See Figure 1.4.

Lean Manufacturing/Lean Operations

Today lean manufacturing sets the standard for discipline, efficiency, and effectiveness. In fact, using lean principles in manufacturing often creates a significant competitive advantage that can be surprisingly difficult to copy. For example, Dell Computer's make-to-order system routinely delivers a "custom-built" computer in a few days, a feat which is not easily copied by competitors unwilling to give up their distribution systems. Lean has moved into nonmanufacturing operations as well. Southwest Airlines focuses on transporting customers directly from point A to point B in relatively small planes, while competitors can't easily abandon their large-batch oriented hub-and-spoke systems. A few industries, such as rapid package delivery, have been structured based on lean principles, and in those industries, only companies with lean operations can survive.

Lean Supply Chain

When lean production practices reach the plant walls, they have to be extended to suppliers, because mass production and lean manufacturing do not work well together. Toyota realized this early, and helped its suppliers adopt the Toyota Production System. Peter Drucker estimated that Toyota's supplier network, which Drucker calls a Keiretsu, gives it a 25 percent to 30 percent cost advantage relative to its peers.11 When Toyota moved to the United States in the late 1980s, it established a similar supplier network. Remarkably, US automotive suppliers often have lean sections of their plants dedicated to supplying Toyota, while the rest of the plant has to be run the "traditional" way because other automotive companies cannot deal with a lean supplier.12 A lean supply chain is also essential to Dell, since it assembles parts designed and manufactured by other companies. Through "virtual integration," Dell treats its partners as if they are inside the company, exchanging information freely so that the entire supply chain can remain lean.

In lean supply chains, companies have learned how to work across company boundaries in a seamless manner, and individual companies understand that their best interests are aligned with the best interests of the entire supply chain. For organizations involved in developing software across company boundaries, supply chain management provides a well-tested model of how separate companies might formulate and administer lean contractual relationships.

Lean Product Development

"The real differential between Toyota and other vehicle manufacturers is not the Toyota Production System. It's the Toyota Product Development System," says Kosaku Yamada, chief engineer for the Lexus ES 300.13 Product development is quite different than operations, and techniques that are successful in operations are often inappropriate for development work. Yet the landmark book Product Development Performance14 by Clark and Fujimoto shows that effective product development has much in common with lean manufacturing. Table 1.1 summarizes the similarities described by Clark and Fujimoto.

Simultaneous improvement in quality, delivery time, and manufacturing productivity

Simultaneous improvement in quality, development time, and development productivity

If any company can extract the essence of the Toyota Production System and properly apply it to product development, Toyota would be the top candidate. So there was no surprise when it became apparent in the late 1990s that Toyota has a unique and highly successful approach to product development. Toyota's approach is both counterintuitive and insightful. There is little attempt to use the manufacturing-specific practices of the Toyota Production System in product development, but the underlying principles clearly come from the same heritage.

The product coming out of a development process can be brilliant or mundane. It might have an elegant design and hit the market exactly right, or it might fall short of both customer and revenue expectations. Toyota products tend to routinely fall in the first category. Observers attribute this to the leadership of a chief engineer, responsible for the business success of the product, who has both a keen grasp of what the market will value and the technical capability to oversee the systems design. In the book The Toyota Way,16 Jeffrey Liker recounts the stories of the development of the Lexus and the Prius, emphasizing how these breakthrough designs were brought to market in record time under the leadership of two brilliant chief engineers.

Product development is a knowledge creation process. Toyota's Product Development System creates knowledge through broad exploration of design spaces, hands-on experimentation with multiple prototypes, and regular integration meetings at which the emerging design is evaluated and decisions are made based on as much detailed information as possible. The tacit knowledge gained during both development and production is condensed into concise and useful one-page summaries that effectively make the knowledge explicit. Generating and preserving knowledge for future use is the hallmark of the Toyota Product Development System.

The National Center for Manufacturing Sciences (NCMS) conducted a multi-year study of the Toyota Product Development System, and the findings are summarized by Michael Kennedy in the book Product Development for the Lean Enterprise.17 In this book Kennedy identifies four cornerstone elements of the Toyota Product Development System (see Figure 1.5).

Figure 1.5 Cornerstone elements of the Toyota Product Development System18

The Toyota Product Development System

The Toyota Product Development System has four cornerstone elements:

System Design by an Entrepreneurial Leader

The chief engineer at Toyota owns responsibility for the business success of the product. He is a very experienced engineer, fully capable of creating the system-level design of the vehicle. But he is also responsible for developing a deep understanding of the target market and creating a vehicle that will delight the customers. The chief engineer creates a vision of the new product which he transmits to the development team and refreshes frequently by talking to the engineers making day-to-day decisions. He defends the vision when necessary and arbitrates tradeoffs if disagreements arise. He sets the schedule and modifies the process so everything is pulled together on time.

Expert Engineering Workforce

From the days of Sakichi Toyoda, the Toyoda and Toyota companies have always had top notch technical people designing their technically sophisticated products. It takes years for an engineer to really become an expert in a particular area, and at Toyota, engineers are not moved around or motivated to move into management before they truly master their field. Managers are teachers who have become masters in the area they supervise; they train new engineers and move them from apprentice to journeyman to master engineer.

Responsibility-Based Planning and Control

The chief engineer sets the vehicle development schedule, which consists of key synchronization points about two or three months apart. Engineers know what is expected at the next synchronization point, and they deliver the expected results without being tracked. If engineers need information to do their job, they are expected to "pull" it from its source. Recently, Toyota chief engineers have pioneered the practice of an "Oobeya" or large room where team members may work, and the whole team meets regularly. The Oobeya contains big visible charts to show issues and status.

Set-Based Concurrent Engineering

Set-based engineering means exploring multiple design spaces and converging on an optimal solution by gradually narrowing options. What does this mean in practice? It means being very careful not to make decisions until they absolutely must be made and working hard to maintain options so that decisions can be made as late as possible with the most amount of information possible. The paradox of set-based design is that this approach to creating knowledge builds redundancy into the development approach, which might appear to be a waste. However, when looking at the whole system, set-based design allows the development team to arrive at a more optimal solution much faster than an approach that closes off options quickly for the sake of being "decisive."19

Lean Software Development

Software development is a form of product development. In fact, much of the software you use was probably purchased as a product. Software that is not developed as a standalone product may be embedded in hardware, or it may be the essence of a game or a search capability. Some software, including much custom software, is developed as part of a business process. Customers don't buy the software we develop. They buy games or word processors or search capability or a hardware device or a business process. In this sense, most useful software is embedded in something larger than its code base.

It is the product, the activity, or the process in which software is embedded that is the real product under development. The software development is just a subset of the overall product development process. So in a very real sense, we can call software development a subset of product development. And thus, if we want to understand lean software development, we would do well to discover what constitutes excellent product development.

The Toyota Production System and the Toyota Product Development System stem from the same underlying principles. The first step in implementing lean software development is to understand these underlying principles, which will be discussed in the next chapter.