When software teams start thinking about delivering faster one of the techniques they often try is limiting work in progress (WIP). The idea is that for each stage the work goes through (for example, “in development”, “code review”, “testing”, etc) there is a limit to how many items can be in that state at any one time.

It’s entirely natural for a team to try this practice without entirely understanding the consequences. But those consequences quickly reveal themselves. A typical scenario is that an engineer finishes coding a piece of work, tries to move it into the “code review” stage, and then finds they can’t because there are already the maximum number of items in code review. Initially this is just a surprise—perhaps they can review one of the pieces already in review, therefore move that out, and so free up space for their work. But sometimes that’s not possible because actually the work in review is already being reviewed by others who just haven’t finished yet. Now this is painful and frustrating; perhaps it even feels silly. Perhaps we should change the rules and increase the WIP limit of the code review stage.

In fact, I’ve found this pain and frustration to almost be the point of setting WIP limits—at least initially. It forces some very difficult conversations, which are about coordinating work between team members, choosing carefully which work to pick up to avoid bottlenecks like this, and generally ensuring a smooth, synchronised, working pattern that allows work to flow smoothly through the team. These kinds of conversations are new, and they’re only happening because the WIP limit forced them.

So if you’re trying WIP limits for the first time, watch out for the pain. And before you give up and go back to how things were, recognise that the pain is telling you that you need to address something important.

Photo by Ath-har Saeed