If I were to give a definition of Kanban in one sentence, it would be: Kanban is a method for teams to visualise and enhance their existing daily process and enlarge their output by limiting the work in progress.
Okay, but what does that mean? How does it compare with Scrum? And why do I like it so much?
Kanban is Japanese for visual sign. Sometimes Kanban is translated as visualisation.
| An industrial engineer at Toyota, Taiichi Ohno, developed Kanban to improve manufacturing efficiency. |
Visualisation, JIT and flow
Visualisation is a big thing in Kanban. It provides transparency, recognition, guidelines for the team and is a reporting tool towards management.
The best example of visualisation is the Kanban board. The board visualises the steps in your work. Every lane is a step and it can contain two parts. The supply part and the doing part.
The first lane is the “To Do” area which contains items that are refined enough and are ready to be processed by the team. There is no excessive amount of work in this first lane, but just enough. This is called Just In Time (JIT). Using a high abstraction level, there is no need for putting too much detail on the board. If you need more detail, add bit by bit. An item moves from the left on the board through all steps and ends on the right side, which is the “Done” lane. The slowest step in the process defines the flow and the pace and only team members can pull the items on the board.
On the board you can only find steps in the process of your team. If succeeding steps are performed by the same person, its best to combine these steps and make them one.
By using a board you make a lot of things very visible. For example, bottlenecks; for when a team member has too many items waiting for his input. By making it visible, you have a chance to get rid of the bottlenecks and by doing this, you improve the overall process. And this is one of the reasons why I like Kanban. You visualize the hold-up! So, no gut feelings, politics, history facts or guesses about where something goes wrong.
The Kanban board is also a progress indicator. Stakeholders can take a quick glance on your team’s board and they have pretty good idea of the progress of a certain item.
Example of a Kanban board.
Please note: A Scrum board is in fact a Kanban board.
Limit
Next to the visualisation, limiting work is the other essential element in Kanban. In fact you’re limiting the chaos in your project or process.
In waterfall projects you can limit the chaos by using phases. In Scrum, time is the way to limit chaos and in Kanban there is WIP, work in progress.
By limiting your work in progress, you create focus on the most important items. And with this focus you’re able to deliver work more efficiently. You’re less distracted by the other items on your to-do list.
Limiting work can be done anywhere. In the different process steps, in refinements, etc.
By having not to many items in progress, you can easily pivot if priorities change.
A nice reference WIP is the number of team members plus 50%.
Event and Roles
In Kanban there is only one event. The stand-up.
And only one question needs to be asked and answered.
“Do I need help to perform my tasks of this day.”
This event is mandatory for every team member and is preferably performed in front of the Kanban board.
Kanban doesn’t restrict you for having more meetings. If there is a need for extra meetings, go ahead and set it up.
There aren’t new roles introduced. It only uses existing roles that are already embedded in your organisation.
Process
So, Kanban is about improving your process while you’re actually doing the daily work in that particular process. There are four simple elements in improving the process. First draw (1) out your process, by using a Kanban board. Second, do (2) your daily jobs in that process, notice (3) the issues and discuss it with the team, so you can improve (4) your process. If necessary, update your working process and start this cycle again.
In Kanban there is one person responsible for maintaining the Kanban process, but this role can be rotated. This person is part of your existing team. Unlike Scrum, Kanban has no specific name for this role.
Define Done
To guarantee quality it’s important to define done.
In Kanban there is the Definition of Done. The team is responsible for creating this DoD and by having this agreement visually present, you can remind each other of these rules. Most of the teams put the DoD next to their Kanban board.
Scrum and Kanban
Differences
Scrum and Kanban are both frameworks used by teams in various settings.
There are similarities, like self-organising teams, definition of done and work in progress, but there also a few differences.
In the next table I’ve put down the most important differences.
| Kanban | Scrum |
|---|---|
| Applicable for daily processes and projects | Applicable for projects |
| One event | Multiple event |
| No scaling capabilities | Scalable |
| Timeboxed iterations optional | Timeboxed iterations |
| Commitment optional | Team commitment to amount of work |
| No prescribed roles | Prescribed roles |
| Prioritisation by team | Prioritisation by Product Owner |
| No PBI size prescribed | PBI small enough to complete in one iteration |
| Kanban board is persistent | Scrum board is reset every sprint |
Combination
In the past I worked with teams that experimented with a combination of Kanban and Scrum. We called it Scrumban. In my post about Constant Pace I explained how we did this.
We aimed for a sustainable pace that we could maintain indefinitely and tried to avoid rushing or relaxing at the end of the sprint. By combining Kanban and Scrum we created a great modus operandi in which everybody (business, development team and me as PO) could benefit from simple things like small stories, no (old fashioned) estimates, short planning sessions and heaps of little refinements. We experimented with teams that were junior and with more mature teams. And we concluded that the combination of Scrum and Kanban works best for mature teams.
Conclusion
I like Kanban because it’s a visualisation method which gives you the opportunities to spot bottlenecks and progress. With WIP you can tweak your process and aim for the best output possible. Kanban can be used for your already existing process or for entire new ones. There are no extra roles defined, so the adoption can be done rather quickly, by not having to train or hire new people. It can be combined with Scrum or other frameworks, but only with mature teams.
