The simplicity of the Kanban approach allows also very simple ways to identify if the team Kanban process is working all right or if there would be something to develop. At the end of this post you will find four questions that reveal if your Kanban practices would need further improvements.

When talking about Kanban, one should have in mind the origins and the evolution of the method. 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 limiting simultaneous work and pulling work from previous process step when needed. 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:

1. Visualize workflow
2. Limit work in progress
3. Measure the flow of work

Very often, only the first of these is realized in teams that claim to utilize 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 overcrowded wall, overworked team, unnecessary task switching, and less actual teamwork and helping of others. When used in this manner, 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 that process step can effectively contain at any given time. The use of WIP limits requires discipline – there cannot be any breaking of the WIP rule. The rules itself should be strictly defined to allow only so many work items for any process step 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 is able to start to optimize the process and increase performance. However, for best results, the third principle must also be introduced.

Measuring the process flow is the final ingredient in a successful Kanban. In the roots of Kanban, in manufacturing, measuring the manufacturing process output flow is essential and finely ingrained in the factory ethos. In manufacturing, focus is often given to making process steps as short and same length as possible, in addition to removing all possible variation to make the process as effective as possible. In software R&D and service development, these targets do not make as much sense. Prior estimation of the final time and effort of work items is less accurate, and this leads to considerable variance in the time that a work item spends “under work” in the team process. This said, the team 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 the team performance, and can be also used for estimating release schedules.

As important as the above issues are, even more important for effective and improving team using Kanban is use of strict rules in the work item handover from one process step to the next. Also, the team will not improve if it does not implement practices and motivation for continuous improvement and experimentation. Much of the same practices that are used in Scrum (like Definition of Done) are also needed in Kanban. Everyone in the team must share the same view what should be ready when the work item is moved to the next process step in the Kanban board. Another Scrum ceremony that must not be forgotten (but so often is) in Kanban is Retrospectives. Without a regular retrospective – improvement meeting looking back at what worked well and what requires improvement – team is doomed to repeat ineffective practices and not able to repeat any accidental successes. Teams should also experiment with process changes and WIP limit adjustments to see what results in best flow of outputs.

Danger when using Kanban is that the team stops working as a team, and starts to work in “silos”. If the team is not doing work item handovers effectively, information is lost in all handovers. Also, if a team is not willing to jump to a different process step to help when assistance would be needed, this is a signal of excessive “silo” situation. To avoid this, teams must focus on the handovers and strictly follow WIP limits and jump to assist any work item that is stuck, even if the item is stuck in a process step that is not in one’s comfort zone. The whole team must be forced to assist when the process becomes stuck.

A common misuse of Kanban is the developer-to-tester process handover. If this handover is not done effectively, testers are left with a change or new functionality to test, with little insight where to start, and with possibly a buggy implementation on their laps, while developers start to work on something new. In worst case, this can lead to huge pile of tasks in “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 high stress work environment and an overwhelming lack of motivation in the team. Such situation can be easily avoided with strict enforcement of WIP limits and with the team members helping each other

When one wants to evaluate how well the team Kanban is working, the following questions can be asked. If any answer is “No”, this reveals that there is some improvement potential.

• 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 last 3 months?
• Is the sum of all WIP limits less or equal to the team size?

Any answer of “No” means that the team should have a discussion on improving it’s 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 anyway valuable.

Kanban can be a very useful tool for optimizing team performance, output flow and quality. However, just the use of a Kanban board is not enough – Kanban requires also discipline and understanding 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 in improving the team process. In this way, the team can achieve the full benefits of Kanban.