Justin is on vacation

I need a few days off, back in August!


In the meantime, have a look at the great conference Lean Kanban Central Europe which takes place in Vienna, October 22-23

Magic WiP Limitation

One of the most common questions I get when talking about Kanban is: „How do we define our WiP Limits?“ There are different approaches to this and I don’t think we can find a best practice for this. What I learned during the past years was:

1. There is no secret formula for setting WiP Limits. No matter what you do: The limits will be wrong at the beginning and need to be adjusted. And they need to be adjusted anyway every now and then, because the team should improve and the system should change over time. So we shouldn’t put too much effort in setting the initial limits.
2. It’s very important that the whole team is involved in designing the board – and part of this is setting the limits. It should be a collaborative process and everybody should have the chance to voice his opinion. Otherwise acceptance might be lower than it could be.

 When facilitating system design workshops in the past, what I did was the following: I stood in front of the first draft of the board that was just designed, said a few words about WiP limits and then asked the group „What WiP Limit should we put on this column?“ This was not a very collaborative process and it often led to long and tyring discussions if the limit should be 6 or 7 etc. Then I used a different approach: I divided the group into 2 or 3 smaller groups and told them to come up with what they think are the best limits to start with. After a timebox they reported back to the whole group. After this we formed new groups and discussed what we had so far. After this we consolidated the different drafts into the final one. 

The second approach is much more collaborative and certainly leads to better results. But it’s quite time consuming.

A couple of months ago, I tried something different. It’s similar to Magic Estimation, aka Bucket Estimation (a technique that some Scrum teams use for estimation their backlogs). And because I cannot come up with a better name, I call it Magic WiP Limitation. I’m probably not the only one who uses this approach, but I couldn’t find anything written about it on the internet. 

This is how I do it: 

1. The facilitator explains or repeats why we want to limit our WiP and how WiP Limits work. And he should emphasize that whatever limits we set: They are not made for all eternity and need to be adjusted.
2. The facilitator asks the group to gather in front of the board.
3. One person starts. He writes a number on a sticky note, attaches it to a column and says a few words about why he thinks it’s a good choice. Then he chooses a number for the next column etc.
4. Another person takes his turn and changes the limits as he feels they are appropriate. And he explains the reasons for the changes.
5. Repeat 4. until nobody wants to change anything anymore or until you observe that one or two numbers go back and forth all the time. Now that’s definitely something you want to talk about a little bit longer.
6.  If you feel that energy goes down, fewer and fewer people are involved in the discussion and they argue about details (limit of 6 or 7), suggest a compromise (often the higher number).
7. Declare success and celebrate the new WiP Limits.
8. Don’t forget to schedule a retrospective for reviewing and adjusting the WiP Limits in a couple of weeks.
9. Continue with another section of the workshop where you talk about the policies for dealing with WiP Limits.

Until now I only have very few data points, but so far I’m quite satisfied with this approach. Do you use something similar? Then please leave a comment and share your experiences!

What the F*** is Pull?

(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.
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.