This is a question that I often ask people when they’re having trouble adapting to Work in Process (WiP) limits. WiP limits can be challenging to some when they’re new – all those competing demands telling you that you need to do more. How do you respond – by pulling more work into the system in the hope that business will equal better performance. It can be hard to make the switch to say “not yet“.

Often the decline into high WiP will occur over time – and it will be so gradual that you don’t notice it happening. Until you’re snowed under – there’s so many things on the go you find that you spend your entire day just trying to keep all the balls in the air – you don’t actually make much if any forward progress. There’s so many things on the go that you don’t have time to consider how to fix the problem – and any attempt to improve the system is met with a negative, sometimes aggressive response because you’re too busy to even think about it.

People can react this way when they’re under stress – from too much work in the system. People don’t want to take on a WiP limit and don’t understand how it can help them and they often think that it’s OK to task switch a lot. It’s not OK – especially in knowledge work. To do knowledge work effectively you need time to think through deeper problems and try and solve them in ways that are intensive on the “necktop computer”. Task switching takes you away from this ability and is part of the source of the frustration.

Which is where my question comes in – if you think a little bit of task switching is OK, then I take it to the extreme. “Is it ok to work on 1000 things at once?”. To which, the inevitable answer is “No” (I haven’t heard anyone say Yes to this yet). To which I respond, “Good, so you agree there needs to be a WiP limit. Now let’s talk about where that limit should be for your context”.

Getting started with WiP limits can be difficult – sometimes you need to take it to the extreme to help people understand what’s really going on. If you find yourself bogged down with too much work, don’t use hope as a method. Limiting your WiP will help you focus on what’s important to meet commitments and achieve balance. What are you waiting for?


One word that I continually think of when I think of WiP limits is “Focus”. Essentially, WiP limits create a focus for working on the right things at the right time. The absence of WiP limits means that there is often a lack of focus in the organisation.

Often when teams are doing many of different things, they tend to start lots of work, but tend not to finish anything. It really doesn’t help drive them towards their key goals and purpose. Having WiP limits in place will help focus a team on what’s key to be doing right now.

Sometimes there may be a mix of work types or priorities / classes of service for work. Using WiP limits more explicitly can help you ensure that your efforts are balanced appropriately across the different types. This helps people focus on the different things to the right level and see them through to completion. It can help ensure the right balance of work.

If teams are resistant to the use of explicit WiP limits, I would say something along the lines of “What’s our focus for this week / month” at their daily stand-up / kanban meeting. That invariably leads to a conversation around, “well we don’t have to start this yet, as it’s not our focus” or “this is critical for hitting <key focal point> for the month”. Teams tend to collaborate towards this shared goal and deliberately avoid the “noise” from other activities.

I often hear of / see things in organisations along the lines of “We have 100 people delivering projects, and 120 projects currently underway”. Clearly, in this kind of scenario there is a lack of focus for the organisation. What really needs to occur is to limit the number of projects in progress so you can focus your group efforts on achieving key outcomes.

In this kind of scenario, trying limiting the number of projects to, say, 20-30 and put a policy in place that says, you can only start a new project when an old one is completed. You start to create a bias towards delivery and completion of work to reap benefits sooner.


Dealing with Resistance to WiP Limits

Sometimes teams will understand the concept of WiP limits and be reasonably open to them, but perhaps their process is still emergent or they don’t yet understand what WiP limits they should put on the parts of their flow.

One possible solution to this scenario is the Constant WiP limit – also known as CONWIP. The idea is that you don’t put the WiP limit on each part of the process, but rather have a WiP limit on the overall flow. See the example below.

This is a basic pull system, but often the underlying process is not well understood or managed, thus it is a lower maturity implementation. You can use this to buy enough slack for you to be able to better understand and elaborate on the underlying system and start to implement some of the deeper kanban practices.


Dealing with Resistance to WiP Limits

Another technique for dealing with resistance to explicit WiP limits is to try limiting WiP per person. This can be useful for a team who is not used to working coherently together yet or might not want to go straight to WiP limits.

This technique has the advantage of being easy to adopt – it can be explained by how it can be beneficial to individuals to stop them getting overburdened with too much work. I often start with a deliberate provocation like “Is it reasonable for someone to work on 1000 things at once?”. To which practically everyone answers “NO!”. The discussion usually continues along the lines of “Well then, why don’t we restrict the number of things someone can work on concurrently to something much lower, say 3 items”.

This can be represented simply on the board by limiting the number of tokens or avatars of each person to, say, 3:

In the example above, there are 3 people working together. Two people are using each of their 3 tokens. One person still has a spare token in the backlog area where they park spare token, enabling them to work on one more item.

This in itself can be difficult for some people. Often, you might get some “hero” types that might like to be the centre of getting everyone out of trouble all the time. However, often these folks are actually the source of many of the problems because they become bottlenecks. You might find challenges with these folks just getting transparency into what they’re doing in the first place, even before you limit WiP.

Assuming you do have a level of trust and transparency, there are a number of drawbacks to this approach. For example, are 3 items actually practical in preventing time wasted context switching? Perhaps / perhaps not – it just depends on the nature of the work and your context.

Also, as you may notice, this limits the work done concurrently by individuals, it doesn’t actually limit the amount of work in the system. You can see the last ticket in the development column isn’t being actively worked on because someone’s token got moved somewhere else. In this case, because systemic WiP is not limited, you’ll notice longer wait and lead times, plus it will make the system less predictable.

If you are having trouble getting a team started with WiP limits, this might help. Ideally, you should try and get to explicit systemic WiP limits, so treat this as an evolutionary step, not an endpoint.


Dealing with Resistance to WiP Limits

This is one of what will become a series of blog posts that discuss and give options on how to deal with resistance to WiP limits.

Having WiP limits for the first time can be confronting for many teams and organisations. For those who have been utilisation or specialisation focused, the concept of flow and WiP limits may take time to get used to. It may involve unlearning what could be years of habit with another process – it’s not something that’s done overnight and it needs continual adjustment, encouragement and monitoring. Until teams have gotten into the discipline of following explicit WiP limits, there may be other ways to help enforce the WiP limits.

The catch-cry of many a Kanban team is “Stop starting, start finishing”. This often sounds simpler than what it means in practice. So, to help out I often suggest to teams that they use the “walk the board” from “right to left” during their daily stand-up / Kanban meeting. What does this mean? Consider this example board for a software team:

Get the team to start the stand up by looking at the right hand side of the board first. We have 2 items in Deployment – if anyone is free, ask if they can help with the deployment activities.

Then move to the next column to the left – Testing. If there are any defects then get any free engineers to focus on fixing the defect. Alternatively, you could have the engineers help testers with automation, data setup or any other activities that could help get the testing done.

Next, move onto development. Are there any free engineers to help with code reviews, build pipelines or any other development activities? If so focus on getting the development done for these tickets.

If there is nothing downstream for an idle engineer, then and only then can they pick up a new card from the To Do column.

Even without explicit WiP limits, you will find that just using this practice will assist your teams in limiting their work in process. By more explicitly focusing on moving the downstream tickets before starting new ones you will have “Stopped starting and started finishing”.

Once the team is used to this habit you can have deeper conversations with the team about what the explicit WiP limits should be.


Recently, I ran a session of “The ship game” that was created by @klausleopold (read up more about it in my earlier blog from LAST conference). During that session, a couple of the attendees looked to me disbelievingly as they saw lead times halved. The look they gave me was “what kind of trick is this” as if I waved some kind of magic wand and magically sped everything up. The answer in the end was that there was no special magic, just the use of Work in Process limits.

Some teams experience lead times halving, some experience even greater improvements. What this group also found that they also had slack in the system when they introduced WiP limits – they were actually not working as hard and they were achieving better results compared to when they didn’t have WiP limits. To me this really highlights one of the key parts of Kanban is really the WiP limit.

Many people have the misconception that “the Kanban” is just the board. So many times, I’ve heard “we’ve got a board so we’re doing Kanban”. Although a board can be useful, you’re really not getting the full benefits out of Kanban – you really need to start limiting WiP to get the benefits. So much so, that I distinguish between the two – now I refer to “the Kanban” as the slot created by the WiP limit that allows you to pull new work in. I refer to the Board as simply the “Visual Management Board”. I really don’t consider it “Kanban” for knowledge work without the use of WiP limits (see for more details on different kinds of WiP limit implementations).  

The WiP limit is important because it:

  • Allows you to see the capacity available
  • Creates focus to avoid task switching overheads
  • Prevents you from overburdening teams by pushing too much work into the system
  • Stabilises the system such that you can get meaningful lead time metrics
  • Catalyses change by stressing the system (as opposed to the people in the system)
  • Creates slack to allow improvement opportunities to take place

Sometimes it can be hard to introduce this and it certainly may seem counterintuitive when you start, but if you can stick to it, you will get many benefits like those mentioned above. So, please help your team, your customers and ultimately your organisation become more successful by implementing this small change.

If you want to find out more about how to implement a real Kanban system, please check out the upcoming Kanban System Design courses.