Kanban in a non-linear flow

A Kanban board is supposed to represent the current process, the way it is right now. Representing the way we work on a simple, linear, Kanban board, is not always easy. In fact, it’s not always possible. Sometimes, the way we work is more complex than that. Jurgen Appelo described how to deal with more complex systems in his recent post on networked Kanban, and that’s what inspired me to write this post.

When first reading about it I was intrigued by the thought of modeling more complex structures as well. As it sunk in on me, however, I realized this also could mean letting go of one of the major advantages in Kanban – the way we improve our flow from start to finish.

I ended up conversing this with Jurgen Appelo and David Anderson on Twitter, and they both helped me understand this better.

Visualizing the current flow, and then continue to improve over and over again, is a key element in Kanban. So what happens if the current flow is too complex to visualize it linearly? Jurgen Appelo suggests using a networked Kanban, a collection of small Kanban models interconnected. The different teams only look at their local Kanban models and improve their local flow.

If there are several local Kanban models in a workflow, how do we improve the flow in the network as a whole? In the end, that’s what we want, right?

In a Kanban representing a linear flow we improve the flow from start to finish. In a non-linear Kanban, if the interdependencies are complex enough, only a few people will understand the entire flow – from start to finish. For local Kanban models it’s business as usual. It might even lead to reduced complexity for them, as they now only need to deal with a simple flow.

What’s bothering me a bit, at first sight, is that if we do this wrong we risk that local Kanban implementations are sub-optimized against the best possible global performance, only because they don’t see the bigger picture. Also, if we start off with a complex structure like this, it will make Kanban “harder” to introduce. If we have too many project policies regarding entry/exit criterion between different Kanban models, people might start treating Kanban as process – not a method.

The clear and to the point linear Kanban board is easy to grasp. People walk by and understand the current process and the status right away. The team itself understands the entire flow and optimize it continuously. Will this be harder with a networked Kanban?

I believe the answer to the question above is yes, but that doesn’t mean it’s a bad idea. Forcing a non-linear flow into a linear Kanban is not a good idea, so we need to look for new ways of representing, visualizing and improving more complex flows.

More research on this topic is necessary, so we get a better understanding on how this can be applied. How can it be visualized, who should be responsible of improving the entire flow, how will different teams interact? And most important, how do we do all this stuff without turning it into a rigid process?

Personally, I would like to see several different examples on this. The backside with examples are that they might set the standard on how this should be implemented. Therefore, it will be important to view this from different perspectives. We need to appreciate the fact that all have different needs, and that there should be as many ways of doing this as there is networked Kanban implementations – just as regular Kanban implementations today.

Here’s a couple of ingredients to keep in mind when you apply this:
1) Let the independent Kanban systems optimize their own flow. Treat dependent systems as “customers”. (David Anderson)
2) Scale out and not scale up. It’s better with 10 simple models instead of one complicated model with 30 columns. (Jurgen Appelo)

To me, this approach is new, but it has actually been brewing for a while. As it turns out, David Anderson presented a similar approach to what Jurgen Appelo described in his post at LESS 2010 in Helsinki, and Reaktor has been coaching this approach with clients for a while.

A final remark: Even though we now have the tools we need for modelling a complex flow, try to keep it as simple as possible!

If you have any experiences or thoughts on this, I would love to hear from you! Use the comment field below, or drop me a note on Twitter.

Note: David Anderson will cover this topic in his next book on advanced Kanban, which I’m really looking forward to reading.


  1. Siddharta says:

    Great post. I had the same questions. I was going to blog about it, but this blog covered most of my questions.

    Has network kanban been used at some place or is it more of the thought experiment? If it was used what was the outcome?

    My initial feeling was by breaking up a kanban into small kanbans, you completely lose the system view. Its back to small teams working without knowing whats happening elsewhere. They know cards are coming in and going out, but whats the big picture? Do they know that there is a bottleneck somewhere else where they can help? or are they sending cards to another board when there is no capacity over there for handling more cards? All these knowledge is lost when each person can only see one small part of the system.

    Also, I get the feeling that too much of network kanban is about “modeling” and too little about visualisation. There is no rule that the kanban board is a “model” of anything.

    In my team, we have one board with all the cards, but a lot of work is nonlinear. Cards can move left to right, right to left, skip columns etc. Who says cards should only move left to right? Some teams I have talked to even have columns that do not represent any workflow state (eg: a column with team members name on it). Why? Simply it is to visualise the work.

    The important thing for us is visualisation. Where are the the cards, where are bottlenecks, are there any queues forming. Whether cards move left to right or right to left or it is an accurate model of exactly what we do is less important for us.

    Maybe network kanban is a more accurate model from a scientific perspective, but in my understanding of reading the blog post, it has sacrificed all the visualisation to get there.

    What are your thoughts? Did I misunderstand it?

    1. hunskaar says:

      What a great response, Siddharta!

      The way I see it, you didn’t misunderstand it at all. All your questions and comments are highly relevant, and similar thoughts are what triggered this blog post.

      If we break a Kanban up it into small Kanbans, you will completely loose the system view. I really liked your phrasing on this. To get the same effects we have with regular Kanban today, I assume we need some new mechanisms to be able to improve the entire flow.

      So from a scientific point of view, this is what’s missing right now – at least I haven’t seen much of it yet.

      David Anderson told me Richard Turner has a research project on this topic going on, so I guess there is more to come?

  2. Johannes says:

    Interesting thoughts! What do we want to accomplish with this, what are the problems we are trying to solve? I can relate on a certain level to the problem, but I’m struggling with the basics: What do we mean by non-linear? Some examples could be useful. I can think of a couple of alternative definitions and situations, but your thoughts would be appreciated.


    1. hunskaar says:

      Great questions, Johannes! Unfortunately I’m not able to answer them all, but here it goes…

      To be honest, I’m also struggeling to see exactly where this can be applied, but I think Jurgen gave a pretty good explanation of when a linear Kanban board doesn’t really fit anymore (in the beginning of his blog post). My interest in this, for now, is mostly from a scientific perspective, but I would also like to see practical examples of this.

      I can, however, give you a simple example that is somewhat related, but I’m not sure if it goes under the “networked Kanban” definition. You see, we use Kanban in our retrospectives, and we move tickets between the project’s Kanban board and the retrospective meeting board according to certain rules. The tickets moved between the different boards are not necessarily one-to-one, they are split up or merged with other tickets if necessary.

      You can read more on how we do it here, but I’m sure other can come up with a better examples than this?

  3. “The different teams only look at their local Kanban models and improve their local flow.”

    Actually no, that’s not what I wrote (or at least not what I intended).

    I doubt that a strong coupling between boards and teams is required. I think the opposite might be needed. Teams swarming across different boards.

    1. hunskaar says:

      Thanks for the clearification, Jurgen!

      What you say makes sense, this will reduce the board complexity, but still give you much of the same advantages you get with regular Kanban (direct communication, improvements with the “bigger picture” in mind, etc.)

      Would you be worried that “domain experts” only really care about their own board?

  4. Siddharta says:


    So how they they know what is happening in other boards? Do they walk to each board every day? Or there is another big board which aggregates all the other small boards? Or all the small boards are kept next to each other?

    I think having one big board with all the states is much simpler, and have the card move between columns (in both directions and in circles if necessary) is so much easier. What is the network kanban solving?

  5. CA says:

    Losing the system view was my fear when I embarked on implementing Kanban a year ago. I work in a matrix org where the same person may also work on projects, support and maintenance activities. Moreover work flowed in a non-linear fashion; i.e. work used to (and still does) bounce between teams.

    What I ended up doing is too long to explain it here; I blogged about it “Making Kanban work in matrix organizations” (http://www.kanbanway.com/making-kanban-work-in-matrix-organizations). Feedback and thoughts would be appreciated.

    1. hunskaar says:

      Great post, CA!

      The scenario you described from a matrix organization sounds very familiar, and you might have found a way to make this work using swimlanes and work centers. I don’t have any experience using work centers the way you described it. However, it strikes me that we, to some extent, already “depend” on work centers when we follow up tickets with dependencies outside a project – we just don’t see it as a part of the flow.

      If we start off with a set of work centers, but decrease the number of work centers over time, we end up with more cross-functional teams. This is a good agile principle, and I like that the way this approach makes it possible to do this one step at the time.

      This is the most complete networked Kanban example I have seen so far. It adds complexity, but it also enables new ways of improving the flow – in the system as a whole. Thanks!

  6. hunskaar says:

    Pawel Brodzinski posted a somehow related article, “Don’t Stick to Standard Kanban Board Designs”:
    Recommended reading!

  7. Great comments. I agree the importance is visibility – not modeling. However, there are some advantages of a Kanban board letting people know what is happening (that is, the nature of the workflow). This is one way explicit policies are conveyed and is very useful for team’s education.

    Also, i’ve used a collection of Kanban boards together before without losing the system aspect of things. However, I can definitely see that being possible. I believe that some of the issues being raised are items for exploration and further study. Nothing said we’d know all there is to know about Kanban in just a few years.

    I am not convinced that a network style of kanban boards can’t still be simple, show visibility and add another dimension of useful information. That’s why I held the birds of a feather that started this off. Always good to ask questions.

    Love the conversation.

    1. hunskaar says:

      I appreciate your comments, Alan!

      Based on all the feedback so far, I think you sum it up great! Using a collection of Kanban boards together is possible without losing the system aspect of things, but there’s always a risk that it might happen anyway. The way we apply it is crucial.

      An observation:
      I mainly work in the context of a project. Of course, I use every opportunity I have to remove bottlenecks, but being responsible for a project makes me focus more on my project than on the entire flow. If the organization were using networked Kanban “all the way”, our project would just be a local Kanban, in a bigger network, and we would mainly improve our own flow.

      A (big) lesson learned for me, thanks to all the great feedback so far, is to look for better ways of improving the flow as a whole, not just improve the flow within our project and our immediate dependencies. We should also look for better ways of visualizing the flow. It shouldn’t really add a much more complexity, instead it should give us a better understanding of the system *as a whole* (which enables us to make better decisions).

  8. notes from the birds of a feather that kicked this off

Start the Discussion!Leave a Reply to hunskaar Cancel reply

Your email address will not be published. Required fields are marked *