Scrum, Kanban and Unplanned Work

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:

  1. that Kanban has some magic way of dealing with unplanned work and emergencies
  2. that Kanban makes it more convenient to deal with them
  3. that Scrum is too inflexible with its timebox and cannot accommodate unplanned work

There is no expedite magic in Kanban

Kanban board with questions about allocating planned and unplanned work

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.

Advertisements
This entry was posted in hands-on. Bookmark the permalink.

7 Responses to Scrum, Kanban and Unplanned Work

  1. pascalvenier says:

    An exciting and thought provoking post. 😉

  2. sri1969 says:

    Good one .. Just a thought – Can’t this be done by having a small buffer in each Sprint for unplanned activities ? Let’s say a team is working on a Product increment, and a few members of the team have to work on Production issues, reduce their commitment to say 30% or 40% of their availability. This way, the product development will not suffer and the high priority bugs are taken up for resolution at the earliest. The actual amount of time set apart for production fixes can be fine tuned after one or two iterations.

    • azheglov says:

      Sri, I described the same thing in the section “Scrum doesn’t tell you to defy common sense.” It can be a small allocation (I prefer this term to “buffer”) or a large allocation, depending on the actual demand. The important point here is not to simply fine-tune this allocation, but to shape demand by reducing restorative/failure demand and to drive this allocation steadily down towards zero.

  3. Pingback: The Best of 2013 | Learning Agile and Lean

  4. Pingback: The Best of 2014 | Connected Knowledge

  5. Panait Ciprian says:

    scrum does indeed tell you to defy common sense in a number of ways:
    1. sprints. these are based on the idea that everything can be chopped into little pieces and the pieces still having meaningful value. Problem is that past a certain point that value is lost. That is why Scrum reducing the 3-4 months iterations in iterative development to 1 month or less often leads to death marches and quick and dirty code. It defies the law of irreductible complexity.
    2. automated testing. While automated testing can facilitate and make things easier in over 95% of software projects it is unable to replace human manual testing. This means that some time should be allocated especially for this. Scrum does not do that and assumes everything can be automated.
    3. story points. normally you would give an evaluation on how much a task will take and plan accordingly. If by chance you finished faster bug free that time would belong to you. Your efficiency would be evaluated based on your ability to do the task in the allocated time. With story points now you have an arbitrary number points that are used to calculate velocity which always must increase. This means writing code quick and dirty. there is no workaround for this. Also means allocating sp with no justification except to look poductive
    4. scrum meetings. 90% of all those meetings are useless. In the era of information communication trough various IM clients mail and phone had removed the need for mot meetings. Having a meeting every two weeks or worse every day wastes valuable time and produces loads of stress.
    5. backlog concept. Normally every programmer will be in charge of his module and how this works with the others. He would test/fix bugs made by his code alone except critical cases. Now you get tasks and bugs from all over and you no longer can have a clear idea on any part of the code, let alone the whole project. you are now reduced to a coding monkey.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s