Implied WiP Limits – Right to Left

Sometimes when you start with Kanban a team might not be open to using WiP limits. To some, it may seem a bit arbitrary or draconian and they might not want to try it. There’s likely something going on there that you may need to tackle – but there is an easier way. As we say in Kanban “go around the rock” – so there are some occasions where its best not to start with express WiP limits, but use a technique that’s a little more subtle and implies WiP limits across the board.

Here’s an example board that you might be able to relate to if you’re working in a software team:

As you can see, there’s a workflow there but we haven’t set any explicit WiP limits either on the columns or on the overall workflow itself. Instead, during your daily Kanban meeting (or what some call “Stand up”), walk the board from right to left. The key here is that one someone is idle, they don’t pick up a new item by default, the default is to help someone else and only pick up a new item as a last resort. Here’s some example of what that policy can look like:

When you’re free:

  • Help with testing, can you:
    • Fix a bug?
    • Setup some test data?
    • Configure an environment?
    • Run a test?

If you can, great, go do that. If not:

  • Can you help a developer, for example:
    • Is there a pull request you can review?
    • Is there someone you can pair with?
    • Does anyone need help with design issues?

If you can, great go do that. If not:

  • Can you help an analyst, for example:
    • Is there a spike you can do?
    • Is there something you can review?

If you can, great go do that. If not, then pull a new ticket.

Notice that pulling a new ticket is a last resort rather than the first resort? There’s several positive effects of this. Firstly, it inherently limits WiP because you “Stop starting and start finishing”. By doing so, you get all the benefits of limiting WiP such as improved lead times, less blocking work, often increased throughput and greater predictability. Secondly, it encourages teamwork which has positive impacts to employee engagement and also builds greater resilience in your system of work through cross-skilling. Oftentimes in teams, people might work more individually as they just pull the next ticket. Whereas in this kind of system, they need to “help others first, start something last”. There might be an initial learning curve that takes a bit of time to get through, but once through this the system of work improves dramatically.

There may be some who still resist the idea of helping others in the team rather than just doing their own work. Oftentimes, just the peer pressure behind this kind of policy is enough – “why wouldn’t you want to help your team mate”? If that’s not enough, usually a management one on one conversation can help clear this up. It’ll help identify why they may be resistant – there may be other things you learn from this that you need to action.

Although we haven’t limited WiP explicitly in this example, through the use of the above kinds of policies, you will inherently limit WiP. It’s important that you do make these policies explicit so that the team follow them and make sure that this is happening through the Kanban meeting. If you’re experiencing resistance to limiting WiP, you might want to give this a try.