A classic use of Kanban is in field support. Trouble tickets arrive on their own schedule. Team members take a Kanban course or read a book. The team puts up a board, sticky notes, and watches as the tickets flow across the workflow, pretty much as they did before. No real improvement except that the manager can now claim that her team is using Kanban and there is greater transparency. (Everyone is happy, and now the team can tick off their “Agile” box–done.)
Even when WIP limits are put in place, they are ignored. “This customer issue is too urgent so we have to exceed the WIP limit” is the logical and customer-focused rationale for the decision. A few weeks or months go by and the team has not stopped to examine why their activities do not flow faster. Kanban does not work. The flow data is not being parsed nor dissected to understand how to improve throughput. Does this sound familiar?
Kanban is a useful tool, but by itself, and without the reflection required to engineer throughput, nothing significant happens to improve life for that overloaded field support team. What’s missing is an understanding about that elusive, counter-intuitive bit about how variability impacts flow. It is really hard to step back and reflect when issues from customers are swamping your team. If you find yourself in this situation, read on for a step-by-small-step way to get Kanban working for you.
The assumption that is hard for teams to get over is that unexpected delays and problems do significant (read HUGE) damage to flow. Here is a short list of the kinds of unexpected delays I am talking about:
- Lead engineer is sick for three days. His or her work is put on hold. And anyone or anything that depends on that engineer is slowed or stopped.
- A software fix exposes a latent defect that was not seen before. Now you have to fix both problems.
- A subject matter expert is unexpectedly unavailable because of a face to face customer meeting in Vancouver (your team happens to be in New York).
- Another team needs your input on a critical customer issue and this will take half a day of your time. Your work goes on hold.
These kinds of events are hard to plan. They happen all the time, and we accept them as business as usual and do our best to work around them. The usual approach is to put a schedule buffer in place, and then load everyone to 100% so that if something gets put on hold, you have something else to work on.
The goal is not to demonstrate how much work is currently in progress, but to show how much of it getting cleared, finished, and delivered in whatever time box you use–weekly, fortnightly, etc.
Kanban does not enforce time-boxing. Enforce it yourself. Deliver to a fixed cadence and measure what you get done. If you are not improving, you are not managing your flow. You are not applying Kanban properly. Here are some suggestions to help get you over the hump. Take some baby steps.
- Start with a WIP limit that reduces your work in process by 5-10%. This is a small amount but it will start to get you used to the idea of paying attention to WIP. Teams under very high pressure are decidedly cautious about limiting WIP. This will be the hardest sell. Find a limit that gets you started. And if you cannot because the pressure is too high, tracking the “on-hold” work will help you develop an understanding of what is really happening in your workflow as a result of ignoring WIP. See below.
- Triage your work in each step of your workflow. Anything that exceeds WIP limits (or is deemed lower priority because of something more urgent) gets put at the bottom of the column of the workflow and tagged as “on-hold”. Measure your “on-hold” work – count it and keep track of it. If it is on hold because of one of the unexpected delay reasons above or any other unexpected delay reason, write it on the sticky note or record it in an excel file.
- If someone becomes idle as a result of the WIP limit or because they are blocked, get them to help someone else on the team rather than starting another item.
- After your time box expires, add up the number of “on-hold” items you have and take the average for the time-box, for each column. This will point out where you need to reduce WIP next. (Example: we had, on average, 5 items on hold each day during this iteration for items in the “Under Test” column.)
- In a team meeting, select one area where delays and “on-holds” are hurting your flow, and do two things. First, if a source of variance (unexpected delay) can be removed or reduced, do it. Second, set a modest WIP limit where you have the largest “on-hold” work.
- Repeat the cycle and keep measuring. Repeat the items in #5. The shorter the time box, the faster your will begin to see what is really happening.
One caution. Don’t try to fix everything at once. Take it one step at a time and observe what happens with each step you take, especially if you are new to this. This will take time and patience. If you have access to an experienced Kanban practitioner, get some help.