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.

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…

(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.)

  • My Management 3.0 World Tour
  • Delegate the Course, Trust the Trainers
Related Posts
free book
“How to Change the World”
  • Hass Chapman

    I too have experienced your problems and thoughts with Kanban and the lack of sequentiality in software development. However, I have approached this as an over-interpretation of what Kanban really means and what detail is required. Consequently I have often chosen to implement Kanban with only those columns that show value changes for the stakeholders: Ready for dev, Ongoing, and Done. I see no relevance of popular columns such as “waiting for QA”, “QA”, or “In review” , etc. The only relevance is whether it is in development or done. However, a couple of teams I have coached have really wanted a QA state and I have (in the interest or self-organisation) allowed this but then as a swim lane within the Ongoing column so that items are free to move back and forth between these states.

  • Paul Klipp

    Finally I see a solid use case I can get behind for the “move ticket to another board” feature that we built in Kanbanery based on user demand.

  • VFQDev

    You have invented email. Or a slightly improved workflow version of email. I carried out trials of a product that helped manage this across a complex department as part of the Management Labs of London Business School in 2008. We had a computer program that ran over the top of email, and monitored the flow of work.
    A system where requests are sent to each other (placed into states such as unread, inbox, filed) with a connected to-do list. It also included the ability to commit, meaning people could manage their work in progress and queue unlike in email.
    It included many of the concepts you have suggested above, we had complete transparency of people’s boards, in fact we could even see if people were not achieving the commitments, and thus consider how to respond. This was all driven from good concepts, no fear, no blame, as part of a well established and successful scrum team. Visibility of flow was our primary aim and to speed up how complex work moves through the network.
    Unfortunately Jurgen, it may be time for you to move back to idea farming. It was an unmitigated disaster. Whilst Personal Kanbans were extremely popular, and many people made great success of them. The scaling out requires a consistent that many did not want to adopt. When a kanban board is personal (or belongs to a small group), they do not necessarily feel the urge to always keep it up to date, further to this people began working off board (people have a habit of doing things like that).
    The sheer complexity devoured the entire concept. This is at a time when our teams were successfully implementing Kanban long before it became popular. Essentially similar to your problem above, we could not cope with the variation inherent in a complex system
    There may be ways of achieving it, but I feel based on our experience the approach above will fail for the very same reasons why you are suggesting Kanban also fails.

  • Chrisvmcd

    I think this is a really interesting twist! I’m currently working with a team that can have work either start with dev and transition to QA or the other way round, start with QA and transition to dev. There is also work that hits our team that doesn’t transition between the two disciplines and can be worked on be either group. The choice is generally dependent on the work item type. I’ve struggled to suggest a way to visualise this without making the board either to generalised or overly complicated. A networked Kanban is certainly food for thought.

  • Jurgen Appelo

    Thank you for your input. I think we must understand _why_ similar (but different) approaches failed and try not to make the same mistakes.
    But just like one person’s success does not mean success for others who try the same, one organization’s failure does not mean others will fail in the same way.

  • VFQDev

    Totally agree, but I think you point out in your reasons above why these systems fail.
    Non-linear flow, transformative work, and dispersed teams.
    In my current work we have very similar issues to you. The dispersed boards and the network don’t necessarily solve the problem. One of our biggest problems unlike a small software development team, is that it is very difficult to bound our work. Whilst I see many benefits to limiting work in process and visibility, I still feel more is required to solve the problems above.

  • CA

    I actually like this approach.
    Some initial impressions:
    1. Creation of a silo mentality, especially in matrix orgs. I did my piece and passed it over to you. I care only about the throughput of my team since I’ll probably get measured based on my team’s Kanban.
    2. Without some sort of enforceable policy, I also see work bouncing between groups.
    As the saying goes, sum of parts is not equal to the whole. How can we ensure the focus of all the teams in the network is on system throughput and not individual Kanbans?

  • Johan Oskarsosn

    This is a very interesting subject. I’m currently working with network kanban system on one site. Where I have so far 6 boards in the network. it pretty much follows mr. Leffingswells ide of kanban system. They all starts with a kanban board for Product managers to improve their business cases which has already been accepted by a portfolio council. Quite alot of columns but I still think it good to visulize the workflow, we have so far not needed to move items back-and-forth there. Here the Epics become Epcis plus features related to the Epric.
    Next board is a prep board for Pwoduct owners to break Features down ot Stories and have them prepared with UATs, draft design and estimates. This boards final column is the teams (3 team) backlog.
    Board 3,4,5 is the teams boards, classics with added column for create test cases, since we are moving towards TDD.
    Board 6 is the QA(or system test) board.
    We do not have any hard roads for tasks or other otem to move between boards, since they do, but we do move items between boards based on the morning info and needs.
    I might try to draw a network diagram based on how the flow moves between board to find patterns. It might be a good idee to discuss inthe comming retro.
    Any more info on this subject is welcome.
    Johan Oskarsson
    Knowit AB

  • David Joyce

    The diagram you drew in this post is great, and one that I have seen used successfully in the past. I’m not a fan of arbitrarily limiting columns on each board though, but to instead let the team decide which columns are of use for them. As always IMO its contextual. MIP in this instance would be a constraint for teams who want to have more (for valid reasons to them).
    The toughest part is the co-ordination and communication between the teams which is true of any multi-team multi-location endeavor.


    One of my teams and I have been doing something similar for about a year now. We have distinct value streams on our team, a fact we discovered right away when trying to model a single value stream.
    I don’t see or grasp the need to get away from calling them value streams, there are just multiple paths.
    Our DBA has tasks which are important to the team but do not follow the flow a feature or bug would. Our architect has something similar, and the tasks I do SE/PM also has a different flow.
    However we also have dependencies between these items – I may need to go get a solid decision from stakeholders before development can proceed, our SA or DBA may need to set up an environment before testing can begin, etc.
    Josh Nankivel, pmStudent

  • Alberto Brandolini

    Hi Jurgen,
    I’m experiencing a similar starting point, but getting different intermediate problems. I’m observing quite a few “non-linear” processes, but for some reason (maybe because I am doing something wrong) this doesn’t end up in more columns or more steps, but more often in more rows. Most of the time looks like I am trying to push different items into the same flow, and 2nd and 3rd generation boards are getting split horizontally with a different set of steps hence different independent flows, but still rather short. Well …this does match point 1, but doesn’t necessarily relate to point 2 and 3. In general a non-linear flow triggers a “maybe I didn’t get it right, at first” thought, that often leads to a more coarse grained column definition, and sometimes to a more finely grained row definition.
    I also have a feeling that the level of detail required is related to the level of maturity in the organization. I might need a more finely grained board in the beginning to spot bottlenecks in a foggy/messy team organization. Once the long awaiting bottlenecks are attacked, the whole system becomes more fluid and the extra detail required becomes lesse relevant.
    Does it make any sense?

  • Alan Shalloway

    notes from the birds of a feature that kicked this off are at


    No one works on just one project, which is why the project kanbans focus on team value over individual value. But, part the variation in team throughput is load on individuals. In addition, surprise projects show up from time-to-time and often against our wills.
    MIPs is a great way of seeing the actual cognitive load on people – even if their WIP is seemingly under control.
    I’ve been working with a team in Germany on building out a networked model of work deployment for the last few months. They are in a vertical where all work can be atomized and reconfigured at will. So the objects of personal, team, and project value are always in flux.
    The false linearity of the current popular kanban model belies the amount all our work is in flux.
    Having said that, I would still urge people to ease into visualization by making visualizations as easy to understand and immediately useful as possible. While you and I and Al certainly see that workflow is more complex, teams are in such need of continuous improvement (and in a state of unimprovement) that the linear view still holds great value.

  • Bruce Onder

    I really like this idea. Strangely, while another commented mentioned working on an email version of this several years ago, I remember the folks at the research facility where I worked working on something like this back in 1991. I really don’t remember details, other than a) the other commenter’s description jarred my memory and b) it was a prototype and I am sure it never went anywhere. Not because of bad results but because 95% of the work we did there was speculative in nature.
    I would say, though, that networked kanban is a prime place where you need to have ready queues between kanbans – these queues become the front line to examine to see where your bottlenecks are between teams/boards.
    Good stuff!

  • Johan_tre

    To me this sounds like an interesting idea.
    At least at first.
    Some remarks: With multiple boards, how can one prevent the throw-in-next-basket-and-don’t-care mentality?
    @Jurgen: What are the type of triggers that make a card to move from one board to another?
    Is there a common denominator-reason?
    I was also wondering: How do you visualize the flow between boards?
    Lately I was investigating Mingle as a solution for visualizing scrum boards.
    Its flexibility is the eye catcher.
    This article, that flexibility, and the option “copy to other project” made me wonder if all teams could be cooperating more efficiently with multiple boards.
    At least it increases simplification per team.

  • Mich

    Some times people prefer to use regular kanban board and it is efficient for them. My company becomes lately more virtual organization. The only way out was to implement online kaban tool. We choose KanbanTool. It’s easy for everyone but it has also many useful features, you are able to customize your board as you want. I recommend

  • Paul_boos

    A couple of things…
    Top level visibility as to which board (team) has it may be useful. Particularly if you wanted ot have higher level organization talks about in-work items between groups.
    If you really must, stats about how many bounces items bounced between boards could rove useful for discussions on whether they should be occurring and for a starting point on discovery if they are not.
    IF the flow is more or less linear (and what Jurgen is suggesting here is it does not for what he has been seeing), this could be a represented by a Kanban board that represents the flow higher up in the organization. BTW, I’d say this type of networked connection to boards (if you plan to have digital ones) could be done by a CRM system that allows ad-hoc flows.

  • women business owners

    Thank you so much for giving us some clarification regarding Network Kanban.

  • Pingback: A ciência por trás do Kanban #LeanPM #Agile | Gestão de Projetos na Prática

  • Pingback: A ciência por trás do Kanban | TRENTIM

How to Change the World - free Workout - free