In Defense of Kanban

June 8, 2013 — Posted by Al Shalloway

As many folks know, Net Objectives does both Scrum and Kanban. Admittedly, our Scrum is very much like Scrumban (or Scrum done under the context of Lean) but it is still an implementation of Scrum.  Scrum, as it normally manifests itself, has several challenges in that it requires teams to learn too much about how to apply it (much is know that hasn't been incorporated into it) and many teams try it when it really isn't the best framework for their situation. 

Challenges such as an inability to form true teams, close the gap between coding and testing and the resulting unfinished stories at the end of sprints has many teams abandon the true Scrum practices of cross-functional teams that are truly time-boxed.  Some in the Scrum community have called this Scrum-but, a demeaning term which I've always disliked for two reasons.  First, it is disrespectful, and second, it hides the fact that most of poorly practiced Scrum is a result of Scrum the lack of most of the Scrum thought leaders not stressing the Lean principles on which Scrum is based and why it works.

The new vogue now is for Scrum teams to drop time-boxing and cross-functional teams and say they are doing Kanban.  I suppose the logic is that Kanban doesn't have these.  While true, Kanban is not defined by not having iterations or not needing cross-functional teams.  It is defined by visibility, managing flow, explicit policies, a white-box process, and continuous improvement with PDCA.  Let me be clear - if you have been doing Scrum and have stopped time-boxing and don't have devs and testers working together you are not doing Kanban.  You are not even doing a shallow version of Kanban. You are not really doing any well-defined Agile method/framework.  END OF STORY. (but not the end of the blog).

This actually reminds me of a company I contracted with over a decade ago. They claimed they did XP, but when I asked them how they did XP, they defined it in terms of what they didn't do: we don't document, we don't do major designs up front, we don't ...  Unfortunately, they also didn't pair program, write tests up-front, do continuous integration - bottom line, they did not do XP.  Methods are not defined by what you don't do alone.  They are defined by what you do and what you don't do. In most cases, when a method/framework doesn't do something, there is something else it does to achieve the intent of what other methods may have practices for. For example, Kanban's explicit policies and managing WIP accomplishes what cross-functional teams and time-boxing purports to do.

What's unfortunate, however, is that many folks don't understand this.  This belief, along with, oddly enough, the belief that you should start with Scrum and then move to Kanban, is widely promoted by folks who have never done Kanban but make their living with Scrum. It's not unlike Chevy dealers telling prospective customers what's wrong with Fords.  My advice is that when deciding between the two, actually, not a good move, in that you should learn from both.  So, perhaps I'll say "when learning about the two"  learn from someone who has done both, someone who can tell you what the advantages and disadvantages are.  There are lots of these folks around, btw, so I am not saying you should pick us (although that'd be a good thing, I assure you).

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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