Kanban Evolution
originally written by Karen GreavesOur summary and key takeaways
This article presents Karen Greaves' thoughts on Kanban, the process of Kanban implementation and its evolution. Her impressions and advice have been influenced by a David Anderson's Kanban workshop, that she attended.
Scrum and Kanban
She begins with clearing up the main differences between Scrum and Kanban. The most poignant one is the fact, that Kanban is not based in iterations, like Scrum, therefore it doesn't demand quite so much effort and current process alteration to implement. The crucial difference however lies in applying work in progress limits, as a main characteristic of Kanban.
The basic Kanban rules
Kanban method rests on a couple of rules. The vital two are: visualization of the process and limiting the WIP. The visualization of the process can be done in two ways: by arranging tasks in columns of the Kanban board or by utilizing the visual aid of the analytical charts, like Cumulative Flow, which will provide a state of the process in just one glance.
WIP limits
Putting a WIP limit on your columns means great productivity boost, as your team will no longer need to multi-task. Setting a limit to how much tasks each team member can perform in one time can seem a danger, as the progress of tasks from one employee to another may mean that sometimes some people can be left task-less. Although this initial impression, in fact studies have shown that limiting WIP mainly increases Cycle Time and cut waste, rather than produce waste as some might imagine without trying it first.
Transparent policies
A fantastic Kanban feature is the ability to make company policies transparent. It's doable to set a WIP limit, prepare the process workflow and let all team members see it. By doing this you're ensuring a perfect opportunity to work on improving the overall process, rather than trying to fix one employee's approach or idleness. In other words: with an explicit policy you don't have to chase individual's work, you're managing the complete flow.
Throughput vs demand
Another great benefit of Kanban is the visibility of your process throughput. By simple analysis you can grasp just how much your team is capable of doing in a given time. The obvious conclusion of that should be: now you know how much precisely will it make sense to demand from them. And by knowing your team's capacity it should be easy to realize, that you can now let go of those tasks, that are not top priority, as they will most likely never make it onto the "working" column. Another opportunity to save time and effort then.
No bottlenecks
With Kanban it is easy to manage and avoid bottlenecks. Once you realize that a queue of tasks in a certain column begins to grow, you know it's happening. Also, by looking at the CFD, when you spot a sharp rise, a step up of the bands - this means that somewhere along the line work is piling up and isn't flowing through the process. What to do with it then? Of course, place a critical limit in the column just before the bottleneck. Even if things will pile up a little bit before the problematic area, the priority work will be more visible. Another logical solution is rising the capacity for this work. Put more people on the tasks in the bottleneck. Another idea is re-thinking the necessity of some of the queued-up tasks.
Urgent task processing
As opposed to doing Scrum, in which a sudden demand for performing an urgent task can destroy the whole Sprint, in Kanban the urgent item can be simply queued in the system and await an opening within the same, healthy WIP limit. All you need to do is make sure that this special, "urgent" task gets classed differently, to underline it's importance and to ensure that the next available person pulls this task instead of a regularly classed one.
Multi-purpose workflows
With Kanban there is the option to allow different lines of process to go on simultaneously. You can now have a swimlane for new release work and one for previous release support and operate on both together with one WIP limit. If you create a policy that 25% of work is support and 75% is development, and have a 4 task WIP limit, you just simply make sure to always have 3 dev. tasks in and 1 support task. It's best and most efficient to visualize the difference with different colored Kanban cards.
With much more info available on how to do Kanban best, starting with these basic rules will allow you to get a taste of evolving your own Kanban process.