Why ‘Kanban’ Is the Perfect Name After All

September 19, 2010 — Posted by Al Shalloway

When David Anderson originally named what is now called 'Kanban' Virtual Kanban System for Software Development. I, like many others, have said that it is a horrible name and very misleading. Kanban, which literally means 'signboard' is a method used in Lean Manufacturing that uses cards (called 'kanban cards') to signal when new materials are needed to be provided to a stage in the manufacturing process. It is the basis for pull systems and a cornerstone of lean manufacturing. David used the term 'virtual' because in software we don't use actual cards, but signal that new, upstream work can now proceed when work falls below a determined work in progress (WIP) limit.

There have been attempts at reducing the confusion by saying 'kanban' is the method of managing the 'Kanban' process. But this is such a subtle distinction that it has caused considerable confusion. Hence, the request by many of us in the Kanban community to have the name changed. I had relegated myself to the fact that it was not going to change but have since decided I like the name. I like the connotations, that, although possibly confusing, bring some clarity to the differences between Kanban and other Agile methods.

The Biggest Difference Between Scrum & Kanban Is Not Iterations

The biggest difference between Scrum and Kanban is not iterations, but rather that Kanban allows you to start where you are. Kanban is essentially a process whereby you start with your current process and make small, but frequent, changes to your process. Kanban supports this continuous process improvement by having the team use an explicitly defined process that is reflected on their Kanban board. Kanban suggests that each step, and even the queues between the steps, have limits on how many items can be being worked on at any time. This is called 'work in progress' (WIP).

There are some fundamental believes, not shared by the entire Agile community, that lie underneath this approach. There are:

  • That you can take a scientific view of software development to achieve an understanding of cause and effect
  • That explicitly defined processes aid in the learning of the team
  • That continuous improvement in small steps is better than infrequent (weekly would be considered infrequent) large jumps
  • That respecting people means you should not tell them they need to abandon their current approaches to start a new one

Why Kanban Is the Perfect Name

So why is Kanban the perfect name? Do we really want to use a name that has people continuously remind us that we are not doing manufacturing? The answer is, perhaps, that maybe we do want to be reminded that the laws of physics (or a comparable set of laws) apply to software engineering in the same way physics applies to manufacturing. These laws, of course, are the laws of product development flow. In a (very small) nutshell, they are:

  • The longer it takes to do something in calendar time, the more work it'll take as well, while almost certainly reduce quality
  • The more things you do at the same time the longer it takes to get something done
  • Delays cause waste
  • Working beyond your team's capacity will result in additional work to be done and lower quality at the same time
  • Queues in a process flow are highly correlated with the time it takes to get something through the process

What I believe is missing in our industry, what stops us from being a profession, is the insistence of many that either such laws don't exist because we are 'complex adaptive systems' (CAS) where cause and effect cannot be discovered or that we must rely on the creativity of our developers to solve complex problems and that a scientific approach is too restrictive or somehow limiting. These beliefs are impediments to our industry becoming a true profession. They are not based on experience, but rather on repeatedly describing theories that I suggest few people truly understand (CAS). While it is true that there is a history of over-management in our industry, it is equally true that developers have strongly insisted that software is more of an art form than a science. While there is an artistic aspect to software design, there is a scientific (or more accurately, an engineering) aspect to it as well.

In any event, I believe having this conversation – about the science underlying software development, is a key to creating a true profession. Recent developments in the software community - the success of Kanban and the migration of many teams from Scrum to Kanban or the hybrid Scrumban – provide a tremendous amount of evidence that something fundamental is going on here. Having been raised a scientist, I believe it is important to follow evidence when one's understanding doesn't match reality. This is true even at the endangerment of one's livelihood. In the end, I believe we will look back and see that the way the scientific approach to software has been discounted is very analogous to the way Agile itself was originally discounted.

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.


Hi Alan,

You've got strange ideas abut CAS and Science in general. Whilst I agree that some people have discovered a preference for Kanban or Scrumban over Scrum, we cannot say that their preference has any scientific basis. There as been no scientific studies, no attempt at applying scientific rigour. Some folk like Kanban and find that it works better for them in their context over Scrum. This is a long way from proving that there are immutable "scientific laws" that apply to software as equally as well as they apply to manufacturing.

Try submitting a paper claiming such a thing to Nature or Scientific America and you will quickly discover that the bar for scientific proof is still higher then mere anecdote and wishful opinion thankfully.

Now I am not dismissing your opinion, but lets leave science out of it! One last point on science. The science of manufacturing is the mechanical science of casual relationships, cause and effect. Some describe this science as Newtonian science. Using Newtonian science, it is pretty difficult to say almost anything definitive about Software Development. For a start measurement in software is illusive. We all agree that we want to deliver value, yet we choose to measure everything else. Lines of Code, Complexity, Effort, everything other then value. Why? Well because value can't be reduced to a SI unit :)

Software development, like other areas of human activity reminds us that not all systems are ordered, and there is not always a clear mathematical relationship between cause and effect. Hence we can't describe all phenomena using quantitative Newtonian laws.

Fortunately science has recognised this truth, and has been extended in a number of ways to help us understand the un-ordered world. Social sciences is a case in point. CAS theory as been applied to social sciences and people have attempted to apply the same ideas to business organisations and software development. But even here nothing is proven.

So for the meanwhile we all have to get use to the unknown. We don't know why certain teams succeed and why others do not. There are lots of factors involved. We can't say that Scrum or Kanban is the defining factor. This doesn't stop us forming opinions, or even forwarding arguments, but lets not claim that our opinions are scientific, unless of course we are willing to back them up with rigourous scientific proof!



There was science before there was precise measurement.  Science means you make hypothesis and test them with experiments. Having controlled experiments work best but in the real world of software development this is hard to achieve.  I will not argue with you about this, however.  I, and many of our clients, have achieved results that were clearly, to those involved, not achievable with standard iterative, time-boxed methods.  If one waits for rigourous scientific proof for innovation one  will wait a long time.  I am happy to have successful clients - I prefer that over getting papers published in scientific journals.

Alan Shalloway, CEO Net Objectives

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