Why Contrasting Scrumban and Kanban Belies a Lack of Understanding of Both

July 4, 2013 — Posted by Al Shalloway

First a new theory is attacked as absurd, then it is admitted to be true, but obvious and insignificant; finally it is seen to be so important that its adversaries claim they themselves discovered it.  William James

Only taxi drivers, bartenders and barbers are entitled to an opinion on everything. Al Shalloway

In the Lean-Agile development space there is much misinformation being floated around by folks who have never truly used a method they are discussing. This makes it difficult for those unfamiliar with these methods to learn what they are.  This misinformation is equally harmful whether it is favorable or unfavorable to the method since it confuses the issue.  I recently read a blog comparing Scrumban to Kanban. It struck me as particularly odd, because if one understands both of these, one would never say they liked one over the other in a general way.  In a particular instance one might chose one over the other, but one is not generally better than another.  Let's look at why as a way to better understand both Scrumban and Kanban.

First, we must recognize that there are two ways to consider Scrumban and Kanban.  Scrumban was created as a transition method from Scrum to Kanban. However, it has since been suggested that Scrumban is a viable method of Agile team management on its own. With Kanban, the overloading of the term had the reverse sequence.  First, it was a Lean-Agile management method using WIP limits to manage flow (Kanban software development) and after a few years a transition method to improve the efficiency of one's process based on Kanban software development was created by David Anderson and labeled the Kanban Method. 

The aforementioned blog didn't mention this over-loading of names with the author clearly thinking of Scrumban and Kanban as only software development methods.  In this blog, I'll discuss why it misses the point to compare Scrumban and Kanban as either transition methods or as development methods. In doing so, we'll learn a bit more about each..

Comparing Scrumban and Kanban as Transition Methods

Scrumban as originally put forward is a transition method from Scrum to Kanban Software development.  The Kanban Method is a transition method from anything to Kanban Software development. The transition methods are reasonably the same, however, except Scrumban always starts with a team doing Scrum and Kanban starts anywhere.  Trying to say which you like better is silly.  When you are going from Scrum to Kanban, they are the same (so the comparison is meaningless).  If you aren't already doing Scrum, then you can't be doing Scrumban and the comparison is still meaningless.

Comparing Scrumban and Kanban as Software Development Methods

Scrumban as a software development process s often thought of as Scrum with Lean practices in it. But that's not what Scrumban is.  Scrumban as a software development method has Lean as its foundation.  Lean's foundation is quite different from Scrum's foundation.  Lean suggests white box process, explicit policies, being inclusive of management, recognizing the laws of flow, amongst other.  These are not only not part of the Scrum framework, the counter several fundamental aspects of classic Scrum. Scrumban is managing flow with explicit policies, pull, limiting WIP, creating visibility, and continuous learning while having iterations and being organized around teams. Corey Ladas' brilliant book on Scrumban - Scrumban - Essays on Kanban Systems for Lean Software Development -  makes it very clear that Scrumban and the Kanban Software Development process have exactly the same mindset. 

Scrumban and Kanban differ as development methods only in that Scrumban is organized around teams and has iterations while Kanban may or may not have teams and does not have iterations. That's it.  So if one were to compare the two, one should ask these two questions -  1) are their times I should use iterations and are there times I shouldn't? and 2) can I create a team? The reason we ask about can I create a team instead of should I have a team is because if you can create one you should almost certainly have one. 

These would be good questions.  But one is not really comparing the methods against each other.  Rather, one is asking, for a particular situation, which is better.  Comparing the two would be like saying "I like screwdrivers better than hammers."  One can only compare screwdrivers and hammers in the situation one is in.  Neither are inherently better than the other.

So, since I haven't heard these questions in the comments/blogs I've seen comparing the methods, I'll ask them now.  

Is timeboxing useful in this situation?

Inexperienced teams often need the discipline time-boxing brings forth.  So, for those new to agile, particularly those unfamiliar with ATDD and TDD, Scrumban has some advantages.  The iterations bring about some discipline.  However, if you have a team that has integrated testing methods, iterations may not provide more value than their cost.  Furthermore, if you are in a maintenance area, iterations provide no value at all as work is typically done piece meal as it comes in.  Time-boxing can also be added to Kanban in the form of time-boxing the work items themselves. In other words, if we think something should take 2 days, then we can focus on it happening in  2 days and take action if it gets bogged down.  In any event, the establishment of cadence (when teams do reviews, when they look at the product backlog, when they demo to the customer-proxy, ...) is critical. Hence, whether you opt for Scrumban or Kanban has little to do with the methods, but rather to do with your team.

Can I create a cross-functional team?

If you can create cross-functional teams, then with few caveats, you almost certainly should.  Cross-functional teams are the best method of getting things done.  The main caveat is that you shouldn't do this if doing so removes people from other teams where they are needed (see Successful Pilots Can Sometimes Harm Agile Organizations). Teams are often not needed in support and maintenance areas as well.  If you can't create teams effectively, then Kanban is your only choice.


I guess people are entitled to their own opinions regardless of their experience level with the methods under discussion.  Just because someone hasn't made something work doesn't mean it can't work.  As has been pointed out by many in the Scrum community, Scrum often fails in certain situations because people aren't really doing it.  Contrasting methods based on the results achieved by people doing it incorrectly is just silly or worse.

Scrumban and Kanban are both software development methods and transition methods.  As software development methods they are not very different.  One would chose one over the other on the basis of the ability to establish teams and on whether iterations were useful.  As transition methods, if you're doing Scrum, then they are the same.  If you're not, then you can only do Kanban. The issue that seems to be neglected by most in the Lean-Agile space is when/where should I apply a method?  Few talk about this.

Hope this helps clear up some confusion.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



First of all I would like to say that I fully agree with your post. The only aspect of your post where I personally see room for improvement is your terminology:

For me Scrumban and Kanban (and also Scrum) are neither software development methods nor software development processes. I see them as project management methods, i.e. methods that people use to manage the work (e.g. software development process activities) that needs to be done in order to generate the required project deliverables.



Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban