As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as an alternative to Scrum. There is a lot of confusion about this simple yet effective tool, so this article will clear up these misconceptions and provide a quick crash course into the essentials of Kanban.
Where did Kanban come from?
Kanban originated in Japan in the 1940s. People from the Toyota car manufacturer noticed that supermarkets used a simple but effective system based around small physical cards to indicate when something was out of supply or needed to be ordered. They applied this system in their own manufacturing process to help visualise work and control flow.
Kanban became a part of Lean Thinking and the Toyota Production System. It was later popularised amongst software developers in 2010 by David Anderson with his book “Kanban: successful evolutionary change for your business”.
What really is Kanban?
Kanban is a simple but powerful system for visualising and managing work. It is not just related to software development, in fact, it is not specifically related to development of any kind. It can be used in a restaurant, a supermarket or a car factory. It has four principles and five practices.
As opposed to Scrum, which involves revolutionary change, Kanban is about evolutionary change, starting from right where you are now (in fact, that is one of the fundamental principles: start off by changing nothing whatsoever! You won’t find any organisation on earth that will resist that change). It is fundamentally about visualising work and then finding ways to improve the flow of work through a system.
The Four Principles of Kanban
This section will discuss the four fundamental principles behind Kanban. They are all essential to understanding and implementing the practices. Fortunately, they are simple and can fit into any organisation or system.
Start with what you do now
As mentioned, Kanban is a method for gradually improving an existing workflow or system. So you start with whatever you are doing now - whether simple or complex, big or small. You can use Kanban alongside or on top of any existing framework or system you are using - Scrum, Waterfall (yes Waterfall!), or anything, really. Many people believe they have to choose between Scrum or Kanban - untrue! You can use them together.
Agree to pursue incremental, evolutionary change
As opposed to systems like Scrum or Extreme Programming, that start out by fundamentally changing the structure and behaviour of organisations, Kanban is about evolutionary change, one small increment at a time. This can make it well-suited to cumbersome organisations that resist large risky changes.
Respect the current roles, responsibilities, and titles
Kanban doesn’t start off by renaming people or inventing strange new roles. Everyone gets to keep not only their job but their job title too. This further helps resistance to change.
Encourage acts of leadership at all levels
This is a subtle but very important principle. Improvement is the responsibility of everyone in the organisation, from the CEO down to the receptionist. You might get to keep your current job title and responsibilities, but you also now have an additional responsibility: leadership, which is really about empowerment and improvement.
The Five Practices of Kanban
Unlike Agile, which only has values and principles, Kanban has actual practices that you can employ, starting from day one.
Visualise the workflow
This is the most important step in all of Kanban, and is at the core of the whole system: visualising work. This was trivially easy to do in Toyota car manufacturing plants: the work was cars lying around in various states of semi-construction. For knowledge work like software development, marketing or design, it is much harder to visualise. This can let work accumulate and create huge blockages without anyone being aware.
So visualise the work! This will make it easy to see where work is piling up and where problems and bottlenecks are. The best way to do this is on a physical board, using tokens such as index cards or post-it notes. Putting the work in an electronic tool might seem convenient but when the computer is switched off or minimised, the visualisation of the work is gone. The bigger and more physical, the better! You want to aim for information radiators (that push information out to the organisation) rather than information refrigerators (that preserve information away from people’s eyes).
The most common way to visualise the work is with a Kanban board that has vertical swimlanes to represent states of work. You can then place cards on the board to represent the actual work item. Here is an example of the simplest of Kanban boards, with lanes for To Do, Doing and Done:
Here is another example of a board, this time with some extra lanes, numbers that indicate Work in Progress Limits, and cards marked as being Blocked.
Limiting WIP (WIP stands for Work In Progress) is another key practice of Kanban. People often think that we want to maximise work in progress - that means everybody is busy and lots is getting done, right? Well, if you have lots of WIP, then everyone will probably be very busy, but that isn’t really valuable. We want work in a Done state, not in a “Doing” state. And the best way to ensure that is to actually REDUCE the amount of Work in Progress!
It might sound counterintuitive, but it is true. Lots of WIP means lots of handoffs, queues, bottlenecks and task-switching. This all means not much getting actually Done. Minimising WIP means you can maximise flow, which maximises the amount of work Done. And that’s the true goal.
Kanban focuses on reducing WIP in order to maximise flow. If you want lots of work to get to Done but don’t want lots of work in a Doing state, you have to reduce the amount of time it takes for work to go from Doing to Done. This is called Cycle Time. Kanban practitioners have many tools they can use to improve flow and reduce cycle time, and these will often become clear after you have visualised the work. They include eliminating approvals and handoffs, swarming on complex slow tasks, identifying bottlenecks, putting WIP limits on Kanban lanes, reducing wait time between tasks, and reducing queues.
Make Process Policies Explicit
As you implement new rules and policies to improve flow, ensure you make these explicit. If you have a Definition of Done, get people to agree to it and publish it. If you change the rules about approving a document, make sure this is understood and explicitly described. Improvements will fall away and get misused if they are not clearly articulated and understood.
Improve Collaboratively, Evolve Experimentally
Improving is a collaborative team effort, not something randomly forced on people by some arbitrary management edict. It should be implemented by teams in an iterative experimental effort. Teams need to feel they are in an environment where experimentation is encouraged and it is “safe to fail”, or nobody will try making genuine changes.
I hope you have enjoyed this crash course in Kanban - many people are using this system to great effect. If you want to know more, I would recommend the books Kanban by David Anderson, or Kanban in Action by Joakim Sunden and Marcus Hammarberg.