Kanban, Flow and Cadence

This is Karl Scotland's take on Kanban, written at the beginning of the great Kanban for software development adaptation wave. It encompasses the general idea of Kanban, the concept of Flow and explains how to understand Cadence in Kanban systems.

Kanban

In his article, Karl refers to Kanban as a means of controlling the workflow. Originally introduced for controlling the stock in automobile production industry (Toyota), it has been designed to allow for a just-in-time production in an automated way, but not void of the all important human touch.

What does this imply? At first glance, Kanban for software development looks just like a typical Agile workload board. The process is divided into stages, and tasks are transferred from one to another as the process goes on. As the tasks are moved, they are placed at the bottom of a stage column, and are meant to be pulled from the top. This way the order of things is kept with respect of the healthy FIFO rule.

Now the difference that Kanban brought is the application of limits as to how many tasks can be pulled into a buffer (waiting) column and limits of the number of tasks that can be progressed at one time.

The idea behind limiting the number of queued-up tasks in waiting stages is to minimize waste caused by premature work (wrong prioritization) and avoid long wait times before a task is processed.

As for the Work In Progress limits, the goal here is to stop unproductive multi-tasking, improve throughput and make the teamwork easier, better and more satisfying. Doing a couple of things at a time is wasteful for two reasons mainly: the sole need to switch between tasks takes time and effort (both wasted, as they don't produce anything), and juggling jobs brings the result about less fast than performing one job after another.

The process throughput benefits from Kanban, as the less tasks is being initiated, the greater should be the speed of their completion. Karl provides the most visual metaphor for throughput in Kanban: the famous traffic jam, in which the more vehicles enter the highway, the slower they move.

The teamwork and overall team spirit gets enhanced by Kanban by the simple mean of having less tasks to spread around and focus on, henceforth being able to see the larger goal, that the team is working towards.

As to the obvious question of "what is the appropriate wip limit" - there are two ways to go about it: either begin small (1 or 2) and increase if necessary, or start with a limit as large as half of your team size, and trim down whenever you see the possibility to.

Flow

By "flow", Karl understands the way in which the tasks provide the best result for the company. There is a mention of the idea of a "one piece flow", which basically means cutting down the size of a work item to a minimum and concentrating on creating "Minimal Marketable Features" (fully operational items, that meet customer's requirements but don't exceed them).

By following this rule you're ensuring a progressive delivery, saving time and work on not necessary features, therefore minimizing the costs. A very good measure of waste-proofing your current workload is making sure that it follows the INVEST guide (independent, negotiable, estimable, small, testable), or checking whether the result would be a good subject of a blog post.

Of course, there will be instances, where the MMF happens to be larger than a typical workload, and this can be worked with via Kanban too. You simply have to treat each Kanban user story (one full set of Kanban cards) as part of completing the MMF. Karl mentions a technique that can come in handy in such cases - User Story mapping (by Jeff Patton). It's also a useful recommendation - if a Kanban board is a step along the way of completing a MMF - to have a board for the full MMF, which will be branching out into smaller Kanbans for each User Story.

Cadence

This is a term here used to describe a path to gain reliability with regards to commitment while applying a Kanban system. Since Kanban doesn't demand a time-boxed deadline, it may seem difficult to establish any form of estimation when items will be completed. But really, it's quite simple. By measuring the system throughput as a relation between Work In Progress and the Lead Time, you can learn to rely on its value, provided that the team's capacity stays the same. This is best visualized on a Kanban' classic - Cumulative Flow Diagram.

There is also a distinction between measuring the cadence for different periods of time - you'd look at quarterly goals when wanting to see the long term performance possibilities, or you'd take just a daily stand-up to track the team's progress of just one day.

A Sum-up

Karl presents three key values for Kanban, Flow and Cadence:

• Applying Kanban allows to get rid of estimates, time-framed iterations and a product backlog
• Flow describes the effectiveness of the delivery by way of optimizing the User Stories and MMFs together
• Cadence allows to measure performance, rather than estimate it.

Read our article on the Kanban flow »