You are here

What is Kanban?

Submitted by Joseph Hurtado on Mon, 07/29/2013 - 23:51

What is Kanban? And what can we learn from Open Source?

Kanban Success as an Agile and Lean Method

Kanban is becoming an important part of Agile Software Development and IT, VersionOne’s authoritative 2013 State of Agile Survey reveals that Kanban has doubled in adoption among the Agile methodologies, and is frequently used as an alternative to Scrum.

Kanban’s unique position as the first Ultra Light Method, coupled with it’s powerful knowledge library from it’s Lean and Agile influences have motivated people all across Software Development, IT and beyond to use it.

Troubling News and Confusion Regarding Kanban

However, despite Kanban’s Agile & Lean heritage, David Anderson and LKU have distanced themselves from Agile, Software Development and IT. This is surprising considering that David was one of the pioneers of Agile, and his Kanban book and original work at Microsoft and Corbis were all done in the context of IT and Software Development.

Confusion does not end there though, as Al Shalloway mentioned recently in a related article, LKU has also distanced itself from Lean Development. What we end up with is one of the leaders of the Kanban movement and his organization defining Kanban in a way that deviates from his previous work, it’s history, it’s influences and the way it is used today by the majority of practitioners in IT and Software Development.

Add to this confusion, the fact that there are other possible meanings for the word Kanban and you get the added element of ambiguity. Our objective on this article is to bring clarity into what Kanban truly is, especially in the context of Lean and Agile Software Development, and to propose a way forward for the future.

Kanban Meanings - Can We Clear Up the Confusion?

In summary the Kanban word has the following main meanings, also shown on the diagram below:

A Japanese Word for sign or billboard 看板. It was frequently used instead of a logo to identify a business or store.

A technique from TPS and Lean Manufacturing. Taiichi Ohno took the Japanese meaning of kanban and associated it with the stages of production flow at Toyota by using kanban cards.

An Agile and Lean Method for Software Development, IT and Business. At AgileLion Institute we call this Kanban Ace. It is also the meaning most people in IT or Software Development think of when they refer to Kanban. In Japanese this Kanban is usually called カンバン (Kamban.) Al Shalloway calls it Kanban for Teams, Corey Ladas calls it Scrumban. Although Kanban Ace is ideal for IT and software development, it is also the recommended method Eric Ries chose for Lean Startups, and it is also ideal for any business that wants to benefit from Kanban’s lightness and power.

The Kanban Method or LKU Kanban. Currently a view by LKU and David Anderson about Kanban that denies that Kanban is an Agile method, and takes away some Lean Development practices. To be more specific LKU Kanban moves away from IT and Software Development to focus on management methods and “evolutionary improvement.”

Now given that our list above helps us distinguish between the different names for Kanban, why is it that we still have an issue with confusion? Wouldn’t it be just a benign problem? An annoyance that can be solved with some background information? Unfortunately no.

The problem is that David Anderson, LKU and some other Kanban Consultants have decided that there can be only one valid Kanban method for business or even IT, theirs. In their view if you do not follow exactly The Kanban Method, dare to call Kanban Agile or add any Lean or Agile practices to it you are wrong. It reminds me of the frequent use of the Scrum-But moniker to attack people who adapt Scrum to their own reality, or even improve Scrum itself.

Kanban the Lean and Agile method is much larger than the Kanban Method, and with over 40 years of knowledge from leading thinkers from Lean and Agile it cannot be ignored.

Do We Need Another Name for Kanban?

Al Shalloway asked in his latest article about this issue with Kanban, if we needed another name for Kanban, the Lean and Agile Kanban method we use everyday. Here is a quote from him:

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… The rest of us should have a term for Kanban that means the entire range of [Kanban] thinking.

Al Shalloway proposed Kanban Thinking, a term coined by Karl Scotland that is much broader than the Kanban Method, it also aligns with the Lean and Agile nature of Kanban. The problem we see is that the Kanban Thinking concept is still evolving, Karl is writing a book on the subject, and he will certainly modify and expand Kanban Thinking in the future.

Learning from Open Source - Introducing Open Kanban

We believe that we need a term that embodies the Lean and Agile Kanban method under one stable umbrella. A concept for Kanban that we can all agree upon, but which is not controlled by any single person or organization, easily modifiable but at the same time sharing a common core. Does this sound familiar? These are precisely the ideas behind Open Source development! Why not create Open Kanban? Open Kanban would be a very light core, and on top of that companies, thought leaders and organizations can build upon without any Intellectual Property or method compliance issues.

The following are some minimal practices we propose as the core for Open Kanban, but Open Kanban should be agreed by consensus, we hope these ideas begin a conversation:

Visualize the workflow

When we are doing knowledge work, like programming a method, designing a user interface or writing a business report most of the work is invisible. This means that the output of your effort is much smaller than the effort involved, and the bulk of that effort cannot be easily seen.

Kanban deals with this challenge by using Kanban boards, visual representations of the flow of work that show how work items move from stage to the next.

This Kanban practice makes it easier to collaborate in a team setting, and also provides transparency about the process and the work everyone is doing. If you are a manager you can easily see at any moment what is the status of things, and if you are a team member you can see your impact on the overall work.

Visualizing the workflow is not limited to Kanban boards; one can also use signs and diagrams that the team can see in their work environment, like dashboards, performance metrics or other information radiators.

Lead using a team approach

Unless your organization is composed of just one person, you cannot achieve anything worthwhile without leading a team.

Although Kanban starts where you are, and does not need to modify any titles or roles in an organization, Kanban cannot work without a team to deliver value.

Teams and team leadership are crucial to deliver value. Both are needed in Kanban: good teams and good team leadership. No need for new roles or titles, but we do have a need for working teams, with leaders in them!

Limit Work in Progress

Research in the way the mind works, and countless experiences from Lean, the Theory of Constraints and Kanban itself confirm that to deliver value faster, with better flow and good team morale we need to focus and limit the number of things we do. Multitasking does not work.

Limiting the number of tasks the team attempts at each stage of the value stream helps us all to deliver value faster. Keeping the team focused helps them finish what they start. Limiting WIP even on a personal level is a key to success. Kanban has focus and limiting WIP as a core of the method.

Learn and improve continuously

The four previous practices ensure you are doing things better than before, and that you deliver more value. However to make sure you make a significant jump in innovation, morale, and value we must also stop, learn and apply our knowledge to improve!

It is worth mentioning that this practice aligns with the Agile value of embracing change, and there are many ways a Kanban team can implement this practice, you could have Retrospectives, Strategy Meetings or even Kaizen Groups.

Learning is the key concept before continuous improvement can ever happen! Once learning is part of the culture, part of the workflow, then improving continuously becomes easy.

These Open Kanban practices should be rooted in values that are Lean and Agile, those values should also be part of the core of Open Kanban. Although Mike Burrows has done some work regarding Kanban values, and how they align with the twelve principles of the Agile Manifesto, we still need agreement on a minimal set of values. Mike proposed 9 values, we propose 5:

Respect for people

At the core of Lean and TPS is respecting people. Respect for people also means assuming responsibility for your actions, and empowering others to take those actions.

Respect for people allows for delegation and the demand-pull that is crucial to Kanban. When any developer is able to take a story from the backlog and pull it to development or QA, he is able to do so because we respect him, we respect his skills, and we give him the ability to do so, we empower him through our respect.

Respect for people also aligns with sustainable pace in Agile, or Muri 無理 in Lean. If you respect your team you will not work them to death, or subject any worker to intellectual or physical demands that make it nearly impossible to succeed. An exhausted developer, manager or team are the perfect recipe for disaster. Kanban cannot succeed this way.

Courage

Respect for people is not enough; like Kent Beck noticed in order to improve or even correct mistakes we need courage. When a manager, VP, or person in authority makes a mistake and someone with lower rank notices it, it takes courage for him to tell us about it.

One of the key purposes of Kanban is the creation of value. In software development value means the creation of working, good quality code and is also part of Agile. Value implies customer satisfaction, and that is the purpose of our efforts.

Value is at the center of Lean and TPS, but frequently it is mentioned as the reverse side of the coin: eliminate waste or “Muda.” in Japanese Muda 無駄 represents anything that does not add value to your process or flow. By eliminating waste, we optimize the creation of value.

Communication and Collaboration

Communication, and collaboration are at the center of teamwork. One value does not work without the other, that is the reason we decided to group them together. To succeed we need to make ourselves heard (communicate) but also we need to be able to work with others to create value.

Without teamwork Kanban fails, and to be honest almost any business that does not communicate and collaborate properly will fail.

Holistic or Systemic Approach to Change

Deming’s System of Profound Knowledge and Goldratt’s Theory of Constraints reminds us that no single part of a system can ever bring overall improvement. We need to take a holistic view of the system and understand it. And the key part of the system is people, not just as resources, but also as full rounded individuals who make the system work.

Kanban agrees with this vision and aims to drive improvement where it counts. An understanding of the whole is fundamental to arrive at steady, successful change.

UPDATES:

A major update and follow-up to this article was the release of Open Kanban. Open Kanban is an Agile and Lean ultra light method to improve any area of your organization. Although it’s main focus is in IT and Software Development, Open Kanban can be used in any business or non-profit to achieve agility and continuous improvement. You can learn more here.

Open Kanban practices and values outlined above are just a proposal for a common Kanban core. Any organization or person can extend Open Kanban to fit their own reality and needs. When an organization, coach or individual extends Open Kanban they create a new implementation of Kanban, but a valid one, part of a stronger open ecosystem. The new implementations are Kanban Methods that share a common Open Kanban core. The diagram on the right explains this fully (click on it to zoom) given that Open Kanban is a brand new initiative no other methods are included inside of it yet, except Kanban Ace our own extension of Open Kanban that focuses on Software Development and IT.

We welcome your ideas and debate regarding this topic. Does Kanban need a new name? Do you think creating a stable Kanban core like Open Kanban is good for our ecosystem? Can you suggest suitable Open Source licenses to make the Intellectual Property the best to make this project a success? Would you like to make your Kanban method part of the Open Kanban initiative? Please comment here or in our forum.

Comments

I have an issue with definition number 3. Kanban was never a software development method, and anyone who calls it that is mistaken. I strongly disagree that most people in IT or Software Development consider Kanban to be a software development method. Sure many people say they use "Kanban" rather than "Scrum" in casual conversation, and often they are not aware that what they really mean is "we applied the Kanban evolutionary change method to our software development process, and now our software development process is more flow-based. Since there is no official product name for our flow-based development process we use the word Kanban because the Kanban evolutionary change method plays a large role in our management system and communicates what our management system looks like at a certain level".

I haven't read Scrumban for a while, but I don't think Corey uses the phrase to describe a software development method. The Kanban community has a clear understanding of what it means, it is simply the normal application of the normal Kanban evolutionary change method to a process based on Scrum.

Lean Startup talks about using Kanban, but here again surely they are talking about the evolutionary change method. How can they talk about using it as a software development method? There are no descriptions of Kanban that I am aware of that would enable anyone to even use it as a software development method.

I also don't think it is accurate to claim that the LKU is distancing themselves from Agile, Software Development and IT. They just recognize, and continually have to point out, that it isn't a software development method at all, and never has been. Of course it can be be applied to any software development method or process, and it is still ideal for the software development context, but it is in no way a software development method and never has been.

I always find it strange that people who use Kanban in the context of software development and IT, either as a project manager, QA lead, part of DevOps or an Agile or Lean consultant still deny that Kanban is and Agile and Lean method. You must deny that Kanban is Agile to call it a method that does not apply to software development, yet it does and I am sure you use it this way every day. Your whole argument reads contradictory.

The fact that LKU has distanced itself from IT and Software Development is not something anyone can deny. All the conferences for 2014 have been renamed Management Method contests, and the links I present are factual. I believe some this year have also been renamed already.

On Twitter you mentioned that the link I used to refer to the distancing of LKU and Software Development is not the best (the article from scrumcrazy) and I agree with you. I wished there was a better source to show quotes where David Anderson has distanced himself from IT and Software Development, I disagree with the opinions of that article I linked to, Kanban can indeed be an excellent method to guide any IT or software development team. In a conversation we had on this topic with David on KanbanDev he said and I quote that “Kanban isn’t an Agile method.” It was a heated debate, and I opted not to put the quote or link here. Do you think that would be better? It is hard to strike a balance between the truth, and respect. I respect the contributions David has given us all for Kanban.

Regarding Scrumban, re-read the book it is all about software development, and a very good Kanban book as well. I find it inspiring and part of the Kanban the Lean and Agile method.

Open Kanban hopes to be an alternative to LKU Kanban, I believe we can co-exist and learn from each other. A bigger Kanban ecosystem benefits everyone.

What makes a successful open source ecosystem is three things:
1. Content (IP) that people will find useful.
2. Clear, open, licensing of said IP for a wide range of audiences.
3. Well defined governance model for contributing to and maintaining said IP.

You need to have 2 and 3 defined before you can make a start on 1 otherwise you will run into issues with IP ownership and usage of said content.

The issue that I'm stalled on currently is that current Kanban IP ownership is very distributed and somewhat derivative. What is the equivalent in the management methods world of the clean-room engineering that enabled the Linux kernel to grow unencumbered by copyright concerns?

We as a community desperately need to address these concerns or we will see more and more incidents like the unpleasantness between John Seddon's groupies and Stephen Parry that we saw during LKNA this year.

Now regarding the copyright and licensing issues. I agree completely, the licensing should be some type of Creative Commons, or Open Source approved license. But because this the first essay on the subject, it does not have that Intellectual Property infrastructure in place yet.

However we do believe (we at AgileLion) firmly that the next step should be to establish a website presence for Open Kanban under an Open Source friendly license. The steps I can see in my mind are:

First step: Extract the core of the proposal for Open Kanban and host it in a repository, most likely GitHub. Accompany that with an Open Source license.

Afterwards invite a talented group of people to contribute to Open Kanban, like the founders or early contributors of an Open Source project.

Finally develop and extend Open Kanban to cover the core of Kanban fully.

Beyond Open Kanban, Agile Coaches, organizations, companies should be able to customize the method. We don't have to be prescriptive, just show the main way forward, like I said in the article the core of Open Kanban. One example is Kanban Ace, http://agilelion.com/why-learn-kanban-ace our Agile and Lean method, it would have an Open Kanban core, but on top of it, it's own advantages. It would still be a valid Open Kanban implementation.

If you have any ideas or would like to contribute in these efforts in the future, please let us know. We are now in the early phases of this initiative.

Joseph,
I am very interested in this initiative, I have 13 years experience in Lean Manufacturing/Lean development and am a little appalled at the thought that a group of folks blatantly took kanban --> Kanban and started licensing the training. Has anyone thought of sending money to the Ohno estate for stealing from the TPS and Lean thinking and alike?
Just a thought, but I have a passion for Lean/Agile and alike and would hope to provide some insights from lessons learned
Paul

Paul,
Thanks for the support and honest opinion. Indeed we will need people to build Open Kanban further in a way that all can access knowledge freely, can you please send us your email to contact you later?
Our contact page would be the best way:http://agilelion.com/contact
Or you can find me in Twitter http://www.twitter.com/josephhurtado and we can DM there.
Cheers,
Joseph Hurtado

Whilst I agree with the spirit of your initiative until you have addressed the issues of a clear and open contribution model and un-encumbered initial IP then I won't be able to contribute, sorry.

To restate my objections:
1. Need a clear governance model for contributions. Needs to be meritocratic, open to all and transparent. This is hard, boring work but possible - I have enough experience with open source projects to help you here.

2. Unencumbered IP. This is my main objection and it is hard - I don't think I can help you here. Especially if you decide to use the term "Open Kanban". How do you plan to license content that you did not create yourself (or is clearly derivative)? Without this in place then it will be impossible for other organisations to use this project.

Regarding a meritocratic system and open to all, that is what open source is all about. Once a proper license is set, contribution is welcome from all parties. We don't expect contributions until the license and IP issues are fully clear. I welcome your help, and anyone's help on how to do this best.

Ideas are not patentable, and the ideas about Kanban, Agile and Lean have decades. We are about ideas, not products or patents for Open Kanban. Creative Commons has had a lot of success on this, it is one of the licenses we are looking at.

Well, I agree with Kurt that "Kanban method" was never intentioned to be a software development method. But, as it already been discussed above, I don't want to comment further on it. What I could not understand is that Agile Lion is propagating "Kanban Ace" as can be seen on this site, and now the blog post starts talking about "Open Kanban" initiative. Why can't Kanban Ace be made "Open Kanban" or made a starting point for this initiative? Using different terms would cause more confusion rather than reducing it.

Open Kanban is an initiative to create a fully open source core for Kanban that is Agile and Lean. But on top of the core of Open Kanban, companies, Agile Consultants, and people would be able to extend and customize. This is precisely what happens in Linux, where the core is common to all, but some distributions focus on servers, or desktops, or mobile.

Kanban Ace is one layer on top of Open Kanban, one that should be among many more to come. Kanban Ace builds on top of Open Kanban other features that are very specific for software development and enterprise. Kanban Ace would be similar to Red Hat Linux, you get that distribution because you trust their team for their expertise and support.

Open Kanban remains open source and free for all. As I previously stated we are looking for the best open source license to make this happen.

I have long been a follower of Deming's ideas. I think the value of a management system approach is huge, but it is rare for organizations to transform their management system. Most often they just use a couple tools and concepts which help but provide nowhere near the results more systemic change can accomplish. The limited changes often result in system problems (in agile software development you often hear the use of these ideas running into difficulties interfacing with an unchanged larger management system).