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.