In Kanban, what should we do about an urgent task?

Question

If at that time, development team is currently at max WIP, then there's an urgent task like critical bug that need to be fixed immediately, do we need to violate the max WIP and allow to do work more than max WIP temporary until that task is done?

Answer 1

Depending on how often this happens, you could consider defining your Kanban board by 'class of service' - where you can use the Class of Services defined by David Anderson in his book: Kanban: Successful Evolutionary Change for your Technology Business.

You might consider all of the classes of service - Standard (normal work), Expedited (customer or other interrupt driven work), Fixed-Delivery Date or Intangible (such as refactoring work) - or you could take a subset.

Once you do that, you can define WIP limits for each lane separately. A common practice - depending on organization/ team size - is to limit WIP of the Expedite lane to just 1 - which communicates to your stakeholders and to the team itself, that you will not accept more than 1 urgent task at a time. Dennis Stevens has written a great blog post about it.

Additionally, you should think about using 'blockers' on cards your team is currently working on to show that some card(s) got blocked when the people working on those cards got diverted to working on the Expedited card. This can provide some great analysis on your team's interrupt driven work and its impact on regular work.

If you have any other questions on Kanban, I'd definitely recommend the book - and you can also find some great information on our website (David is an advisor to us) as well as our blog.

Good luck!

Answer 2

TL;DR

Disruptive requests are "waste" that can be accepted, managed, or removed. While the needs of the business must be served, every such request is an opportunity for kaizen and a chance to make sure that a recurrence is less likely in the future.

How to Handle Urgent Requests in Kanban

[If] there's an urgent task like critical bug that need to be fixed immediately, do we need to violate the max WIP and allow to do work more than max WIP temporary until that task is done?

No. In Kanban, WIP limits and classes of service should be agreements made in partnership with the business, rather than something fixed by the framework. That means that when "urgent" work comes in, you should:

1. Consume reserved capacity.

   Use any pre-negotiated buffers, high-priority swimlanes, or Expedite queues that have already been set up, provided that this new request fits within the the reserved capacity. In other words, the card wall has reserved some slack for just this purpose, and you now use that capacity to fulfill the urgent request.

2. Review organizational agreements about WIP limits and classes of service.

   If there is no Expedite class of service, or it is already in use, you should generally remind the business of the agreements about WIP limits and classes of service. You should also review the costs to the business of disrupting flow and cadence, and extending lead times, that are the natural consequences of out-of-band work. Sometimes it turns out that the "urgent" work item isn't really that urgent when carefully re-evaluated, and the business will accept the lead time of a standard class of service rather than disrupt the entire process.

3. Evict WIP to make room.

   Just because something is urgent doesn't mean there's actual capacity to deliver it. You have to extract the capacity from elsewhere in your system. If the need truly is business-critical, and the business is therefore willing to absorb the costs of disrupting the process to ram something through, then ask which active WIP items should be suspended to make room for the urgent item.

4. Inspect and adapt (after the fact).

   If this sort of thing happens enough that it creates statistically significant perturbations in your flow over time, then you should adapt the process and the partnership agreements until the flow smooths out again. A one-off emergency can't be predicted, but "routine emergencies" are wasteful process problems that must be fixed.

There is value in a smooth flow and a predictable cadence. When the process is disrupted, the cost to the organization should be made visible on the card wall and through reported metrics. Since Kanban is based on agreements, part of that agreement needs to be an acceptance of responsibility by management for the natural consequences of disrupting the process.

When Nothing Else Works

When necessary, you can also gently remind stakeholders of the following unpleasant (but unavoidable) reality:

Management is always free to disrupt a process, but the cost of disrupting the process is not "free."

— CodeGnome's Iron Law of Process Economics

A healthy Kanban is done in full awareness of this truth. A dysfunctional organization typically ignores it. Perfection is not required; only a desire for kaizen.

Answer 3

If you are facing a business-critical bug that needs to be fixed, you definitely have to break any kind of rules you have, including WIP limits. You are not going to jeopardize the whole business for the sake of the process and its rules.

In a team I used to work with we called this a "panic situation", not that we would actually panic. When a " panic situation" happened, the whole team usually stopped whatever they were doing to "swarm" around the new work item. The process was de facto suspended.

There is nothing wrong with breaking the rules in case of emergency. Now if you realize that emergencies are...usual, you might want to consider including them in your process. To do so you can, for example, permanently allocate some empty slot so that you won't have to suspend the normal execution of your process in case of emergency. This would help you keep the system in a statistically stable situation, which is what you want to keep a high level of predictability.