Why We Need a New Meaning/Name for Kanban

July 13, 2013 — Posted by Al Shalloway

What Is Kanban?

When Kanban first came out for software development, it was not the Kanban Method.  It was A Kanban System for Software Engineering.  It was a system for managing flow in software development and maintenance teams.  It was developed over a few years by several different people at Microsoft and Corbis.  It was essentially what I have sometimes referred to as “Team Kanban” and is actually what most folks mean by Kanban.  David Anderson’s book, Kanban: Successful Evolutionary Change for Your Technology Business, introduced the Kanban method, a way of effecting evolutionary improvement.  In many ways the Kanban Method is little more than Lean Kaizen with a particular starting approach and with some additional, sometimes useful, practices (e.g., service level agreements).  I tried sorting this out a couple of years ago with my article Demystifying Kanban and several webinars on that theme that Kanban is an overloaded term meaning all of the following:

  • A signal card and usually referred to as “small k Kanban”
  • A team management method using Kanban to manage flow and usually referred to as capital K Kanban.  This is essentially the original Kanban system for software engineering which I will refer to from this point on as Kanban Software Development
  • A thought process
  • A transition, or education, method (the Kanban Method)

While I have been troubled about this for years, even suggesting years back that we needed to come up with different terms for different things, I thought it mostly was an annoyance, but not dangerous.  Recent insights and events has had me shift my thinking here.

It is quite clear that a number of Kanban consultants, particularly those in Lean Kanban University, are attempting to usurp the term to mean that Kanban is the Kanban Method and that any use of Kanban other than the Kanban Method is a “shallow implementation of Kanban.”  I am not trying to draw any aspersions to their motivations for this.  I am certain they feel they are doing what is in everyone’s best interest, as the Scrum folks did when they blurred the terms Scrum and Agile.  But I do not agree that equating Kanban (in the sense of the original Kanban) with the Kanban Method is beneficial for most in the industry.

Kanban and Lean

I have long felt that Kanban (both software development and method) is a subset of Lean Software Development.  Our industry will forever be indebted to David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others who brought Kanban into existence.  Kanban software development opened ways of doing Agile software development to companies for which cross-functional teams were either impossible or prohibitive or who couldn’t otherwise make the jump to Scrum.

However, I have never felt that Kanban, by anyone’s definition, was as complete as Lean.  If this distinction was always made clear by Kanban proponents I might not be so worried.  But, as also happened in the early adoption of Scrum, many Kanban proponents say the Kanban Method can be applied anywhere.  Well, true, it can, but that doesn’t make it the best thing to be used anywhere.

It turns out that although Net Objectives uses Kanban quite frequently, we only sometimes (20-30%) use the Kanban Method as a starting point.    First, we always look to see where folks are.  How and where to start doesn't always include the development organization.  When it does and we want to improve flow, we have found that there are 4 different places to start an Agile transition:

  1. Load level and size of items hitting the development organization
  2. How the folks in the value stream are organized to work with each other
  3. Workflow order
  4. Managing queues with Kanban

Load Leveling and Size of Items.  One can make drastic improvements in one’s development efforts by using Minimum Business Increments (MBIs, also referred to as MMFs, MVFs, MVPs, …), delivering the most important value quickest.  Even just splitting up the delivery into smaller batches can make a big difference. Having two three-month projects is an improvement over one six month project no matter how you look at it.  I find it ironic that this is ignored by the Kanban Method as Eli Goldratt, creator of Theory of Constraints, a cornerstone of the Kanban Method, once said “often reducing batch size is all it takes to bring a system back into control.” Smaller batches starting out is often a brilliant way to start.

Team structure. I have long held that Scrum’s success is primarily based on two things, 1) smaller batches (a result of the Scrum timebox) and 2) cross-functional teams (see a somewhat dated blog from May 2007 Challenging why (not if) Scrum works). These two practices implicitly manage flow.  Teams are incredibly useful and should be created almost wherever possible.  While Kanban Software Development provides for Agile software development without true teams, it doesn’t mean they shouldn’t be used when possible. Some level of team (often a combination of a core team that’s stable with a few rotating members) is virtually always possible. Many challenges can be solved simply by temporarily assigning a member of a component team to a new application development team that requires changes to the component team.  Easy to do, great results.

Workflow order.  Very often teams develop software in the wrong workflow order.  The development team takes a preliminary conversation about what to do and goes off and writes the code. The test-team goes off and builds tests and then after the software has been written, everyone gets together to see the results.  While this is often called “normal” it is not very effective.  Methods such as Acceptance Test-Driven Development/Behavioral Driven Development can be done in a light-weight manner that provides immediate results by changing the order of the workflow at the start of the project and avoiding much waste and rework.  People collaborate early on to understand the true challenge and solution and what it means to implement it.  This is something that can virtually always be done to some beneficial level.

Managing queues with Kanban. The one stated thing to do in the Kanban method. There is no question this is useful.   But it is not always a good place to start.  Folks often don’t know how to set their work-in-progress limits – causing frustration right from the beginning.  The steps discussed in Mr. Anderson’s book include making several agreement near the beginning.  These are often difficult to achieve at the start.   But, perhaps more importantly, the size of the queues may be due to other issues that can’t be solved merely by managing them.  Focusing on queue size, which is a result of poor workload, poor team structure and poor workflow order is attempting to solve the effect without being clear of the cause. 

Why Does This Matter?

Since raising these issues I have been repeatedly told that the Kanban Method doesn’t preclude any of the items I am talking about and doesn’t discuss order of adoption.  Let me take the “doesn’t preclude” argument first.  We all know that newbies to a method are going to try what their consultants tell them to look at first.  If it’s not included as something to do it may as well be precluded.  Especially if your consultant talks about Ha Shu Ri (a training metaphor I dislike but which emphasizes that beginners are not going to look outside the beginning set).  Take a 5 minute diversion and read the first few paragraphs (and watch the video) over at Patterns of Non-Observation.  One thing Kanban Software Development has taught us is that explicitly working and discussing our challenges provides much more power and value than an implicit approach. I find it ironic the Kanban Method doesn't take advantage of this insight.

Regarding order, the Kanban method prescribes six things.  They may not prescribe an order for these six, but they are all in front of 7, 8, and 9 (my first three mentioned earlier).  Taiichi Ohno suggests team structure and workflow order must be set prior to attempting to establish flow with a kanban system.  So, we see that the Kanban method ignores the starting points of the two foundations on which it is based – Theory of Constraints and Lean.

The danger of the Kanban Method is that it ignores other first actions that might provide great value right at the start and then focuses on managing queues with WIP limits and thereby continues to ignore these issues.  Our experience with hundreds of clients demonstrates that in almost all cases, some improvements to managing the work load level coming in, team structure or workflow order can be achieved at the very beginning.  And, of course, one only undertakes any of these actions after looking at the value stream and understanding where you are.

Back to the Need for a New “Kanban” Term

So, back to my original point – the need for a new meaning of Kanban.  The way the industry is going now, I see the term Kanban as being usurped by a relatively small number of people to mean the Kanban Method.  In my mind, this is only in the best interests of those making their livelihood off the Kanban Method.  The rest of us should have a term for Kanban that means the entire range of thinking.  That is:

  • kanban as a signaling mechanism
  • Kanban Software Development
  • Kanban Method (a prescribed method for starting Kanban)
  • The thought process behind Kanban

I’ve been reading Karl Scotland’s work on Kanban Thinking. I really like it.  It suggests we find models based on the principles and practices of Kanban that we can use in our own particular situations be it for:

  • Managing workload
  • Managing our project
  • Transitioning to better methods
  • Whatever …

I wrote this blog without Karl’s involvement, but intend for it to strengthen the need for both developing Kanban Thinking and to have “Kanban” refer to this broader term and not merely a prescribed method that only, in my mind, is best in a small percentage of situations.

From this point on, I suggest we use the term “Kanban” to mean “Kanban-Thinking” and to include all of the ways of using Kanban that I have been talking about.

Be Clear, I'm Not Suggesting We Do More at the Start

There is a lot of value in focusing on a few things to change at the start.  And one should always see where one is before undertaking any change.  I have found there is great value in doing a value stream map, which can be done in the form of a Kanban board (see Mapping a Value Stream to a Kanban Board on our Lightning Webinars page).  But it is an easy matter to consider doing 4-5 things and then picking the one or two that make the most sense.  Sometimes something simple opens up more complex and beneficial things to be accomplished with less effort.

If you want to discuss this more, head over to the Lean-Agile Yahoo User group.  I'll be starting a few conversations there in just another couple of minutes.

Al Shalloway
CEO, Net Objectives

Related blogs of interest:

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.


Al, we agree that Kanban is very rarely, if ever, only the six practices and it includes more. What you say though is that the assumption is that we should start with the Kanban method practices before going further.

Well, I can't say what the original intent was when Kanban method was defined, but I can say that in my experience this assumption is false. The whole discussion around different ways of applying Kanban is not only about the order of introducing practices of the method. It is about the order of interacting with an org.

For me, the spirit of Kanban (if there even is such a thing) is all about inclusiveness and not following a list. As long as I typically see value in limiting work in progress it's often difficult to put that high on the list. At the same time ATDD can be both welcome and easy to implement.

I mean, it is always contextual and I don't think an method, even such flexible one as Kanban method, can ever become a recipe for improvements. And I don't think Kanban method was ever intended this to be one.

Hello. And Bye.

I am not sure if we agree or disagree.  I agree we shouldn't just start with those 6 things.  But I was also told the Kanban method does not include starting by looking at changes to the team.  I actually think most folks doing the Kanban Method aren't doing it the way LKU is certifying folks to be doing it in. 

But my point is also this, any method one takes should investigate the three things I mentioned explicitly.  Not doing so is a high risk.  Saying you could add it on your own is fine, but then you should not say you can apply Kanban Method anywhere because many things you need will be left out.

I think might be better off moved to the Lean-Agile Group if you want to discuss further.



Hi Alan:

My two cents.

Other (clearly wrong) uses of the term "Kanban"

- "The Kanban", referring to the visual board, IMHO as a contraction of "kanban board", term popularized by Kenji Hiranabe in http://www.infoq.com/articles/hiranabe-lean-agile-kanban
To avoid this misunderstanding we need a better term.

- The "kanbans" referring to the workitems. IME because the people misunderstood the literal translation from Japanese. In the "flowgrams" the kanbans are the empty slots defined by WIP limits.
Myu proposition. In the standard design of the flowgram show explicitly the empty slots (e.g as empty squares)

As I can not edit my previous comment, I want to clarify the "flowgram" term.
Is the name that I give to the "kanban board" or "card wall". I prefer this name because it is more clear about the function of the visual board: to visualize the flow.


I personally prefer focusing on Lean as the brand name. We've called our events Lean Kanban, which was right. But then spoken mostly of Kanban, which was wrong. This has contributed to confusion among our customers between the two terms. They have wrongly assumed them to be interchangeable.

As you say in the post, Kanban is a subset of Lean. You focus on Kanban Software as a subset of Lean Software. I would abstract that to apply in any domain. Kanban makes it possible to implement Lean, but it isn't Lean. You need the whole package to be successful.

* Kanban makes it easier to optimize the whole by visualizing the value stream. But it doesn't by itself complete the optimization.

* Kanban helps to eliminate waste by increasing transparency of communication and process management. This can help to reduce pressure for unnecessary features, highlight unfinished inventory, reduce/improve handoffs, cut down on task switching, and reduce delays. But other Lean techniques are also needed to eliminate these wastes. And Kanban by itself has no effect on technical debt and defects.

* Kanban can help to highlight where autonomation is necessary. But it certainly isn't autonomation by itself. By definition these are technical practices, ie TDD, monitoring, automated code deployment, etc. An organization cannot successfully sustain a Lean rate of delivery without autonomation.

* Kanban can be a tool for identifying targets for kaizen and managing implementation. But it cannot by itself find all possible kaizen targets. And it certainly isn't a synonym for kaizen (or kaikaku for that matter).

* Kanban is needed to connect the work cells in a value stream and to bring more clarity into their internal processes, but the Kanban is blind to the human dynamics at play along the way. Explicit policies can aid in standardizing the most critical handoffs. But most human interactions will always rely on implicit understandings. The dedicated, cross functional (80/20 rule) teams that Scrum urges us toward can be a tough goal. But they aim in the right direction and are the right ideal in contrast to the waterfall's matrix of interchangeable 'resources'. I would suggest the co-located aspect is a bridge too far in today's world of far flung talent. But I certainly agree that team and organizational human dynamics are crucially, crucially important. And they are right there in the Lean principle of Respecting People.

* We can use the Kanban to show that we have deferred commitment. But the Kanban doesn't itself effect that deferral. We do so through good Agile analysis techniques for deliverables that can be sequentially iterated and through set based design/development for those that cannot.

* Etc etc.

I guess I would summarize by suggesting that we should avoid overloading Kanban itself and instead let it serve in IT the same purpose it serves elsewhere - as a mechanism for visualizing tactical progress and measuring improvement in order to identify strategic opportunities.

Note also that I say IT, in contrast to software development. I would strongly urge that we be more inclusive of all the practitioners in the technical domain.

Let it be Lean IT.

Jon:Thanks.  I'll take credit/blame for the Lean-Kanban moniker.  When the Miami Lean-Kanban conference in 2009 was being formed it was going to be a Kanban conference and I convinced David it should have the name Lean-Kanban.  Since then (even then :) ) it's been like you say.  This is why I started the Lean-Agile initiative.  We need to avoid brands in the third generation of Agile.  Extending Scrum with Lean is not the same as doing Agile under lean principles.  LKU has so modified the meaning of Kanban from what it originally was, that it may be impossible to recover from that.

The main point is we should not be approaching our problems with prescribed methods (which Scrum and Kanban Method in their own way) are.


No worries, you can comment here if you really want to.  But it looks like this blog has stirred up some interest and it will be much easier to comment on it at


Everybody welcome.

Al Shalloway

My early experience with Lean came well ahead of the agile software movement, and the introduction of the Kanban Method for software development brought some concern, mainly because the term kanban already in very common use meant something much simpler and was a potential source of confusion where strong lean cultures already existed. I do like the Kanban board applied to software, but in my mind it actually represents many kanbans and embodies additional lean concepts not specific to the original kanban concept: addressing the entire value stream, load-leveling(heijunka), and other aspects drove new complexity into the word... and in conversation with production people, you end up having to clarify which you are talking about - the lean school and the newer software school had different concepts in mind. I think the Kanban Board a beautiful idea... it creates a view of software development that floor supervisors would look for in manufacturing. It helps expose constraints, show the difficult teamwork dynamics, and ultimately drive solutions and resources to the need. Learning to see is one of the very hard things in software that the Kanban board helps greatly with. That said... I also worried that not highlighting individually the other lean elements introduced meant we might have skipped over some of the lean principles. Of the four definitions Al mentions... only the first is from the original lean mindset; we (the software community) added the other three. I guess I like the original vector of Lean Software Development... because it helped push you back to some of the lean tools and concepts - the pursuit of perfection, set-based design, the A3 process, etc. - so many things that are not specific to software and many which we struggle to formally introduce as tools in the software community. The Kanban board - and all the synergy it suggests - I can still map to the original lean principles. Naming... is one of those things that makes me crazy at times; the phrase Knowledge Management meant something profound and new - until the market jumped on board and scattered most of the important concepts to the wind. I had a tech writer explain she was object-oriented, so I asked her to describe how she was polymorphic. I will jump over to the group and see how things are developing.

I have started calling the Kanban Method "LKU Kanban" since it is the method those in Lean Kanban University espouse.  Many (most?) of the original members of LKU are no longer members of it (I being the co-founder and past member).  Most of us ex LKUers don't follow the Kanban Method but do something else. Scrum is to Agile the way the Kanban Method (LKU Kanban I mean) is to Kanban.  Using the two interchangeably just causes confusion.

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