Dear Gemba Coach,
As a practitioner and advocate of design thinking, I’ve been curious about lean, but it seems to me we’re talking about the same thing: essentially developing a PDCA mindset in people. Isn’t that the case?
Well, yes and no. At the end of the day, the mind is the mind, and all methodologies are about making a better use of our minds, so all methodologies will have elements in common. Certainly, PDCA will appear in most modern approaches. Yet, as a former design thinking disciple myself (my first book was on systems thinking, and my first job designing and simulating complex systems with feedback loops), I would try to emphasize a deep difference in outlook.
Traditional western thinking is about thinking yourself into a new way of acting. Lean thinking is about acting yourself in a new way of thinking.
Yes, yes, I know this might sound zen-ish and koan-like, but please bear with me – I’d have to be a much better writer to make this difference crystal clear, so I’ll just put my head down, bash on, and muddle through.
Most interpretations of Deming’s PDCA cycle I come across are the following, as I’m sure you’ll agree:
- Plan: I intend to do something, so I define the challenge and plan how I’m going to address it.
- Do: I execute the plan.
- Check/Reflect: I measure and check the results and then,
- Act: I draw conclusions in terms of what to continue, what to adjust, what to adopt and so on.
However, let’s look at this presentation of PDCA from Deming’s own hand:
He is not talking about doing something new, but about changing something to an existing process. The focus is not to start from scratch, the blank page, but to start from what is already there and tweak it. And then it says: “run the cycle again, possibly under different environmental conditions.”
You might feel I’m stretching and belaboring a point, but we’re looking at a very deep, set, hidden assumption about learning here: Is learning an event or a process?
Still Learning Kanban
Our casual theories of learning assume that we study something and at some point, we get this aha! moment where we “get it” and then we move on to “learn” the next thing. We tend to assimilate learning to understanding. The assumption is that you create a new connection in the brain, change the wiring, and now you “know” something new and it’s up to you to act upon it. Learning is an event because subjectively, this is how it feels. I’m sure you can remember specific instances when you “got it.”
In this case, in order to teach, we do what we do to our kids. We present the same problem in a similar situation and ask them to learn by rote then try the exercise until they can master it – and then move on. Once the “learning event” has occurred, we can tackle the next one.
On the other hand, I discovered kanban in 1994, and I’m still trying to wrap my mind around it – granted, that probably says I’m a bit slow – but it also uncovers a completely different assumption about learning, as a process, rather than an event. In this perspective, learning is about familiarization with an object, an idea, a technique. Rather than go after the learning event, we’ll look at what we want to learn, repetitively, in different varied contexts until we get a diffuse but robust sense of what it is all about.
This brings us to two very different approaches to design.
Say you want to design a new car model. The design thinking way is to:
- Define the challenge of the car in terms of which segment of drivers you want to attract
- Research what this target audience would really want in their own context
- Detect patterns in the data
- Come up with insights and creative ideas
- Prototype them and come up with a simulation
- Test as much as you can until you commit to the design
Or …
You start with an existing car model – say the current 11th generation of the Corolla (11!) and you ask yourself a completely different question: what should I keep that makes the Corolla a best-selling car and what should I change so that it stays in the spirit of the time. You will then try to talk to as many people as you can that drive the existing model, as well as drive competing cars and capture the zeitgeist and not come up with a design, but with changes to the existing design – a different concept.
In one case, you’re trying to have a complete, clear new design set in your mind. In the other, you’re trying to be clear about what remains as is, what you intend to change and how these two will interact in practice. Very different.
Similarly, in design thinking, once you’ve clarified the innovative design you want, you’ll be tempted to look for innovative processes to make it so. In lean, you’ll start by spending time in production to see how current problems in making the current Corolla have been solved, what new problems people are working on, and what impact this has on the changes you have in mind.
Many Similarities
Obviously, I’ve accentuated the differences in the thinking. Clearly, in real life, this is far more of a yin-yang process as we will both think through radical concepts as well as incremental change. The mind is the mind, and it needs to see the full picture as well and organic modifications – both are important.
But whereas at the methodological level all seems the same, in terms of – (1) have an idea, (2) check it with others, (3) prototype it, (4) check the results, (5) adapt it until it works – the actual source of knowledge and learning is very different in design thinking and in lean thinking. Design thinking is about, well, design, whereas lean thinking is about familiarization through try and see, try and see.
The funny part is how much of a design thinker I still am after all those years. Occasionally, I’ll write a paper about lean – a design paper that explains lean in broad generic terms and makes wild claims about its world-changing importance (which, by the way, I am honestly and fully convinced of). Whenever I show these to Japanese sensei, the typical answer will be, “I started reading your article, but it is too sophisticated for me and unfortunately I cannot make any meaningful comments on it.”
Which is a very polite way of telling me I’ve lost my way, and I’m in full design thinking mode and very far from the craftsmanship of daily kaizen.
Yes, there are many similarities between design thinking and lean, in particular, the passion to understand how people interact with products and services in their contexts in real life, and then testing ideas through quick prototyping and testing. But the underlying paradigms are radically different:
- To unlock new markets and identify strategies, design thinking focuses on imaginative, human-centric problem solving to come up with better ideas, test them and bring them to market.
- To retain current customer’s business in evolving times, lean thinking focuses on what changes need to be made to what we already do by solving immediate problems for customers now and drawing the wider conclusions from knowing both the product and the delivery process inside out in its finest details.
Again, I am not arguing one over the other – I believe we should do both. Toyota certainly follows both approaches as can be seen by their radical concept of its e-palette as a connected mobility platform at this year’s CES show. The point here is understanding the profound difference between the approaches so as use them both as best we can rather than a weak hodgepodge middle ground that won’t help us much other than confusing issues.
In the end, we’re back to the eternal question of seeking salvation in breakthrough thinking – and then applying it – or in daily kaizen and then discovering breakthrough through making small real changes in how we work day-to-day. Both I suspect. But seeking breakthrough thinking changes is something we’re familiar with, whereas kaizen is something we have to re-learn every day, therefore I suspect it has the far greater potential for real improvement.
