Getting Started With Kanban

Kanban arose as a scheduling system for lean manufacturing, originating from the Toyota Production System (TPS) and soon was incorporated into Software Industry. Kanban helps to make the problem areas in the process visible. And finding a solution is easier than finding the actual problem.

This article is a quick overview of how Kanban can actually make problems visible, and how it can drive the team to improve the process.

It is easy to start with Kanban right away. Kanban does not need any ceremonies or roles to be decided. No matter what processes are currently used, as long as a board that displays the current status exists, Kanban can be incorporated. Even if there is no board present, then it is a good time to have one.

Create/update the board to reflect the current process of the team, from ideation to production.

The initial board might look something like this. But this does not reflect the exact process. Consider the following points

1. Are all the items that the team is working on are present on the board, from bugs to maintenance task?
2. The value of the ticket is only achieved when it is in production. So let the board reflect the process until production.
3. Not everything present in Dev and Testing Column is being worked on. Some tickets are moved from previous columns because they were completed. Add buffers or queues to represent that.
4. A ticket itself can be of different types. A new feature, bug, maintenance etc. Assign a colour for each type.
5. Add details on the tickets like the description, tracking ids, deadlines, blockers (represented by a small red sticker on top), progress indicators (indicated by a dot).

So basically add everything that could give a visual status of the current work.

The board captures the current status of the team and already shows the underlying problems like a high number of tickets in the Waiting for Ops and Ready for QA column. A bug ticket (represented by red) is in In Dev column for a long time (dots represents days). A blocker ticket (represented by a small red ticket on the yellow one) in the Testing column lying for a long time (represented by dots).

Right now the team can still continue to work on other tickets rather than fixing the existing ones. Developers will keep pushing their work into the Ready for QA column and pick a new one, ignoring the pile of tickets in the Ready for QA column and the bug ticket lying in In Dev column for a long time. Testers will keep switching to other tickets ignoring the blockers. Even if the problems are identified, something still needs to be done so that the team follows the “Stop starting, start finishing” principle. The team needs to take ownership of the ticket from start to end. What teams fail to understand is that their responsibility is not limited to pushing the ticket in the next column. Their responsibility is to push the ticket into production, together.

And that is where we can bring in WIP limits into the picture. WIP limit is basically a number of tickets that can exist in a column at a given point in time.

There are various approaches to calculate the WIP limit. The simplest one could be to multiply the number of team members by 1.5, and that can be the WIP limit. The team is free to have different WIP limit for different columns. Not all columns need a WIP limit. Do not be strict about the WIP limit, it is a trigger for discussion. The most important factor is to have a WIP limit low enough so that team can reach it. Only then, the team will become one and start focussing on solving the problems.

A high WIP limit can leave the work idle. A Low WIP limit can leave people idle. But dealing with idle people is easy, as they can collaborate with other team members and get the work done faster.

The board above has a WIP limit set for a few columns. No WIP limit is set for Waiting for Ops, and that is because for this particular team the Ops is outsourced to another team or organization. This does not really put the development team in control of that column. But this also exposes the consequences of not having a cross-functional team.

In the example above, the developer cannot push the ticket to the Ready for QA column as it will break the WIP limit. Increasing the WIP is definitely not the solution. So either Developer can work to help the QA to resolve the issue, or work on some improvement task, or help the team in analyzing the tickets. All this enforce the team to help each other and completing the current work rather than starting a new one.

Both Developer and Tester also have to resolve the bug and blocker respectively to avoid hitting the WIP limit often. Even if they avoid doing that for some reason, the delay will be visible due to dots. So by making the process highly visual, it is also made transparent.

Whenever a bug or a blocker occurs, consider having a quick retrospective with the team. As important it is to fix the current bug or blocker, equally important is to avoid a similar bug or blocker again.

There is a lot more to Kanban. But I deliberately wanted to keep the blog short, so that people can quickly get an idea about what and how exactly can Kanban help the teams, no matter what process is currently being used.

I will write the next blog to help identify the waste in the current process using TIMWOODS.