-Guest Post from Software Results

Scrum and Kanban are both popular these days, but which is the right choice for you?

Given that Scrum prescribes specific roles – each with its responsibilities and boundaries – I view Scrum as a governance framework that is well-suited for product development, whereas Kanban is more of a general framework that can be applied to various types of work. Both are valid options, and both help you to visualize your work, yet there are trade-offs associated with each.

Let’s talk about software development first. A key consideration that comes with adopting Scrum over Kanban relates to the level of dissatisfaction that you have with your current delivery, and what your appetite for change really is.

Scrum demands a great deal of change. New roles are introduced, teams are asked to self-manage, project managers no longer exist, and ScrumMasters are directed to protect the team from outside influences, such as managers assigning work to team members.

This type of change can be viewed as a good thing – if the organization deems that it has some serious problems with software development. If you feel that you do multitask your developers too much or that you genuinely want to improve on your ability to prioritize feature work and deliver greater value in shorter cycles, then Scrum is a perfect fit.

Kanban, on the other hand, is well-positioned to appeal to many organizations because it doesn’t ask you to change anything that you currently do, nor do you need to introduce new roles into your organization. Kanban is about making your current processes and policies visible and explicit to serve as a foundation to “pursue incremental, evolutionary change” (as one of the three foundational principles of Kanban states).

This is where Kanban is a double-edged sword. Kanban assumes that there are some things you are doing well which you want to retain, but there are other areas that need improvement. However, Kanban lacks explicit guidance in terms of changing your software development approach. It’s up to you to educate yourself on different models and approaches to improve your current state.

On the plus side, Kanban is flexible enough to be applied effectively in many situations; I personally feel that Kanban is well-suited for maintenance and support activities because it’s a simple matter to make prioritization and escalation policies explicit (if you haven’t already done so). This coupled with the visual workload management and WIP limits make Kanban a great fit.

In the final analysis, either Scrum or Kanban should be implemented because you want to improve. Implementing Kanban or Scrum won’t make you Lean or agile – they are merely tools designed to facilitate a Lean and agile mindset and approach… Tools that will one day be obsolete.

As Mike Rother reported in his book Toyota Kata, he heard remarks from two Toyota people along the lines of, “The purpose of Kanban is to eliminate the Kanban.”  In other words, we’ll reach a state where we’ll need something else because we’re executing so well – and that our mindsets and behaviors are fully in tune with Lean and agile thinking – improvement will need to come in some other form.

Until that day arrives, use the tools to help you become more Lean and agile. But don’t implement the tools without the mindset and behavior changes that should come with the package; otherwise your gains using either Scrum or Kanban will be marginal.

Read Dave’s blog

Join the Discussion

    • Dave Moran

      Thanks for your remarks. I don’t disagree with your assessment that Scrum is a framework of practices to evolve a product and that Kanban is a method to evolve your (existing) process. I do, however, stand by my comment that Kanban lacks explicit guidance in changing in terms of changing your software development approach. (I didn’t see anything in your comments that would talk me off of that ledge, if that’s what I’m on. That’s not to say that it can’t be done!)

      Scrum itself is not complete in this respect, either, which is why you see recommendations to utilize the technical practices of XP in conjunction with Scrum. Both Scrum and Kanban are good, but neither are complete if your objective is to improve your software delivery. You need to pull information and techniques from other sources. And as I close the post with, both Scrum and Kanban are tools to help you become lean and agile, but they won’t make you lean or agile in and of themselves.

      And FYI, I’m a guest blogger for VersionOne, not an employee. And I do a great deal of reading – including that of David Anderson. I tried to capture the essence of what is different between Scrum and Kanban in a very short blog post, and in the spirit of my own continuous improvement I am always willing to listen and explore different opinions and perspectives. I’ll continue to consider your comments.

      Thanks again.

    • Kurt Crowley

      Good post Dave, as you said there is a lot to cover with both methods, this is a good succinct intro to the topics of deciding on an approach. The reality is you need to start somewhere… I wrote a similar post on my company’s site: http://goblubird.com/cms/agile-but-which-one-the-kanban-trap-and-scrum-shock/ (maybe a little more “critical” 🙂 )

    • Paul

      Scrum or Kanban…? Everybody seems to ask the same question. In my opinion it depends on situation. “When considering whether adapting Kanban or Scrum would be the right choice for your situation, consider specific characteristics of your work, team and organization.” from: http://www.kanban-scrum.com/

    • Erik Philippus

      There are circumstances that Scrum and Kanban can be effectively applied in combination. I have hands-on experience with the introduction of Scrumban in many multidisciplinary organizations. For more info, read the article: “Dealing with unplanned work using Scrum + Kanban” published on: http://www.improvement-services.nl/blog/?p=147

    • Dave Moran


      I agree, a proper blend of Scrum and Kanban can and does work. And thanks for posting the link to your article! As you point out, unplanned work is a reality and needs to be budgeted for and managed. I like your point about asking whether something can wait until the next sprint — I’ve seen teams assume that they need to jump on an issue mid-sprint when in fact it could wait.

    • Nigel Hamilton

      The transparency of Kanban is important and bottlenecks can appear in real-time on the board. It’s these bottlenecks which often show areas for improvement. Scrum does provide places to hide – which means sometimes learning is held up.

    75 + = 77