How to avoid clogging up your Kanban with too much Work in Progress

Kanban focuses on the flow of work. By seeing all the work on the Kanban board, your team knows what is going on, what work is stuck, and what is progressing. But for your team to succeed with Kanban, the amount of work on the board needs to be limited. 

This is what Kanban calls Work In Progress (WIP) limits, and it is truly essential to great Kanban.

For example, the team can have only 5 items at development, or 3 items in testing at any one time. If the WIP limit is reached, the team shouldn't be allowed to push work downstream until the work phase which is limiting the flow has been cleared.

The chaos without WIP limits

Without any WIP limits, your team could easily start to accumulate too much ongoing work. With too much work on the board:

• It will be difficult to predict or manage the flow of work 
• There will be frequent task switching and more stress. 
• The team is forced to develop mechanisms to flow urgent work through an otherwise clogged process. This can lead to “whoever shouts loudest will win” prioritization, which is not something you want to teach the rest of the organization to do.

However, most Kanban teams do not set strict WIP limits. And the teams that do set them up, often end up not obeying them. 

Imagine a factory floor instead of software development process

Imagine another, more traditional type of work. If we take a look at a small factory workshop that is building physical products. Building the products would take place at multiple workstations. The steps could include: 

• Machining
• Painting
• Assembly
• Final quality check
  
  

Imagine a situation where a problem occurs in the final assembly stage. The production line has to be stopped for some reason. The reason could be faults observed in the components coming from upstream, or a breakdown of the production line tools. What would happen on the factory floor?

I am fairly certain that if the problem would remain any longer than a few minutes, the operators of the paint and machining workstations would know about it. Would they continue to perform work on their workstations normally, filling the factory floor with semi-finished components?

That would be quite absurd. It would become totally stupid to continue work on the previous steps, when the work is not flowing in the downstream steps. It would actually become physically impossible - there would not be room on the factory floor to store the incomplete components. 

If possible, the operators would surely try to troubleshoot and fix the production line as soon as possible.

Why doesn't the same common sense work in software development Kanban?

In software development, the work items are not physical. If there is a problem in the downstream work steps, the office space is not diminished. It is still possible for developers to push work downstream. 

This is exactly why the Kanban WIP limits exist. They are virtual constraints, meant to highlight process bottlenecks. If you totally disregard - or have no WIP limits at all - you are like the oblivious factory workers who blindly continue to fill the factory floor with incomplete work.

Why is it easier to disregard WIP limits in IT work? It could be because of following reasons:

• Work tickets are more abstract than physical objects
• We do not truly understand or respect downstream work
• We do not work as a team - focusing only on our own process step
• We are not measuring the workflow with DevOps metrics-like cycle time
• We instinctively want to “be efficient” and appear busy at work

Resist the need to appear “efficient”

Efficiency is a measure for situations where you work with a blindfold on. When you have no knowledge of how the work flows through the team’s process, you obviously focus on working as fast and efficiently as possible on your own task. 

Maybe you have instincts to “be efficient and busy”. What do you do when a boss is around? Everyone act busy! Is this kind of behaviour a result of us wanting to appear a valuable part of the team?

What you can do to fix the situation

How can we make the team understand the value of flow of work, and limiting the work in progress? I think we should

• Measure the flow of work to “Done” and experiment with strict WIP limits
• Perform actions to reduce the effect of constraints and bottlenecks
• Get to know other work steps better - switch roles
• Team building - get to know each other and you will feel more of an urge to help when other team members need it

Measure the flow of work to Done

The Scrum Master could measure a weekly velocity for the team. For example, every Friday she could calculate how many tickets made it to the Done column that week. Then she could agree on an experiment with the team: for the following week, the team agrees to strictly follow some set of WIP limits. And then, the amount of work Done would be measured again on that Friday.

The team should then discuss how to change the WIP limits for the next week. I guarantee that this would speed things up. It is inevitable. When combined with splitting work to smaller chunks, this approach should be in every “Kanban master” cookbook.

Be aware of constraints

The team has a bottleneck. Every process in the world has one, and the team has one too. What is it? Is it testing? Automated testing? Approval from the customer? The team Scrum Master must ask this question, and the team must be aware of the bottleneck.

The next question is, how can the work flowing through the bottleneck be increased? For example: 

• if the bottleneck is automated testing: how can creation and execution of the tests be made faster? 
• If the bottleneck is code reviews: what rules can the team set to experiment speeding up reviewing other developers' pull requests?

Have better knowledge of the total process

If the problem of too much WIP is because the team does not know or respect other process flow steps, maybe it is time for some role switching. Have developers do testing for a while, and have testers pair program with a developer.

I also firmly believe that traditional “team building”, where the team members get to know each other better, will also help in respecting the others. Are you a group or a team? Talk about other things than work, and get to know the person behind the role. 

I hope this blog got you thinking on enforcing WIP limits with your team. Happy limiting ongoing work!