The Agile Apprentice
In a previous post I talked about how effective limiting work in progress had been for one of the software delivery teams I worked with. The team’s discipline to stick to the limits didn’t come overnight, it was developed through experience and learning.
People tend to understand the logic of limiting work in progress on an individual basis. Once we get to a team or organisation, things are more complex. Like most things in life, limiting WIP has a benefit and a cost, it’s important to understand both in different scenarios.
Here are some scenarios where I have seen teams call work in progress limits into question.
The Urgent Bug
The team stop to debate the limit rather than getting on with fixing the bug.
The cost of temporarily exceeding the limit is low, while the cost of not fixing an urgent bug is high. This is a simple economic decision. Once you have decided urgent bugs can exceed the limit, it’s sensible to set a policy so that next time, the team just get on and fix it.
If you are facing this frequently, there’s a high cost to exceeding the limit with too many bug fixes at once. Defining a class of service to handle urgent work with it’s own limit can allow you to manage this. Creating a separate horizontal lane, or ‘swim lane’ on the board is one way to help to manage urgent work that needs to be expedited. (We set our expedite limit to 1).
If enough work becomes stuck, staying within the WIP limit stops the system. The limit appears to be slowing the team down, there is other available work they could be getting on with.
However, the limit should force the team to stop and evaluate what’s going on. Why is so much work being blocked? If you can identify and permanently fix whatever is causing the problem, work will flow more smoothly from then on. You removed a source of delay, that delivers benefits for the delivery of every future work item.
Furthermore, what about when blocked items become unblocked? If you ignored the limit, suddenly you have lots of context switching back to old work. You may have to remember what you were doing before it got blocked!
If you can stick to the limits and fix the problems, the benefits of the limit should far outweigh the cost.
Pushing rather than Pulling
The MD needs something urgently. She goes directly to her favorite, most trusted developer. There’s a personal cost to the WIP limit, no one likes to say no, especially to senior people who they developed a relationship with.
Teams would not be blamed for choosing to exceed the limit to not upset anyone. However, hopefully they recognise they exceeded the limit and have a conversation about how to handle this situation in future.
Classes of service can help in a similar way to the urgent bug. You could measure lead times for that class of service and set a service level agreement with the MD, based on what the data tells you, giving the MD confidence and predictability.
A Natural Bottleneck
The team has 6 developers and 1 tester. The developers are getting through work quickly, then they hit the limit, as a queue of testing has formed. The team are stood around debating WIP limits again, surely they should just get on with starting the next piece of work?
Starting more work won’t result in that work being delivered faster, the system is limited by the speed that work can be tested. Starting more work will just add to the test queue, slowing work down further, just like cars queuing at roadworks on a motorway, the more cars, the longer the queue. The limit is acting as a safety net stopping that from happening.
The limit should force the team to stop, identify the bottleneck and find ways to alleviate it.
Often when the team point the finger of blame at WIP limits, they are thinking about the local effects on them, rather than the economics of the system as a whole.