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.
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.
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.
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 https://www.kanbanmaturitymodel.com/ for more details on different kinds of WiP limit implementations).
The WiP limit is important
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.