A couple of weeks ago ago I posted the question “Are you overproducing improvements?” and compared a typical improvement “blitz” with a large monument machine that produces in large batches.
I’d like to dive a little deeper into some of the paradoxes and implications of 1:1 flow of anything, improvements included.
What is “overproduction” – really?
In the classic “7 wastes” context, overproduction is making something faster than your customer needs it. In practical terms, this means that the cycle time of the producing process is faster than the cycle time of the consuming process, and the producing process keeps making output after a queue has built up above a predetermined “stop point.”
If the cycle times are matched, then as an item is completed by the upstream process, it is consumed by the downstream process.
If the upstream process is cycling faster, then there must be an accumulation of WIP in the middle, and that accumulation must be dealt with. Further, those accumulated items are not yet verified as fit-for-use by the downstream process that uses them.
The way this applies to my “Big Improvement Machine” metaphor is that we are generating “improvement ideas” faster than we can test and incorporate them into the process.
“Small Changes” Doesn’t Mean “Slow Changes”
No matter how good your solution or idea, it is just an academic exercise until it is anchored as the an organizational norm. The rate limit on improvement is established by how quickly people can absorb changes to their daily, habitual routine.
Implementing and testing small changes one-by-one is generally faster than trying to make One Big Change all at once. When we do One Big Change, it is usually actually a lot of small changes.
I hear “we don’t have time to experiment,” but when I ask what really happens if a big change is made, what I hear almost every time is they had to spend considerable time getting things working. Why? Because no matter how well the Big Change was thought through, once you are actually trying it, the REAL problems will come up.
Key Point #1: Don’t waste time trying to develop paper solutions to every problem you can imagine. Instead, “go real” with enough of the new process to start revealing the real issues as quickly as possible.
In other words, the sooner you start actively learning vs. trying to design perfection, the quicker you’ll get something working.
Slow is Smooth, Smooth is Fast
Your other objective here is to develop the skill within the organization to test and anchor changes quickly, as a matter of routine. This will take time.
When we see a high-performance organization making rapid big changes, what we are typically seeing is making small changes even more rapidly. They have learned, through practice over time, how to do this. It isn’t reasonable to expect any organization to immediately know how to do this.
Key Point #2: If managers, or professional change agents (internal or external consultants, for example) are telling people exactly what to do, this learning is not taking place.
It is critical for the organization to develop this learning skill, and they are only going to do it if they can practice. Learning something new always involves doing it slowly, and poorly at first. If your internal or external consultants are serving you, their primary focus is on developing this basic competence. Their secondary focus is on getting the changes into place. This is the only approach that actually strengthens the organization’s capability.
The same is true for an operational manager who “gets” lean, but tries to just direct people to implement the perfect flow. It will work pretty well for a while. But think about how you (the operational manager) learned this stuff: Likely you learned it by making mistakes and figuring things out. If you don’t give your people a chance learn for themselves, you limit the organization in two ways:
- They will never be any better than you.
- They will wait to do what they are told, because that is what you are teaching them to do.
Think about what you want your people to be capable of doing without your help, and make sure you are giving them direction that requires them to practice doing those things. It will likely be different than telling them what they layout should look like.
Improve your Cycle Time for Change
Coming back to the original metaphor, if you want fast changes to last, you have to work speeding up the organization’s cycle time for testing improvement ideas. Part of this is going to involve making that activity an inherent and deliberate part of the daily work, not a special exception to daily work.
Part of that is going to be paying attention to how people are working on testing their ideas. The Improvement Kata and Coaching Kata are one way to learn how to deliberately structure this work so that learning takes place. Like any exponential curve, progress seems painfully slow at first. Don’t let that fool you. Be patient, do this right, and the organization will slingshot itself past where you would be with a liner approach.
Small changes, applied smoothly and continuously become big changes very quickly.
