Home > Knowledge Center> The Birth of Lean: How Practices, Principles, and Tools Came Together as a System

The Birth of Lean: How Practices, Principles, and Tools Came Together as a System

Balle, Michael

The Birth of Lean is a fabulous book: an absolute “must read” for any lean practitioner. It holds the key to a profound issue in lean implementation: the link between the principles, the tools and the underlying management practice. Indeed, Jim Womack described the evolution of the lean movement as different “ages:” first, the search for the basic principles of lean, as illustrated in the seminal Lean Thinking, then the detailing of the tools, such as can be found in the various workbooks, starting with value-stream mapping in Learning to See, and finally, an exploration of the management techniques required to make lean principles and tools stick, as with A3 management, explained in John Shook’s Managing to Learn. As lean practitioners progress in their lean journey, they tend to be predominantly interested in either of these aspects of lean. Yet, experience on the shop floor shows that successful implementation often rests on the proper combination of all three -- principles, tools and management practices -- as Freddy Ballé and I have tried to illustrate in The Gold Mine.

Fundamental Questions

Fifteen years ago, I came to study lean from a slightly peculiar perspective, that of my own original field, theory of knowledge. I got interested in the lean movement as the constitution of a brand new body of management knowledge essentially built on the “translation” of Toyota’s unique industrial experiment in other environments – as many people tried to interpret, adapt, and reproduce what Toyota did in their own companies. So far, fully integrated reproductions of Toyota’s approach to designing, marketing, and producing remain few and far between, but numerous lean efforts have created a wealth of experimenting and learning as adaptation attempts moved out of manufacturing to touch the full enterprise, and out of automotive to spread in fields as diverse as healthcare, services, or software development. Yet, throughout this vast expansion, the same questions keep popping up: how “lean” is our lean? How do we get sustainable results beyond the low hanging fruits? How do we create a “true” lean culture? And so on. In reading the candid and often vivid stories of Toyota’s early struggles with lean in The Birth of Lean, I believe that several answers can be found to these fundamental questions.

No Map or Manual

I first encountered the Toyota Production System as I studied one of Toyota’s first attempts at supplier integration in Europe in the early nineties. A team of Toyota engineers from the Burnaston plant would visit regularly a production cell at suppliers and work with their engineers and operators to apply TPS, under the occasional supervision of “sensei” from Toyota’s headquarters. The sensei would look at the cell, make very generic observation and conclude their visit by repeating general principles such as “the water and the rocks” and so on. The European engineers would then attack issues progressively with very specific analysis frameworks – how to make this calculation, how to look at this situation. These would later been recognized as “tools.” As the cell evolved continuously, becoming “leaner” every month, I kept asking the Toyota consultants about their blueprint for implementation. Like most people at the time, I was persuaded they had an implementation roadmap, which they applied step-by-step, making the cell evolve accordingly. I got increasingly frustrated by their constant refusal to share this “manual.” They kept claiming they did not have an implementation manual. All they did, they said, was solve problems one by one, as they appeared.

It took me a while to take their answer at face value. It was all the more difficult to accept that, generally, they seemed to know clearly where they were going. This was no random walk. But when I finally did, I found I had not progressed much: what problems? Solving them in what way? Clearly, what the Toyota engineers considered to be a problem differed widely from what the supplier manufacturing engineers thought was a problem. And just as clearly what the Toyota engineers considered an acceptable solution was seen as wildly unrealistic by their counterparts. This led me to formulate a working definition of “mental models” as a set of “typical problems, typical solutions” applying in given situations. And just as frustrating, the Toyota engineers could not explain to me how they went about it. “You’ve got to do it to understand,” they’d say. So I did. I started experimenting with various people how to implement TPS by solving problems one by one rather than applying a full-fledged implementation plan.

A common claim in all the stories of The Birth of Lean is that the protagonists of Toyota’s early journey “didn’t know what they were doing” but they experimented and solved problems. Yet as we read more carefully, we find, as I did over the years, that this is both true and not. Yes, problems are tackled one by one. Yes, solutions to problems are not known beforehand – and, in that respect, this is a far cry from our usual concepts of “implementation” or “applying best practice.” And finally, yes, operators are involved at all stages of problem solving. But on the other hand, this is no “open eye” looking for kaizen opportunities either. Lean rollout is deliberate, and follows a definite direction. This is not a matter of simply walking through the processes, identifying improvement opportunities randomly and going at them. The method is disconcerting because it is different from our implicit assumptions about implementation, but there is a method nonetheless.

The implementation method, I’ve come to believe, is about consistently linking lean management practices, principles, and tools. And it does start with management practices. To oversimplify, I’ll sum up lean management to: going to the shop floor (no other conversation makes “lean” sense), challenging teams to solve their own problems and work with other functions (mutual ownership of problems) and to do so through kaizen (short cycles of improvement). There is no preset “roadmap.” The boss or sensei goes to the shop floor to observe operations with the local management, sets a challenge (“reduce this buffer by half”) and lets them get on with it.

But it’s not so random as all that either. First, as it appears very clearly in The Birth of Lean, the challenges set by the sensei are not purely opportunistic. In fact they follow strictly the key principles of lean. First is “value”, or, to put it in shop-floor terms, point-by-point confirmation. work cannot progress from one station to the next without a clear confirmation mechanism that stops non-quality from moving downstream. One of the main points which comes out clearly in The Birth Of Lean is that total quality control at Toyota was a pre-requisite to applying TPS. In one way or other each of the texts presented insist on how they first tackled quality problems because without that there was no point in trying to improve the flow operations (why try to flow bad parts quicker?). TQC at Toyota was not independent of TPS by any means. Indeed, one commentator describes Toyota’s approach to quality as “TQC without the paperwork.” The first principle clearly applied in any circumstances is “stop at the first defect” and then decide what to do.

Then came just-in-time as specifying value streams with clear multi-process cells, flowing parts by putting stocks at the right place (no parts outside of the flow: all parts are held at the process that produces them) and finally pulling with kanban card (a box is withdrawn from a shop stock with a withdrawal card, and a box is produced to refill a shop stock with a production card.) Getting all parts to flow within the process is not “lean” – it’s a second pre-requisite to “leaning” the process. The key insight is that the sequence of problems to be resolved will be dictated by reducing the amount of inventory in the system. To be able to do so, however, all parts used in the value stream must be visible within the flow. As soon as some work-in-process is held in storage somewhere, one loses the visibility of what happens in the flow and what impacts problems really have. The Birth of Lean is very demonstrative in this respect: kanban is a tool of kaizen, not the other way round. The relationship between kanban and kaizen was difficult for many to understand, even within Toyota, but one account in particular show the dawning of the understanding that kanban (the original “Ohno system”) is the key to steering continuous improvement. When all inventory is held at the cells, and conveyance and production are regulated by kanban, “challenge” takes the form of “cut the inventory by half” because people will see immediately what key problems will emerge.

Finally, once the basic principles of value, value streams, flow and pull are in place, “challenge” drives towards perfection through kaizen by using rigorously the tools. Pulling processes both with jidoka and just-in-time and then reducing the number of kanban cards creates some specific problems of manpower, materials, machine or method – not the least, the proportional cost of changeovers when one increases the number of production changes to reduce the batch sizes in order to cut the inventory buffers. Yet, here again, these problems are not tackled randomly. These specific, known problems are attacked through well-defined tools such as SMED, standardized work, 5S, TPM and so on. The tools are not there to be applied randomly to any opportunity, but specific analysis methods to tackle specific issues in the flow as one challenges on either confirmation or inventory. These tools are designed so that the operators themselves (with the support of their frontline management) can tackle the problems highlighted in the process. Team leaders can conduct 5S, analyze production changes with SMED, take times to rebalance a line, or analyze standardize work with the people on the cell.

The Birth of Lean is essentially about TQC, kanban and kaizen. But as one reads through how the stories develop, one can see a profound structure of:

  1. Challenging by senior management or sensei
  2. on highlighting problems through the prism of the basic principles of lean
  3. to be solved by the teams themselves by the rigorous use of the tools

This, I believe, is the essence of lean’s unique approach to implementation. There is no roadmap as such, but a specific learning cycle: challenge, principles, tools, challenge, etc; such a reading of The Birth of Lean can have several far-reaching implications.

Firstly, I feel this highlights Toyota’s revolutionary approach to knowledge creation. This is no longer thinking on one side and executing on the other, but a continuous process of challenging, experimenting and learning. Vision here is not a destination, but a few key high-order problems we need to resolve to get ahead on our markets. Execution is not about applying what has been developed elsewhere, but relentlessly using the analysis method which has given good results elsewhere, in the spirit of kaizen – small, rapid improvement cycles.

Secondly, this has significant implications for “lean” programs. I do not believe lean culture can be implemented by having a “lean” body of knowledge on one hand and a traditional implementation approach on the other. Lean culture is the result of acquiring lean values and lean practices. Yet many lean programs tend to be built around a traditional vision of implementation. One usually finds some sort of roadmap (tools to be implemented, by phase according to a set sequence), implementation by staff specialists who conduct training sessions and workshops, and control by an auditing structure of how “lean” the sites are – not according to their operational results but to their implementation of the roadmap. By contrast, The Birth of Lean shows how senior managers have acquired a deep understanding of the principles and relentlessly challenge their operational line to solve the corresponding problems rigorously. This is a radically different sort of lean program, where the priority is getting a sensei to work with senior executives and define short-term and mid-term challenges to be resolved in a “lean way” (no investment, and applying the tools properly). Certainly, this requires some initial training to the tools at shop floor level, but the emphasis is on maintaining the kaizen pressure to resolve problems one by one.

Finally, the reading of The Birth of Lean also explains a fact of lean implementation – it only works where senior management is fully committed. It turns out that it’s not the “commitment” as such that makes it work, but senior management’s acquisition of the lean attitude and practices, which, rolled out through the operational line to the work cells, creates lean results by “leaning” each process one after the other. As long as senior management doesn’t see the profound value of point-by-point confirmation, of rolling out pull systems with kanban cards as quickly as one can (messy doesn’t matter), and of leaning processes relentlessly through kaizen, the translation of TPS into lean at one’s own company remains disappointing. The effort is there, the tools are audited, but the results remain elusive. The profound lesson of The Birth of Lean is, to my mind, that any company that wants to do lean must consider deeply how it’s going to handle the link between management practice, lean principles and lean tools. At the gemba.

About Michael Ballé
Michael Ballé, Ph.D., is the co-author with Freddy Ballé of, The Gold Mine, a best-selling business novel of lean turnaround, and The Lean Manager, a novel of lean transformation, both published by the Lean Enterprise Institute. Both books are winners of Shingo Research and Professional Publication Awards.