Real lean vs. fake lean
Dear Gemba Coach,
I am a lean consultant who is totally dedicated to applying the lean principles. Unfortunately most lean gurus who I encounter seem to look down on our work. They argue that consultants like me don’t do “real” lean. Where do you weigh in on this? Are they being too snobby? Should I work to be more authentic in my practice?
This is a very good question, but rather above my pay grade, and typically, this is why we need senseis. Have you got one?
You see, this question touches upon several different principles of lean practice and lean learning. And ultimately much of the answer depends on your personal point of view. First, let me latch on to the idea of applying lean principles. On paper, this sounds clear and simple. The rub is that lean is a practice, as my father keeps repeating, and not a theory. This means that “applying” the principles can be problematic.
I can’t count the times when I’ve been working with guys at the Gemba in a new situation (or, occasionally, in an old situation, which is really embarrassing) trying hard to apply a lean principle such as, say, flow, or stop-at-defect. And when I’ve shared our efforts with my father (yes, I know, my father is my sensei – sigh!) he’ll roll his eyes and wonder what possessed me to advise this or that. But I’ve applied the principle, I complain. And then he’ll ask if I’ve noticed this. Because, in this case, the principle applies completely the other way around.
The issue here is that lean principles and goals can’t just simply be “applied,” they are interpreted, and there is usually a great need for wisdom in their interpretation. So-called “real” lean is in fact far more of a tradition than a theory. That’s why it’s so important to have a connection to this tradition and to seek to inscribe oneself within its bounds, as opposed to interpreting it as feels more comfortable. That’s why senseis are so important.
Recently, I was struggling with a completely new environment with managers who were obsessed with productivity (of course). I didn’t quite know where to start, and asked my father, who said to start as we always do: accidents and customer complaints. We did that, which uncovered a number of findings, which led to kaizens to improve operator ergonomics. I had told the managers that they should see productivity results show up as they improved the ergonomics of their working cells. When this did not happen, I couldn’t figure out why and discussed it again with my father. Are the operators stabilized in one zone, he asked? Or are they moved around across the plant for flexibility’s sake? I went back to the Gemba to check, and of course found out that operators could be moved from one station to another within the day according to the MRP- calculated work orders. As long as a team of operators doesn’t “own” a cell, and doesn’t see that they’ll get the benefits from their own kaizen efforts in their own workplace, they’re unlikely to get involved. Furthermore, productivity simply won’t progress as long as operators are isolated across the shop because any time won on a single operation cannot be reorganized in a way to gain a full person, and make real productivity improvement. Ohno, in The Toyota Production System, had explained long ago that reducing half an operator’s workload was not productivity until we could take the full person away to another job.
Upon reflection I realized that I had been befuddled both on the “respect” front (involving operators in the success of the improvements) and the “kaizen” aspect (real productivity). This “practical wisdom” for fault of a better term can only be learned through practice with a teacher. This a core issue to lean, and is why lean remains fundamentally interpretative and linked to people. Principles can be codified and are a good place to start, but without the correct interpretation, they lead to nonsensical solutions more often than not. The sensei’s opinion is the obvious test method to know whether you’re doing “real” lean or “fake” lean. And again, what can appear as nuances of a principle can end up with radically different results when you end up applying it in practice.
But what if you haven’t got access to a sensei? I’m often asked this question, and never quite sure what to answer, beyond: looking for a sensei is part of your lean journey. I realize how frustrating this answer can be, so I’ll go out on a limb and suggest some possibilities.
If you work as a consultant in production, whether manufacturing or services, then I’d say the test method is pretty straightforward: do your clients learn to see muri, mura, and muda and to reduce them?
- muri, or overburden, means making people or equipment work in unreasonable conditions. In the case mentioned above, because of my lean experience, I could see right away that operators were constantly picking up crates. This is overburden. The managers themselves considered this as normal, and inconvenient at most. But from practicing seeing with “lean glasses,” they progressively learned to see the muri for the disaster it was, and so, start doing something about it.
- mura, means any form of stop-and-go. The company in question had attacked its productivity problem by investing in many large machines. They then set up incentives for running rates of the machines. Consequently, the people at the Gemba would wait until they had enough material at hand and then run the machine as fast as possible. This is typical mura: slow, slow then fast, fast, then slow, slow. In service, mura is everywhere since customers tend to want to do the same thing at the same time: have a meal, check out from their hotel, pick up the rented car. If mura is not taken into account, it will create both muri and muda.
- muda, better known as the “wastes” of overproduction, correction, waiting, motion, transport, inventory, overprocessing. Unfortunately, muda is often interpreted from the manager’s point of view as a drag on productivity. In the lean tradition, muda are non-value-added operations imposed on the operator. Respect for the operator means that he or she can do as much value-added work without overburden. So wasteful operations are not respectful. When you hear about the “eighth” waste (wasted creativity), you can be certain we’re talking about the managerial perspective, whereas the real challenge is to look at work from the operator’s point of view.
All in all, if you work in a production environment and as result of your consulting, frontline managers develop a greater sensitivity to muri, mura, and muda and find specific good ideas to reduce these (muda is usually the result of a combination of muri and mura), you can be confident you’re doing something right. In my experience, a lot of muri can be seen at the preparation and planning stages and can be avoided proactively. mura is more about eliminating fluctuation at the operational level. muda tends to show up when the process is in place and seen by variations in output which can then be analyzed in terms of muri and mura of the system. I’ve been taught that management’s role is to continually self-examine operations in order to provide and improve a flexible system and connect the workforce to the customer.
But what if you’re not in a production environment? What if you try to apply lean in a completely new setting, such as IT, where there is no lean tradition? This is a discussion I recently had with Steve Bell, co-author of the great book Lean IT: Enabling and Sustaining Your Lean Transformation. We concluded that it’s tricky, but the spirit of PDCA still applies, and your question is still totally valid: how do I test my ideas?
In developing lean beyond the original field of automotive production, its pioneers such as Jim Womack, Dan Jones, John Shook, Jeff Liker and others have consistently tried to test their ideas in two ways:
- Testing the “Toyota-consistency” by discussing the idea in question with senseis, and listening carefully to their reactions. Typically, senseis will not want to have an opinion outside of their area of expertise, but they can’t help reacting to any new notion. Their reactions are often based on Toyota tradition and not necessarily easy to specify, but it’s the intent to understand that matters – our collective will to recognize that Toyota has opened a different management path that we need to capture that counts.
- Testing the idea in real-life by experimenting live with your clients, and making sure that they understand clearly what is being tested (Plan) and how we’re going to do this (Do) how we’re going to test it (Check) and what kinds of conclusions we can expect (Act).
I’m not sure whether this answers your question, but from talking to the gurus over the years, I can tell you that what really gets their goat is applying lean without the PDCA spirit: the certainty that such and such principle applies and that’s that. Lean is not a religion, its applying scientific practice to the realm of business. Whenever I pontificate about any lean topic, or worse, consulting success, which is frightfully easy to do, I find that they just stop listening. On the other hand, the lean gurus I know are always ready to discuss ideas and experiments and debate against real life experience or Toyota traditions. On balance, I’d argue that lean gurus don’t especially look down on consultants or their work, but are unimpressed by the cookie-cutter approach of most consultants. If there is one common theme that binds all “real” lean practitioners it is turning the PDCA wheel. I’m willing to bet that if you frame your questions in that way the lean gurus will be as patient (and forgiving) with you as they’ve been with me!
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?