Kanban is a very popular way to control and manage a team’s work. But it is often misused. Read on and start doing it right.
For some teams, Kanban is just a whole lot of tickets or post-it notes on the team room wall. Other teams view Kanban as a process tool that allows for continuous improvement and increased effectiveness. When used correctly, Kanban can be a very effective tool for improving your team’s performance.
Since Kanban is so simple, there are easy ways to see if your Kanban process works well or if you need to develop it further.
At the end of this post, you will find four questions that reveal if your Kanban practices would need further improvements.
Kanban in short
To be successful at it, it is useful to know where Kanban comes from and how it has evolved.
The roots of Kanban are in manufacturing, but lately, it has become increasingly popular in many R&D and service development organizations.
The basic principles of Kanban are to:
- limit simultaneous work
- pull work from the previous process step when there is room for new work
These two principles mean that new work is started only after previous work has been finished.
Kanban contains three main rules, all of which are essential for optimal performance:
- Visualize the workflow
- Limit work in progress
- Measure the flow of work
Visualization is not enough
Often, only the first of these - the visualization part - is realized in teams that claim to use Kanban principles. Issues and tickets are posted to the team wall, but no effective control is used to limit the number of them. This can easily lead to:
- an overcrowded wall
- an overworked team
- unnecessary task switching
- less actual teamwork and helping of others
When used this way, the Kanban board itself does visualize work and increases understanding of work in progress. But that is about all that is achieved. There is also a risk of hiding process problems, bottlenecks, and a faulty belief that the team is working to its best potential.
Kanban starts to show its true value when the Work-In-Progress (WIP) limit is taken into active use.
With WIP limits, the team can start to optimize the process and achieve results faster. WIP limits basically mean that each process step is analyzed and the team decides what is the maximum number of work items that process step can effectively contain at any given time.
You need discipline to use WIP limits. You need a strictly defined rule - and nobody should break it.
Allow only so many work items for any process step, so that in no situation, the people are doing two or more things at the same time. This allows people to focus fully on any one work item. Task switching waste is minimized, and if there are any problems, other team members are called in to assist.
With WIP limits in use, the team takes huge strides towards a working Kanban, and can start to optimize the process and increase performance. However, for the best results, the third principle must also be introduced.
Always measure the flow of work
Measuring the process flow is the final ingredient in successful Kanban. In manufacturing - where Kanban has its roots - measuring the process output flow is essential and is finely ingrained in the factory ethos.
In manufacturing, you aim to:
- make process steps as short as possible
- make the steps similar in length.
- remove all possible variations
This makes the process as effective as possible. But in software and service development, these targets do not make as much sense. It is harder to accurately estimate how much time and effort is needed for each work item.
This lack of estimation accuracy leads to considerable variance in the time that a work item spends “under work” in the team process. This said, you can still measure velocity, averaging it over a time period (a week or a month) and then following the rolling average over many time periods. This measurement will reveal any trends in team performance, and can also be used for estimating release schedules.
Be firm in your handovers
As important as the above issues are, to master and improve your Kanban it is even more important to use strict rules in the work item when you hand it over from one process step to the next.
Also, the team will not improve if it does not implement practices and strive for continuous improvement and experimentation. Many of the same practices that are used in Scrum (such as Definition of Done) are also needed in Kanban. Everyone in the team must be clear about what should be ready when the work item is moved to the next process step in the Kanban board.
Don’t forget your retrospectives
The retrospective is an important Scrum ceremony in Kanban, but sadly it is often forgotten.
It is an improvement meeting looking back at what worked well and what requires improvement. You really need to have it regularly. If you don’t,the team is doomed to repeat ineffective practices and will not be able to repeat any accidental successes. Teams should also experiment with process changes and WIP limit adjustments to see what works for you.
“Those that fail to learn from history are doomed to repeat it.” Winston Churchill
Be aware of silos
There is a danger when using Kanban, that the team stops working as a team, and starts to work in “silos”. For example, each time a work item is handed over, information is lost if the handover isn’t done effectively.
There is also a clear warning sign to look out for. If a team is not willing to jump to a different process step to assist when needed, you have an silo situation. To avoid this, your team must focus on the handovers and strictly follow WIP limits. The team members should be ready to jump in and assist on any work item that is stuck, even in a process step that is not in their comfort zone. The whole team must be forced to assist when the process becomes stuck.
An example: handing over from developer to tester
A common misuse of Kanban is the developer-to-tester process handover. If not done effectively, testers are left with a change or new functionality to test, with little insight on where to start. They will possibly have a buggy implementation on their laps, while developers start to work on something new.
Worst case scenario: you will have a huge pile of tasks in the “waiting for testing” state, while developers keep generating new changes for the overworked and suffocating testing team, building an ever-growing testing debt.
Such situations usually result in schedule delays, cost overruns, huge amounts of bugs, regression, low quality and a high stress work environment, and an overwhelming lack of motivation in the team. You can easily avoid that situation with strict WIP limits and with the team members helping each other.
Ask yourselves these questions to find out how YOUR Kanban is doing
When you want to evaluate how well the team Kanban is working, just ask yourselves the following questions. If any answer is “No”, you have potential to improve.
- Is the Kanban board visible to all team members and also to team stakeholders? Is the board always up to date?
- Does every process step on the Kanban board have a WIP limit that is strictly followed?
- Have the WIP limits changed in the last 3 months?
- Is the sum of all WIP limits less or equal to the team size?
Any “No” answer means the team should have a discussion on improving its use of Kanban. Not all teams are able to ever answer “yes” to all of the questions, but the continuous improvement of work practices is always valuable.
Kanban can be a very useful tool for optimizing team performance, output flow and quality. But simply using a Kanban board is not enough. You also need discipline, and you need to understand the importance of optimizing the flow of work items through the process. Correct and effective use of Kanban is not difficult, but it does require understanding the essential principles and a continuous focus on improving the team process.
That is how you get the full benefits of Kanban.
Published: March 11, 2022