(This text was written collaboratively by some of the people named at the bottom. Special thanks to Yuval Yeret!)
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.
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”.
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
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!
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?”
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?
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.
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”.
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.