Kanban versus Scrum

Once upon a time, “Agile” was a new word. Somewhat later, “Scrum” was a new type of agile development. Now I’m reading more about “Kanban” as a new(er) type of agile development.

Henrik Kniberg has an interesting comparison of Kanban vs Scrum on his Web log. He does a very nice job of summarizing the difference. If I were to summarize his summary, I would say that Kanban essentially replaces the concept of time-boxing as the main constraint mechanism with that of limiting simultaneous tasks in a particular workflow state.

Scrum Sprints are planned, through collaboration between the Team, Product Owner, and Scrum Master. This planning is time boxed, just as the Sprint itself is time boxed. Given a particular team size, the execution of the Sprint is constrained by the duration of the Sprint, with requests implemented in rank order.

Kanban work is not time boxed. Instead, the team works through a steady stream of requests, prioritized as appropriate. The constraint is on the maximum number of simultaneous requests allowed per workflow state. Thus the team might have a limit of two “In Process” requests at any time.

My take-away is that Kanban and Scrum are both Agile.

I like Scrum more from the planning perspective, because it entails more planning (albeit short term). Like it or not (and most engineers don’t like it!), stakeholders outside the Scrum teams do want to have some concept of “plan” or “schedule.” The business as a whole has valid needs for such things.

I like Kanban more as a process for handling a stream of unpredictable requests, such as in tech support departments. Kanban’s emphasis on “pull” and absence of time-boxing appear well-suited for the interrupt-driven life style of tech support.

Scrum processes can handle tech support issues, but not instantly. Kanban processes can handle feature development over time, but provide less of a safety net in terms of working to a plan and having due dates.

That’s my take on Kanban versus Scrum. What’s yours?

Advertisements
Explore posts in the same categories: Uncategorized

6 Comments on “Kanban versus Scrum”


  1. Why are you talking only about Kanban vs Scrum?
    I agree that Kanban suits the tech support issues better. On normal software development Kanban is like an oxymoron, and I wonder whether people talking about Kanban have any idea about what the original Japanese meaning is.

    With Scrum you say “albeit short term”.
    That’s one of the drawbacks of Scrum.
    How about Evolutinary Planning, which is short time planning (looks a bit like Scrum) but also longer time planning and connecting both.
    Have a look at http://www.malotaux.nl/Booklets. booklet#2 and booklet#7.
    Why would you still want to talk about Scrum?

    • deepscrum Says:

      Why am I talking only about Kanban vs Scrum? Partly because I am not trying to cover the entire field of software engineering project management in one blog post, partly because their similarities and differences are interesting, and partly because I write about things that interest me.

      You say that short-term planning is a drawback of Scrum. I disagree. You can plan out as far as you like, and should at the strategic level, but Scrum Sprints require only short-term plans, and provide the opportunity to change direction quickly because you are not locked into a large, inflexible plan. The quick cycles allow for quick changes in plans based on changing customer needs, which is how Scrum provides for responsiveness to customers.

      Why would I still want to talk about Scrum? Because Scrum works very, very well, when facilitated by a Scrum Master who knows how to do it. If you think Evolutionary Planning is superior, by all means write a comment here and tell us why.

  2. Alan Char Says:

    I think this is a largely a semantic issue, and the two terms are more differences of viewpoint than process. The premise in the linked “conversation” is that if you don’t do all the items in the sprint, you have somehow “failed” it. The point of sprints is that it’s an iterative planning process. If you know you are a customer event driven operation, then you will eventually learn to have fewer pre-planned items in your sprint in order to allow for ad hoc tasks that come up. Ad hoc tasks and/or velocity adjustments should be part of the agile process.

    Likewise, in an ideal scrum environment, only one task is worked on at a time. In reality, this only works for very small teams, but regardless, the point is to make a best effort to perform the tasks in priority order. So even if the team is too large for everyone to perform the same task, there should be a natural limit to the number of parallel tasks based on the size of the team. At least one of the current tasks should be completed before a new task is started. Otherwise, all the tasks will be started, risking that none of the will be completed. In this case, you really have “failed” the sprint.

    • deepscrum Says:

      Alan, my only comment on your comment is to agree with everything you’ve written. The importance of “burning down” stories in rank order, so that the team is guaranteed to have at least some of them completed by end of sprint, is crucial. It’s also an area that needs careful attention, as new teams tend to fall naturally into “one story per person” mode.

  3. David Kramer Says:

    Kanban and Scrum are different tools to work on different problems, Asking which is better is like asking if a hammer is better or a screwdriver is better.

    Scrum is focused on what work gets done and in what order. Kanban focuses on efficiency of flow and identifying bottlenecks.

  4. deepscrum Says:

    David – I agree. I would use them for different problems.


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


%d bloggers like this: