6

So I've been trying to push Kanban, and consequently having WIP (Work In Progress) limits, but there's one question I keep being asked that I don't have a great answer for:

"What happens when we're at our WIP limit and 'do it now' work crops up?"

What I've considered is taking something currently in-progress out of in-progress, essentially pretending it was never started in the first place. This would be rather jarring event, and much work could be lost (even with some/all of it being committed, there would be losses due to hand-offs, knowledge decay, etc.)

Another option is to just violate the WIP limit, but that has downsides as well (possibility that the WIP itself may become irrelevant, loss due to task-switching, etc.)

Is there a better approach?

Improve this question

3 Answers 3

Reset to default
9

Embrace Change but Keep Costs Visible

"What happens when we're at our WIP limit and 'do it now' work crops up?"

If you've structured your process with spare capacity, rather than striving for 100% utilization, some Kanban processes allow for a special high-priority queue (sometimes called a "silver bullet") with a WIP limit of 1.

Some slack is essential for any lean or agile process, but special high-priority queues require even more. If an organization wants to reserve extra capacity, then this represents an ongoing cost to the business. It may be an acceptable cost, but it is never free.

More generally, though, the correct response is:

  1. Determine why the business expects "do it now" work to crop up on a regular basis. Expecting routine interruptions is a process smell that indicates that not everyone is on board with a queued workflow, or that key policies and processes have not been properly defined.
  2. When genuine emergencies do arise (and they do!), then it should be a jarring event to handle it. The goal of Kanban (or any other agile methodology) isn't to prevent important work from being done. The intent is to make the cost of new or unplanned work fully visible.
  3. The business (not individual stakeholders) should make a strategic decision about whether the opportunity cost of not doing something right now is higher or lower than the costs associated with lost work, unplanned change, or disruptions to flow. Costs can't be swept under the rug, but the business still has the ability to pay for the strategic decisions they make.
  4. When work exceeds capacity (not just an arbitrary WIP limit), then capacity must be shifted from one work product to another. There's no free lunch here. If your team is at capacity, then adding new work to the current cycle means something else must be removed or left undone.

In short, you can't create capacity out of thin air. Change has a cost. Kanban, Scrum, and others make these costs visible to the organization. It is then senior leadership's responsibility to make decisions about what costs to bear, and what "do it now!" things aren't really emergencies after all. It's amazing how well things can be prioritized when it's clear that they cost time or money, and that they were never really "free" in the first place.

Improve this answer
3
  • Does that then imply that the WIP (sans the 'silver bullet') must be lower than the Team's capacity? In order to accommodate the silver bullet when necessary?
    – Sarov
    Commented Jan 31, 2017 at 21:50
  • 2
    @Sarov WIP should never exceed capacity, and should generally be some (admittedly undefined) amount lower in order to provide sufficient slack in the system. For example, The Art of Agile Development says "The amount of slack you need doesn't depend on the number of problems you face. It depends on the randomness of problems." —Also, note that Kanban is about agreements; if you haven't agreed to a high-priority queue, then WIP items need to be pulled to fit new work into a lane/column that's at capacity.
    – Todd A. Jacobs ♦
    Commented Jan 31, 2017 at 22:13
  • @CodeGnome I'd argue that for a true emergency, it's ok to break that WIP limit, with the understanding that (likely) one of the WIP items is in WIP, but not actively being worked on. Of course, that should be a rare occurrence. If it happens often, it should be dealt with. If it becomes a real problem, I'd recommend allowing folks to put "emergency" items at top priority, but refuse to pull them in until space in the queue frees up. Anyway, great answer. ++
    – RubberDuck
    Commented Feb 2, 2017 at 0:57
3

First let us consider why work in progress is limited. Limiting WIP is needed in order to establish a self-regulated system that balances capacity and demand throughout the value delivery stream.

Simply put - if you see too much WIP, this means that somewhere down the line there is resource shortage. The most proper way is to address the resource shortage rather than piling up more work in progress.

"Cheating" to formally comply with the process, but without following the spirit of the process, reduces your efficiency and if abused too much will render the whole process useless.

Improve this answer
3

If you have to exceed the limits for some reason, increase the limits, get the work done and then decrease them again. It is easier to remember the rule "Never exceed limits" than "Sometimes it's okay". Alternatively, allow "Expedite" lane at the top, but make sure to only expedite critical issues, not business-related stuff. If you're always expediting, then you're not doing it right.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.