Common Myths of Kanban

September 26, 2010 — Posted by Al Shalloway

Kanban has come of age, and what that means is that there are now just as many (maybe more) misinterpretations of it than ever before. I've seen this happen when XP, Scrum and Lean became popular - so this is no surprise. There are some differences, however. With Kanban, there are thought leaders, such as myself, who are willing to say what Kanban is and not just say "it's what you do after you understand it." While Kanban isn't a thing actually, it is somewhat well-defined and it is easy to tell if many of the things said about it are true. Here are some of the most common misinterpretations I've heard.

Contents:

Lean Development is a prescriptive approach to work in social systems

Lean is not at all prescriptive. Lean is about thinking. Yes, it does suggest you should always attend to time and make sure you are not overloading teams. But how you do it depends on the context of the problem. Lean is about learning – not acting without thought. See my blog Rethinking the Practices of Scrum – or What Would Chris Alexander Say? for more.

Kanban suggests linear work and requires too many hand-offs

Lean manufacturing may assume linear work, but not Lean software development (nor Kanban). Kanban boards may often appear to be linear but Kanban boards reflect the way people are doing the work. Hence, if people are working linearly, the board will reflect that. However, Kanban boards can also reflect non-linear work. One must also recognize that a Kanban board does not reflect the people doing the work but rather reflects the flow of the work being done. Hence if a board looks like:

Backlog   Analysis   Design   Code   Test   Done

 

it is not suggesting that the work be done by different people and hand things off. It just shows the states the work progresses through. In this case, it's on the backlog, in analysis, being designed, coded, tested or completed. It could very well be the same person doing the work. The second misconception is that the board tells you to break things down into these steps. Actually, it doesn't (or shouldn't). The board should be a reflection of the work being done. So different columns on the board should reflect the different steps the team is doing. If the team swarms on multiple steps, then the Kanban board should only have one column for that. Essentially the Kanban board has one column for each type of work the team is doing. The explicit policy for how it gets to that step and out of that step also needs to be stated, but is not necessarily written on the board. Bottom line - if you don't like the process that you see on the board, change it (and then update the board). The board is there merely to reflect on your work so you can better change how you work.

Explicit policies are static, hard to change and/or inflexible

A Kanban board reflects the process that the team has stated that they follow. It is not something to be followed, but rather reflects what the team is doing. It is not meant to be static. If the team sees a better way to do the work, they should change their policy. An explicit policy can also have options to it. You can say "Under these circumstances, we do this. But if we have this, do that. ..." Being explicit does not limit what the policies you have can be. It just means they've been communicated from one team member to another.

Kanban has been successful because it is being done by early adopters

The following is an excerpt from my blog David Anderson's Kanban Book and the Myth of Early Adopters:

In the last few months, I've heard several people say Kanban's success is because it is early adopters who are applying it. I actually believe just the opposite is true. While Net Objectives consultants may be considered "early adopters" (we are always looking for the next best thing to offer our clients) most of the teams that have adopted Kanban or Scrumban are actually late adopters. That is, they have gone from non-agile or some kind of generic agile to Kanban/Scrumban. The reason is that they couldn't see how Scrum could work. Or, the teams weren't excited about doing Scrum.

Given that Scrum has a limited context in which it works without major disruption to an organization, this should not be surprising. Yes, I know Scrum is supposed to make impediments visible and have the company remove them. But making impediments painful is not the only way to make improvement in one's process.

Over the last couple of years, I've seen three groups for which Kanban is particularly useful:

  • Those doing maintenance work where time-boxing adds overhead with little value
  • Those who have specialized skills present which makes it difficult to create well-formed teams where each team member is only on one team
  • Those who are nervous about Agile and do not see how it will work for them

Kanban is useful for these three groups for different reasons. Respectively:

  • Kanban manages small pieces in a chaotic environment extremely well. And this is the situation most maintenance teams find themselves. Little overhead is added as estimation and planning the iteration is not needed (just prioritization).
  • For many organizations, specialization is the only viable route (despite what many in the Agile community would say). Stress testing experts may be an extreme case in skills, but many people are aware of companies that have limited numbers of staff knowledgeable of the intricacies of their own legacy code.
  • Kanban was designed to start where people are. This enables a smooth transition from current to incremental delivery with much less disruptions.

It is interesting to note that the last two groups are often late adopters to Agile. For those having people with specialized skills, they've often avoided Agile because they don't see how Scrum or XP can work (neither can I, BTW). In the second, they don't want to try such a deep dive into a new method.

I think much of the reason Kanban has been successful is not because it has been adopted by early adopters, but rather because it was designed for late adopters (that is, those afraid of change). The fact is that many of the success stories of Kanban are now coming from late adopters of Agile – saying otherwise is merely marketing obfuscation. Kanban works not because who is adopting it, but because it was designed to be adopted in an incremental (dare I say, Agile) manner. Scrum, on the other hand, is a "jump in the water (may or may not be) fine." Kanban works because it truly manifests the principles of agility – respect people. Let them use what they know and let them turn up the volume, so to speak, of agility at their own pace. Don't force them into it because they'll know that's the right approach after they've done it. In other words, Kanban consultants tell their charges – "trust yourselves, don't trust us."

Better to start with Scrum and then go to Kanban

I have no idea where this comes from other than perhaps marketing hype. I don't know of any Kanban thought leader who has ever said this. There are times you want to start with Scrum, but there are times you want to start with a flow based method. It depends on several factors. Scrum is fine to start with if you either already have well-defined teams, or can easily get thm formed. Kanban is designed to start where you are so if you don't have well-defined teams and they'll be hard to form, I'd start with Kanban. Even if you have teams, but work on mostly small items or if there is some resistance to Agile methods, I'd still start with Kanban. For more information on which one to start with, look at one of webinars on different factors of this decision in our Business Driven Software Development. Session 3 is Where to Start Your Agile Transition while Session 4 is Team Agility: Scrum or Kanban? My own experience is that Kanban is easier to start with than Scrum, but that doesn't mean it is always the best place to start either.

Kanban doesn't respect people as much as other Agile methods

Kanban is based on Lean thinking. One of the pillars of Lean is Deming's respect people while looking to create an environment (system) for them to be productive in. I believe this misunderstanding comes about because Kanban talks about the work not the people – but this does not mean that we don't respect the people. Rather, its focus is on creating an environment that will facilitate the emergence of productive behavior. In many ways, this is more respectful than merely cheering people on. Kanban lets you start where you are with the roles you currently have. You don't need to say – "we're going to learn a new method where we will reorganize our teams, adopt new roles and rules." If you ask me, that's telling people they've been doing it the wrong way – which doesn't sound too respectful to me.

Kanban Doesn't Attend Enough to People

You can't really get people to do what you or they would like to do by just telling them to do it. People know what to do, they don't do what they know. You must create an environment within which they can work better. Focusing on the environment may not look like it is about the people, but it is. Kanban helps people by providing them with the tools (e.g., Kanban board) that create what the people need to know to get their job done (e.g., visibility of the work flow).

To make great change you need to be revolutionary while Kanban is evolutionary

Kanban believes in evolutionary change. The reason is so you don't overwhelm people with too much change. Traditional Agile methods may believe in dramatic changes, but that's difficult to do beyond the team level. Kanban enables the organization to change at the rate it can bear. The ability for a method to make significant change in an evolutionary way is revolutionary. When you stop to think about it, you'll actually realize that evolutionary change is about starting a method that will sustain itself and keep growing. This is what a learning organization truly is – being evolutionary over time to become revolutionary.

Where to go for more information

You can check out Net Objectives' resources.

If you are interested in training in Kanban, please send a note to Mike Shalloway – mike.shalloway @ netobjectives.com

If you'd like to follow my Lean-Kanban-Scrum ramblings, please follow me on twitter @alshalloway

If you'd like me to discuss more myths of Kanban, please loot at our Myths of Kanban Poll and respond.

Here are some other blogs you might find of interest:

 

Author: 

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.


Comments

Yeah, I've always disliked this aspect of the Scrum training I've lead -- not long after explaining how important teams are and after going over all the agile values and empowerment and how it's individuals and interactions over processes and tools, I start talking about a very disruptive and prescriptive process.

andrew
www.andrewfuqua.com

Great blog entry!

I have an opinion on why some have the "misgivings" you mentioned

- "Better to start with Scrum and then go to Kanban"
     
My perception is that scrum promotes team environments heavily and fosters collaboration. Kanban beginners see all of the workflow examples on the web like the one you give above and often see their waterfall process. They make the mistake of mapping the people and not the process as you stated. For that reason, scrum seems to promote teamwork better as a perception of the framework. I'm believe they equally practice teamwork improvements when implemented correctly, yet I also believe that some implementations are wrong and this is the cost.
     
Another possible reason is that scrum, arguably, does not tolerate changes in priorities mid-sprint very well. Some teams look to this for protection from change (not embracing change I know). Kanban allows change at the prioritization level and you can see many other levels introduced as well across the web via expedite columns, classes of service, etc. In order to mature companies where reprioritization is the norm and is done at the hour level, teams sometimes look for this false protection to solve what is really the root cause: bad planning, multiple POs, etc. I am not totally against solving the issue this way depending on the environment, however, a truly kaizen environment will not need this step as they will already be empowered to solve the problem themselves instead of manipulation through process.

- "Kanban doesn't respect people as much as other Agile methods" - same thing.

Re: myth that Kanban requires hand-offs and suggest linear work

The *first* thing I would point out here is that a Kanban board is a window to your existing process. Kanban doesn't require or suggest anything in terms of hand-offs or linear work. If it looks that way, that's more that your current process requires hand-offs and is linear.

Thanks for the clarification.  I sometimes refer to the Kanban board as a mirror of your process.  Don't blame what's in the mirror.  You don't follow the board, the board follows you.

Alan Shalloway, CEO Net Objectives

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

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
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
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, 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