Agile Zone is brought to you in partnership with:

Jurgen Appelo calls himself a creative networker. But sometimes he's a writer, speaker, trainer, entrepreneur, illustrator, manager, blogger, reader, dreamer, leader, freethinker, or… Dutch guy. Since 2008 Jurgen writes a popular blog at www.noop.nl, covering the creative economy, agile management, and personal development. He is the author of the book Management 3.0, which describes the role of the manager in agile organizations. And he wrote the little book How to Change the World, which describes a supermodel for change management. Jurgen is CEO of the business network Happy Melly, and co-founder of the Agile Lean Europe network and the Stoos Network. He is also a speaker who is regularly invited to talk at business seminars and conferences around the world. After studying Software Engineering at the Delft University of Technology, and earning his Master’s degree in 1994, Jurgen Appelo has busied himself starting up and leading a variety of Dutch businesses, always in the position of team leader, manager, or executive. Jurgen has experience in leading a horde of 100 software developers, development managers, project managers, business consultants, service managers, and kangaroos, some of which he hired accidentally. Nowadays he works full-time managing the Happy Melly ecosystem, developing innovative courseware, books, and other types of original content. But sometimes Jurgen puts it all aside to spend time on his ever-growing collection of science fiction and fantasy literature, which he stacks in a self-designed book case. It is 4 meters high. Jurgen lives in Rotterdam (The Netherlands) -- and in Brussels (Belgium) -- with his partner Raoul. He has two kids, and an imaginary hamster called George. Jurgen has posted 145 posts at DZone. You can read more from them at their website. View Full User Profile

Networked Kanban

03.28.2013
| 2426 views |
  • submit to reddit

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

Big-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.

Small-kanbanThe 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…

Published at DZone with permission of its author, Jurgen Appelo. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)