Networked Kanban

I am wondering if maybe some people should try and replace their regular Kanban board with a networked Kanban variant.

I love the principles behind Kanban. I really do! Despite the occasional clash with the Great Leader. But I have been unsuccessful trying to apply a Kanban board to the work I’m doing with my team members. I simply cannot seem to fit the tool to the way we do our jobs…

1. The phases in our work are not sequential, and thus we cannot easily map our work onto a value stream. Our work is a value network.
2. The work items are not coherent. They split and merge and multiply in many ways before value is delivered to very different stakeholders.
3. We cannot swarm around a board because our work is not collocated. It seems we need partial visualization of work in different locations.

Regular Kanban

Of course, I’m quite sure the Kanban experts can come up with modifications and extensions to customize the Kanban tool to the way we do our work. But I feel it’s like turning a bicycle into a shopping cart by adding extra wheels and a big basket. I seems more effective to me simply to find an actual shopping cart. In other words, I want a tool with native support for non-linear flow, transformative work, and dispersed teams.

And thus I was glad that Alan Shalloway organized a “birds of a feather” discussion at LESS2011 to talk about non-linear forms of Kanban. The issues he described are very similar to the issues I have encountered myself. Most knowledge work is complex, not linear. Transformative, not repetitive. And distributed, not centralized. I’m looking for Kanban implementations that really address these issues.

Networked Kanban

I have already started experimenting with what we might call Networked Kanban. It differs from regular Kanban implementations in the following ways:

1. There is a collection of small Kanban models, most of them with just three columns (waiting, in progress, done). I might even suggest that we introduce a MIP (model-in-practice) limit, which says that each Kanban model is not allowed to be bigger than a few columns.
2. The Kanban models each have their own entry and exit criteria which determine how work moves from one model to another. An item finished on one model can trigger multiple new items on other models, and vice versa. An item can also ping-pong back and forth between two models, until the state of the work item allows it to move elsewhere.
3. Different models can be implemented and visualized in different ways. Some will be physical, some will be electronic. Tools I already use, such as Remember The Milk, GMail, and EverNote, and artifacts I already work with, such as invoices, evaluation forms, and the queue of magazines on my desk, can all represent small local Kanban implementations.
4. Different team members can flock around different models. Some are just meant to be used by me personally, while others are meant to be used by the whole team.

The main difference with my suggestions and how I see other people implementing Kanban is that I prefer to scale out and not scale up. I think we should evolve many small context-specific models, instead of having one Kanban model that tries to do everything in one place. I prefer a network of 10 simple models with 3 columns instead of one complicated model with 30 columns and nifty expandable swimlanes on supersized whiteboards.

Note: As Alan Shalloway pointed out, the idea of multiple Kanban boards is not new. What could be new is going as deep as possible with the networked version of Kanban, by tearing apart the big boards, leaving only “atomic” Kanban boards in a network of implementations.

The focus of continuous improvement should then move from improving flow on one board to improving flow through the whole network, in a nonlinear, transformative and distributed way. A network of models might make it easier for (some) teams to understand the complex nature of their work.

As a complexity thinker, this would make me very happy!

Another note: It is important to point out that the goal of models is to help us make sense of the world. I am not trying to make my Kanban implementation complex, which is both impossible and undesirable. I am trying to evolve it to an implementation where it actually helps me understand the real work, instead of oversimplifying and linearizing it in such a way that it doesn’t make sense to me anymore.

But right now, these are just ideas that require rigorous experimentation. And I would love to hear what Alan Shalloway and the other Kanban experts think of it…

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)