Scrum or Kanban? YES!

Alternate Title: A model for understanding Scrum and Kanban

(Cool diagram below – skip down if you are in a rush 😉 Or check out the 3 minute video explaining why Scrum and Kanban are complementary.

As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.

Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.

Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.

I use Agile

I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.

I use Lean/Kanban

I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.

For me, Agile includes Kanban

When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.

What I learned at LSSC10 that shifted my thinking.

At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.

Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.

Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.

(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.

Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.

Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.

Scrum and Kanban fit different contexts

  • Kanban can handle a lot of interrupts
  • Kanban supports specialized roles with divergent skill sets
  • Kanban excels at repeatable work such as a production line
  • Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower
  • Scrum excels at projects requiring deep collaboration and innovation
  • Scrum works best with small cross-functional teams (7+/-2)
  • Scrum is great for providing shared goals and work context
  • Scrum encourages generalists

For a more comprehensive list of similarities and differences see Kanban and Scrum – making the most of both. See also Jason Yip’s recent observations.

A model for thinking about Scrum and Kanban

I am a visual thinker so I need a picture to put it all together:

  • The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
  • The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.

Every process has a sweet spot

I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest  that these are not hard boundaries. The regions and shapes are more illustrative than literal.

In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.

I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.

In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients

We need to know both Scrum/XP and Kanban

If all you have is a hammer, everything looks like a nail.

What tools do you have in your belt?

Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.

As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”

Let’s build community

For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.

For my Kanban friends, let’s build bridges and create a strong inclusive community.

Hungry for More?


Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.

What do you think?

The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.

Print Friendly
Tagged with:
, , , , , , ,

Find Content

Adoption Agile Agile2009 Agile Failure Agile in the Large Agile Tour Toronto Change Artist Christine Day Coaching Communication Container Craftsmanship Creativity Empathy Facilitation Fear Games and Simulations Hierarchy Kanban Kotter Leadership Lean Management Observing Organizational Change Organizational Culture People Personal Growth Production Product Strategy Project Management Red Pill Safety Scrum Strategic Play Teamwork Technical Practices Training Training from the Back of the Room Transformation Transition Trust VAST Vulnerability XP

Leave a Reply

11 responses to “Scrum or Kanban? YES!”

  1. […] This post was mentioned on Twitter by Declan Whelan, David J Anderson and jasonlittle, Michael Sahota. Michael Sahota said: Scrum or Kanban? YES! (Model for relationship btw #Scrum #Kanban based on #lssc10) #agile #lean […]

    [WORDPRESS HASHCASH] The comment’s server IP ( doesn’t match the comment’s URL host IP ( and so is spam.

  2. Hi Michael,
    I love this. Thank you so much for sharing it. I particularly like the concept of “Vale Kanban” 🙂
    At the risk of being seen to be not building bridges, I see GoodScrum as a style of Kanban. In that light, your matrix shows that Kanban provides a common language to describe a variety of processes in a variety of contexts. It also begs the question of how you would describe the style of Kanban in the centre of the matrix.

    • Michael Sahota says:

      Karl, thanks for your comments. I think you have hit on a crucial concept in terms of style of Kanban. Perhaps we need to build a catalog of KanbanPatterns to describe different styles of working: From production line style to naked planning style.

  3. Alan Hensel says:

    I’m really skeptical of the “7 year run” theory that you heard. With neither a detailed history of 7-year runs, nor any reason behind the number 7, it just sounds like an attempt to promote lean by burying its perceived predecessor ASAP.

    The level of precision is also suspect. When did Scrum “start”, and how will we know when it’s over? Scrum was first mentioned at OOPSLA in ’96, but I hadn’t heard of it until XP burst on the scene around 2000, and many others probably hadn’t heard of it until then, either. Either way, that would mean that Scrum is already long dead, a notion which is supported by neither anecdotes nor statistics ( ) …

    I think there is a lot of truth in Scrum, and the truest parts will leave a lasting imprint on our profession, even if the word “Scrum” disappears from our vocabularies forever. And who knows when that will be? Or cares, provided that our industry is changed for the better?

    Let me put another bee in your bonnet: 30 years.

    At the XP/Agile Universe conference in 2002, I heard Martin Fowler’s keynote speech, where he wondered aloud about whether XP was a paradigm shift. I thought “oh no, I hope not!” You see, I had been hoping that Agile would sweep the industry in the next few years, certainly by ’05 at the latest, but one key thing about paradigm shifts is that they take about 30 years to become widely accepted. The reason is, the old generation has to pass away first.

    Consider a previous paradigm shift: Object Oriented Programming. It started around sometime around 1967/68 with Smalltalk. Broad industry-wide acceptance of OO? Late ’90s. About 30 years.

    Well, eight years have passed since that speculative speech by Fowler. I have to say, it’s looking like he was right. It looks like Agile coaches have their work cut out for them for the next 20 years.

    Note that I am not saying that some people are incapable of “getting it” and you just have to wait for them to pass away. It’s not that they can’t; it’s that they won’t, if you’re not there to explain it. Those that we can reach can be helped, but you can’t walk in uninvited. So, what I’m really saying is that, looking at the big picture, expect invitations from the last hold-outs around 2030, after which hiring an Agile coach will seem about as strange as hiring an OO consultant today.

    (I apologize for this being tangential to the main point of the original post. The article as a whole is very good and thought-provoking. Thank you.)


    • Michael Sahota says:

      Alan, thank you for sharing your thoughts.

      I agree with your notion of looking at the long run as I am a believer in Kuhn’s theory of scientific revolution – I believe this is where the origin of paradigm shift comes from although you did not mention it explicitly.

      I had a similar reaction to you when I first heard the theory of the 7 year run. I am not saying I subscribe to it or agree with it – I don’t have enough data. My purpose was to share with a larger audience what I saw, heard and digested out of the conference. The timeline sketch I heard is 1990 – Waterfall, 1998 – XP, 2004 – Scrum, 2011? – Kanban. This timeline doesn’t match what I see for Toronto (a bit of a laggard due to banks), however, I can see this matching the story in the U.S. So, perhaps this is more about shift within the Agile community than within the overall industry.

      I appreciate the complement on the article.

      – Michael

    • Michael Sahota says:

      Readers – check these links out; very cool – I can sense the discipline and focus. Seems like there is a difference between “new” Kanban and Scrum-evolved Kanban.

      Marko – You ask a difficult question … maybe you should answer as you are the expert on your process? Overall, this feels like Naked Planning since there is just a big TODO area for team. I would put it more in the direction of repeatable because of the high level of structure in your definition of Ready. Seems like you attain focus through stop-the-line.

  4. Michael, thanks for that great article. Coming from an iteration based process (not exactly scrum…) I shifted more and more to kanban. Focusing on flow and limiting work in progress turned out to work better for our small team, which is building and maintaining a typical web site. The “strictness” of Scrum was not helping here. But it really depends on the environment and on the maturity of the team.

  5. Personally I think concepts like cross-functional teams, not bigger than 7 +/-2 people work great no matter which approach you choose. I tend to analyze impact of implementing them not from a perspective of a method team uses, but from a perspective of the team themselves. You either are able to have cross-functional teams or you are not, for whatever reason. It isn’t really connected with the area on the diagram your team is in. For example I know a company where cross-functional teams are non-existent because of political reasons. That doesn’t prevent adoption of Scrum, although it is easier to get through with Kanban.

    I also think areas you created should overlap with each other. There are many projects where at least a few approaches would work well, including non-agile ones, and a specific choice would depend on people in the team, not on organization or project.

    What is clearly seen however is how far is maintenance work (support Kanban) from work on a new product (Scrum/Naked Planning). This is where differences between different approaches play their role. I always found time-boxing hard in maintenance teams, especially those with fixed deadlines for applying bug fixes. The same would be probably with production line although I have no experience in the area. But these areas are pretty far from each other and that’s why different approaches would work best.

    When we discuss surrounding areas there aren’t as many differences and interchanging, adjusting or mixing different methods would work well. Actually it should be encouraged as I believe you should adjust tools to people, not the other way around.

    • Michael Sahota says:

      Pawel, thank you for sharing your thoughts. On the topic of cross-functional teams, I think the important aspect (especially for innovation) is the collaboration between people with different skill sets (they may be on the same team or not).

      I also agree wholeheartedly that the areas in the graph should overlap. I tried a drawing with overlapping and it was unreadable. That’s when I decided to use dashed lines to show where a process style plays best.

  6. Jussi Mäkelä says:

    I really enjoyed this article and I will certainly be telling about it to my friends. Very well put and quite helpful!

    I agree with Karl though, I would be very interested in hearing your definition of the Kanban in the middle of the diagram.

  7. Hi,

    I enjoyed this well written article. It helped me explore even more about Kanban position into the Agile world dominated by now traditional Scrum and XP. I also like to share my perspective about Kanban vs. Scrum through this small article from my blog . Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *