In this year's Kanban Leadership Retreat in Mayrhofen we had an interesting Session on Pull. The basic question we wanted to answer was: “What the F*** is Pull?” You might wonder why a group of Kanban practitioners should discuss such a basic concept like Pull which is really at the core of Lean and Kanban. Well, what we discovered was that there are different understandings of Pull.
We started the session by gathering our understandings of what “Pull” and “Push”means to us. The answers were quite different - ranging from “Optimize Flow” to “Decide by yourself”.
After this exercise, we discussed different possibilities of grouping all the sticky notes. We ended up with two groups and the idea that “Pull” could mean quite different things to people. On the one hand people mean a Pull System when they say “Pull”. A Pull System is basically every system with a WIP-Limitation. So as soon as we agree to limit our system to, let‘s say, 10 tasks at a time and we only start a new task as soon as we finish an old task, we‘ve created a Pull-System. That is one of the basic concepts of Kanban and pretty much Lean in every possible shape. In this sense a lot of the statements we collected make very much sense, i.e. “Think from customer”, “Make or move an item only when needed”, “Long term focus on balancing work to capacity”, or “Start work an available capacity”.
But what about some other statements like “Some kind of choice”, “I decide when I take over the task”, or “Decide by yourself what to work on”? These are quite different notions of Pull, they have to do with responsibility and freedom of choice. And you could have a Pull-System with or without these implications.
So after discussing these different notions we ended up with what we called Pull Behavior. Pull Behavior means that choices of when people pull a new item and which one they pull are being decentralized. So everyone in the workforce is empowered to decide by himself when he‘s ready to pull a new item. And he or she is also empowered to decide which one to pull - based on policies the team had agreed upon. The main policy for pulling tasks might be “First in first out (FIFO)” as well as “Highest business value first” or “Decide by yourself which one you think is appropriate”. So this is where the freedom of choice comes in. And here (again) we see how important process policies are!
If we agree that there‘s a difference between a Pull System and Pull Behaviour, the interesting questions are:, “Can we have a Pull System without Pull Behaviour?”, and “Does the Kanban Method specify a Pull-System, or Pull Behaviour, or both?”
After some really interesting questions, we came to the conclusion that it is possible to have a Pull System without Pull Behaviour, i.e. one person or a tool telling people when they should pull the next item (and which one) based an the fact whether the system has free capacity or not. Yes, this could work. Yes, it could be a good first step in the right direction. And Yes we would call this a Kanban-Implementation. We also felt very awkward about this. Where are the humane aspects in this? Is Kanban really aligned with a Control culture?
We came to the conclusion that the awkwardness comes from the fact that the people in the room, the event, and the Kanban community in general mostly come from an agile-thinking background which means we are very oriented towards collaborative empowering systems rather than controlling systems. We also agreed that the Kanban Method can be applied in a Control-heavy culture to improve the flow of work but that one of the properties that will emerge in the long run will be a more and more collaborative culture driven by the Pull System and by the scalability limits to Centralized Pull decisions. We also made a mental note to re-emphasize emerging properties of successful Kanban systems in future writing and discussions.
It should be emphasized that both system-level Pull and Pull behaviour are an analog dial. One of the features of the Kanban Method is that Pull Behavior can be decentralized little by little using safe-to-fail experiments (e.g. from central Project Manager to Function Managers to Function Managers consulting with the individual people all the way to fully decentralized pull). Also different behavior can be specified for different kinds of work (e.g. Expedites are centrally pulled while normal work can be completely decentralized). This is really an enabling factor for an evolution towards collaboration while avoiding the feeling of “losing control” of the system - yet another example of “respecting where you are” and slowly nudging you towards “where you might want to be”.
To sum up, We respect whatever state systems start with But in the long run we definitely want to see Pull Behaviour, because we believe that without empowerment there will be no real Kaizen!
Thanks to everyone who contributed to this discussion, especially Nina Schwab, Chris Mc. Dermott, Russell Healy, Yuval Yeret, Maarten Hoppen, Keith Mitchel and Zhanna Bogomaz.
No comments:
Post a Comment