The Kanban Boardoriginally written by David Joyce
Our summary and key takeaways
When looking at Kanban in management terms, this is an ongoing exercise in matching supply with demand, aimed at delivering the right number of items at just the right time. According to David Anderson, Kanban board serves the purpose of a visual control. The actual signals that we read from this board are differences between the set WIP limit and the number of cards in a given process stage.
Setting up a Kanban board
Kanban is meant to visualize the sequential process stages. As a task leaves one stage column, it is placed at the bottom of the next one. Pulling always happens from the top of the column, and in this way the progressive order of task completion is kept. The one thing that proves the difference between a Kanban board and any other task board are the limits, applying of which Kanban demands.
There are two kinds of limits happening in Kanban. One are the work in progress limits, defining how many tasks can be worked on at any given time. They aim at eliminating multi-tasking and increasing throughput. The other limit is on the total number of tasks that can be placed in a particular column. This puts a stop to any premature work, therefore enabling the “just-in-time” delivery. The number of tasks that should be kept in each column should match the team's size and capacity – large enough to keep them busy, but not as big as allowing prioritization, meaning that some tasks will not be worked on for a long time.
Thanks to this approach, the overall process is easily read by all team members, the bottlenecks are apparent and any issues with the teamwork or tasks can be identified and solved much quicker. An additional help to making the visualization really work is color coding the different types of cards, which makes it easy to realize whether a problem occurs with a new feature development, a bug fix, documentation preparing or any other type of work.
Kanban fast lane?
The idea of just in time delivery and value pulling don't really facilitate a speedy lane as such. However, many teams had made a compromise to keep an “urgent” lane open – but for one task at a time only. Therefore, when a team member becomes available, instead of pulling from the backlog, he takes the urgent task on and then goes back to pulling from the regular backlog. This approach will work for as long as the Urgent lane is limited to one task only. Once it becomes full of tasks, there is no longer any point in keeping the backlog open.
The workflow gets improved on very quickly with Kanban. The best part is that it shall carry on improving with each and every retrospective – once you identify what could have been done better, simply decide on a change and implement it in the next session.