A colleague sent a link to an article to a group of colleagues and ask for a comment. The article was published in one of the popular online IT magazines. My goal here is not to criticize or fix this article, but to clear up the misconceptions that this article left some of my colleagues with.
A Scrum team plans stories for the sprint ahead and starts working. Very soon, some unplanned work arrives: technical support interruptions, bugs, requests from other teams dependent on this team, and so on. If the team is unwilling to interrupt their planned work on their user stories, ask their Scrum Master to “protect” them, and the Scrum Master succeeds at that, then some clearly urgent and important work doesn’t get done, leaving several stakeholders frustrated. If the team interrupts their sprint, that jeopardizes their delivery of planned user stories by the end of the sprint, leaving the Product Owner and some other stakeholders frustrated.
Then — honk if you have never seen this happen — somebody says: “This is the nature of our work. We cannot honour our timeboxes. We have to admit Scrum is not for us. We need to switch to Kanban!”
Things are much better in the imaginary Kanbanland. Whenever an urgent important issue occurs, the team places a ticket into the Expedite lane on their Kanban board and swarms it. The issue gets resolved very quickly. Dynamic prioritization happens all the time, so some items pass other items in the “flow” so that they can be done faster. The work items they pass get done a little slower, but still on time. Everybody is happy. Someone has this vision in their head and sells it to their colleagues. This has of course never happened to anyone you know.
Switching from Scrum to Kanban, Missing the Most of Both?
Embedded in this naive Kanban sales pitch are those several misconceptions:
- that Kanban has some magic way of dealing with unplanned work and emergencies
- that Kanban makes it more convenient to deal with them
- that Scrum is too inflexible with its timebox and cannot accommodate unplanned work
There is no expedite magic in Kanban
Drawing an expedite lane on a Kanban board doesn’t magically ensure that unplanned/expedited work gets done. What many Kanban practitioners do is they allocate some of their capacity to work on unplanned work/expedites and some capacity to do planned work. They design explicit policies for sequencing work items belonging to different classes of service. That’s how their unplanned work gets done. Their board makes the allocation explicit.
The point of Kanban is actually to get rid of such work, not to keep doing it indefinitely through magic or skill. Kanban, when practiced at the depth that includes quantitative flow measurements, makes the economic cost of expedites explicit. Case studies presented at major conferences show that it is actually quite heavy. Monte Carlo simulations based on real-world project data confirm and provide the mathematical basis of this finding. For example, in his LSSC’12 talk, Dan Vacanti showed an example where a 10% capacity allocation to expedites roughly doubled lead times for the standard class of service. Another analogy is a suburban highway closed during rush hour to make way for the presidential motorcade – when will the commuters get to work?
In the Corbis 2006-2007 case study, which is one of the case studies in the book every Kanban practitioner ought to have read by now, the arrival rate of expedite tickets was reduced to five per year for a company of 1300 employees, including over 100 in the IT department. (It may not be easy to connect these two numbers because the expedite statistics are mentioned on page 227, while the size of the company is described on page 52.) Gradually reducing restorative demand is the direction to go, regardless of process and improvement frameworks. Pursuing this direction with Kanban requires certain depth of practice of the Kanban method, especially in the areas of demand analysis, measuring flow, Katas and models. Simply visualizing team workflows and controlling multitasking with WIP limits, which is what many teams “switching from Scrum to Kanban” for convenience end up doing is not likely to be enough.
Scrum doesn’t tell you to defy common sense
At the same time, unwillingness to set aside planned work and switch to a clearly urgent, important issue, insistence on “honouring” the sprint plan and scheduling this urgent work for the next sprint strikes me as a dogmatic interpretation of the Scrum framework. Scrum gives teams a process and an improvement framework, but it doesn’t tell you to defy common sense. If an unplanned work item shows up and there is no economic cost to not doing it and there is no benefit to the business or clients in doing it, then common sense says, delete it from your backlog and don’t do it. Otherwise, which is more likely, there is some economic cost to not doing it, because it is very beneficial to your clients and your business (we call it cost of delay in Kanban), and that means you have to find and allocate capacity to do this type of work quickly. How much capacity does your unplanned work require? Do some team members need to be relieved of planned user-story work for the sprint so that they are always available to handle the urgent unplanned work? How many and for how many days? What does it take? What does cost-of-delay vs. cost-of-capacity tradeoff look like for this team?
When the team plans their sprints, they should use only the planned-work capacity to select the user stories for the sprint. This capacity measure may also be called the sustainable pace, the focus factor and so on. Then they can use this capacity to do their planned work in an uninterrupted timeboxed fashion. If they use their total capacity for the planning purpose, they are counting on magic to happen. There may be one problem with this approach: the planned-work capacity is laughably small, because unplanned work dominates. Say, the Product Owner expects the team to pick up 10 stories for the sprint, but they only pick up 3 and say, we need the capacity that could be used for 7 other stories to do all that unplanned work that we know will occur. PO: “WTH?”
If the team’s planned-work capacity is so small, then they have two great questions for their next retrospective. Why is there so much unplanned work? What can we do to reduce the arrivals of unplanned work? Scrum is both a process and an improvement framework. No matter what happens within the Sprint timebox, there is a retrospective a the end, where the team can identify and take some improvement steps. If unplanned work causes a lot of pain, ask those two focused questions.
Conclusion: Kanban for Improvement, Not for Convenience
Kanban can provide options for improvement. However the powerful improvement-focused questions have to be asked regardless of the chosen improvement framework. If these questions are not being asked, that’s a problem. Those making the “switch” for convenience may be ignoring this problem and running the risk of missing the improvement part, which is the point of the Kanban method.