Kanban is a Lean signaling approach designed to support Just-in-time (JIT) production. It was conceived for the shop floor as a pull signal to replenish depleted inventory.  A classic Kanban signal would be a plastic card attached to a skid of materials used by an assembly station.  When the materials are depleted below a set threshold the signal card is sent to the source of the materials to trigger production of another skid.  The signaling approach synchronizes upstream production with downstream consumption.

Recently Kanban has been a growing trend in the software industry. But, like any story that gets retold around a campfire, the story changes with each telling, and in that manner I think Kanban morphed as it moved from shop floor to design studio to software house.

Software developers tend to view Kanban as supporting a Value-Flow-Pull environment with the following properties:

·         No iterations

·         No time boxes

·         No estimation or planning

·         No burn-down

·         Encourages division of labor

As David Anderson points out, this irritates the Agile Software community because each property violates pillars of the Agile faith.  Agile evangelists don’t really know what to think of Kanbaners. On the one hand they love anything new and exotic sounding, but on the other hand…what do you mean no iterations?

I doubt someone familiar with Kanban on a shop floor would recognize its form used for software development.  Most software Kanbaners write task or feature descriptions on signal cards. The Kanban cards get stuck on walls, not on skids. They tend to be arranged in vertical swimlanes and people move the cards from one lane to the next as production progresses. Two things are important to note: first, most software Kanbaners flow the cards in the direction of the value stream; second, the swimlanes are production phases not divisions of labor.

What software developers have managed to do is use the name “Kanban” to describe what amounts to a card-based work item tracking method.  That’s not what real Kanban is all about…real Kanban is supposed to be about using signals to trigger just-in-time (JIT) production between non-co-located divisions of labor.

I’m not saying all software Kanbaners screw this up…but many do.

A true Kanban signal needs to flow opposite the value stream.  Rather than starting at step-A and progressing to step-B, the signals should start their journey at step-B when inventory is depleted and be sent upstream to step-A to trigger additional production.

The proper application of Kanban is to signal between divisions of labor. Therefore, on a software project one would use it to signal between a database group, a programming group, a user experience group, analyst team, marketing team, and etc.  To the extent that adevelopment value stream depends on a division of labor, productivity and flow efficiency can be enhanced by using Kanban.

Moreover, you don’t need PostIts, wallboards, or swimlanes for Kanban. Kanban is a “signal”.  It could be an email, an Outlook task request, or any of a million simple things.  I’ve never understood the software industry’s fascination with wallboards.

Agile teams with little or no division of labor (just like good little Agilests ought to be) are trying desperately to use Kanban because it’s cool. Since these teams have no real use for the signaling aspects of Kanban they use Kanban cards to document their work items, tasks, and stories.  Kanban becomes a kind of wallboard todo list. This gives them a distorted view of what it means to have no iterations, no time boxes, no estimation, and whatever else.

That’s not Kanban… I don’t know what exactly to call it.