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.
Disclaimer: This blogpost was originally published on a different platform. Formatting may be incorrect, links may be out of date.
Jørn Hunskaar 