Sunday, February 19, 2012

Plan-based change vs. pull-based change

Kanban is a method for driving evolutionary change (although it has several other aspects as well). In that sense Kanban is a great tool for helping teams and organizations evolving a Kaizen culture. And this is what I’m especially interested in.
As all of us know, Kaizen tends to become a buzz word and a lot of approaches (for example Lean Six Sigma) come with the promise of Kaizen. So why is Kanban different?
The first reason is Kanban‘s evolutionary approach: We start were we are and evolve from there in rather small steps. By doing so, we try to decrease the resistance to change that can be found within almost every team and organization. And we should be aware of the fact that people don’t resist change because they were cowards or stupids. They all have good reasons for doing so – based on their fears and experiences with earlier change initiatives.
But there’s a second reason why Kanban is likely to help establishing a Kaizen culture. And that is what we might call pull-based change (thanks to everyone who discussed this topic at the LKU meeting in Soestduinen earlier this week!). In „traditional“ change initiatives there’s a plan for what needs to be changed. Usually some kind of expert committee analyzes the current situation, agrees upon a desired outcome and derives a list of changes that need to be done in order to reach the destination. This approach can be called plan-driven change or pushed change. These changes are usually imposed upon the staff. This not only leads to resistance. It also denies the fact that we cannot foresee the future and that plans need to be adjusted while we move on and learn.
Kanban is different. While we do create visions and set high level goals, we do not try to determine concrete changes in advance – and we do not not impose them upon the staff. What we do instead is:
1. creating an environment were the workforce is empowered to change things themselves;
2. putting mechanism in place that make improvement opportunities evident and put some kind of pressure upon us to deal with real issues.
The beauty of Kanban lies in the fact that it does not show us random improvement opportunities, but the ones that are urgent and relevant – at the time they occur. This is what we mean with pull-based change.
How does that work? Imagine a situation, where a developer is ready to pull a new item from the input queue. He takes a look at the first one and decides that he cannot pull it because he’s lacking the special skills that are required. So he looks at the next one, but the same problem occurs – even with the third and fourth item. Because the input queue is limited to 4, he cannot pull a new item at all.

So he has slack capacity. During the next standup meeting he discusses the problem with his colleagues. They come up with two possible solutions: 1) Increasing the input queue’s WIP limit so that there might be a better chance to provide „a ticket for every specialization“ at any time. 2) Agreeing upon a policy saying that every developer with slack capacity should use this capacity to learn about the parts oft he system that lie outside of his specialization. He could do this by reading books, reading and completing the documentation, prototyping, looking over other developers‘ shoulders, pair programming with them etc. How would the team decide? We don’t know. But no matter how they decide, they are in the position to make an informed decision. They might increase the size of the input queue which would mean increasing the lead time and not dealing with their knowledge silos (which now are evident for everyone). Or they might decide to tackle the knowledge silos which most certainly would lead to less throughput during the next period of time, but on the long run should lead to more flexibility and a lower truck factor.
Two years ago I heard David Anderson saying: „Slack ist he ultimate weapon!“ First I did not really understand this, but today I completely agree: When someone has slack capacity, this not only indicates that there’s an improvement opportunity; but now this person also has the spare time to work on this improvement. What a great mechanism!
Don’t get me wrong: I do not think that putting Kanban mechanics in place will automatically create a real Kaizen culture. I know that there still is a lot of work to be done in order to get there. And depending on the context of the team or organization, the pull-based change I described might not be sufficient or too slow to get on track again. But for all teams I know, pull-based change would be a great step towards a Kaizen culture.