The common frustration in the weeks following a classic 5 day “kaizen event” (which go by many names) is that the follow-on actions are not completed, and the changes that were made erode quickly.
Recently I have asked myself why it works so well during the actual workshop, and then fades so quickly afterwards.
Mike Rother has a great graphic that starts this conversation:
The question I am exploring today (and bringing you along as I reflect on it) is “Why do the ‘lean tools’ work so much better during an event than during “business as usual?”
Hanging this on my current working theory, I think it comes down to different patterns of interaction.
What Happens During the Event
Look at how the structure of these events drives how people interact with one another.
The workshop preparation usually involves establishing a clear bigger-picture sense of the problem to be solved. Even if it isn’t specific, the team education establishes a sense of direction, typically toward 1:1 flow at takt, and a pull process that limits lead times.
The structure of the workshop itself has the team working together studying the current flows, seeing the problems for themselves, and working in pairs or small groups on proposed solutions.
Those proposed solutions are usually structured as experiments – “let’s try this.” At the end of a typical day there is some kind of structured reflection on what we tried, what we learned, what we are going to try tomorrow, and what we expect to achieve.
So – we have small groups of people, collaborating to solve a specific problem, running experiments and learning what will work.
Unfortunately the team usually comes up with more ideas than they can actually try out. Those end up on a to-do list for follow-up.
After the Workshop Week
There is a fundamental shift in the dynamics after the pizza party on Friday.
The team members go back to their regular jobs. The problems they are focused on are different. The leftover items from the workshop are added to the “stuff I need to do” list that nearly everyone in every workplace has.
Rather than continuous collaboration, there might be periodic meetings to talk about the status of these “action items.” But there isn’t specific time carved out to work on them.
If this is what happens then “Business as Usual” couldn’t be more different than the working structure that created all of these improvement ideas. Business-as-Usual is not creative, does not allow for experimentation, and is optimized for repeating what we already know vs. learning something new.
I’d like to point out here that I have seen exactly the same situation in companies that many others consider “lean” benchmarks. What I saw in those companies was a much heavier infrastructure of dedicated lean specialists who were doing the heavy lifting. It still wasn’t embedded in “business as usual.” Instead it is a parallel process that is running improvement events about as fast as the day-to-day processes erode the improvements.
In fact, to this day, after being after this for two decades, one of those companies still has to hire “lean experts” from outside. Why? What is the business-as-usual day of a supervisor that they never learn this stuff?
In summary: During the kaizen even week, we organize and interact in a way that works for creative problem solving and making improvements. Then, the next week, we stop.
It shouldn’t be a surprise that the dynamics shift from “experiment to solve the problem” to “get this stuff done.” Business-as-usual is represented by “get this stuff done.”
5 Replies to “Thoughts on Failure Modes of Kaizen Events”
Mark, insightful post. Thanks So what are the countermeasures companies have experimented with and what were the outcomes? How/what can we learn from the accurate picture you paint? How can we effectively offset the gravitational pull of Business as Usual?
Thanks for commenting – nice to hear from you.
I’ll be writing more on your question, but the short version is “What do we want the daily conversation to look and sound like?” That question is at least as important as “What do we want the production flow to look like?” We apply experiments to change the physical flow, to discover the barriers and obstacles that come up, and to work through them. The work to shift the daily habit of how people interact requires at least as much effort and focus. I think a lot of us tend to assume that the shift in conversation will follow the shift in physical flow without having to do the hard work to change it.
Looking at agile teams in product development, “things to try” will be added to the backlog as enablers that get priorized and done with all the other stuff. I assume that the organization is good at getting things done. No fault in that, because else it will be out of business soon.
And just to continue – if “getting things done” turns out to be an obstacle to progress, then *that* is what must be worked on.
Thanks for this thoughtful post and the underlying questions that you introduce. I think the problem is not so much the habits demonstrated during the “business as usual” period, but the underlying structure of the “kaizen event” itself.
I go back a way, at least with respect to the U.S. history of Lean. I started seriously experimenting with JIT/TPS in the late 1980’s. “Lean” wouldn’t show up for almost another decade. Teams and employee involvement were a center piece for any progress made in our JIT/TPS efforts, but the Lean “event”, “workshop” or “blitz” concept was not generally known at that time. Art Byrne and George Koenigsaecker of The Danaher Corporation were doing this with the Shingijutsu consultants at that time, but their work had not yet become widespread. They did 5-day events because Shingijutsu was based in Japan and were only available in the U.S. for 5 day intervals.
No, we stretched out Team efforts over several weeks and maybe several months, depending on the scope of our effort. While the Team activity was intense, 2-3 half day or full day meetings per week, they went back to work doing “business as usual” on the other days. But their Team efforts carried over during these “business as usual” periods. That’s when they tried things out or at least had time to think things over before rejoining the Team effort. And they shared the Team’s thinking with other workers and got feedback. But when the Team finally finished their work, they were finished. No list of “To-Dos” hung over their head afterwards. And they owned their work and continued to make improvements long after the formal Team was disbanded.
I operated in this manner for almost two decades with great success. I did do some “kaizen events” but only when our efforts required the participation of outside people or groups.
I tried to capture my experiences with this approach in a seven-part series on my website entitled “Teams are Us”, which starts here:
I covered the differences between this “old way of doing things” to the “blitz” approach here:
Take a look if you get a chance. Feedback would be very welcome.