This will be the last post in the series about process visualization in professional services, specifically within the context of applying the Kanban method and one of its core practices, visualization. Earlier in this series:

• How to understand the process as collaborative discovery and enrichment of knowledge and to visualize accumulation of knowledge and not operations and handoffs. Note that we depart here from the notion that a process is an algorithm made of prescribed steps. We explore the process as it actually happens through imperfect decisions and actions of people working in it.
• The first post in the series included an example and more examples followed (1, 2)
• How to map processes and create such visualizations with groups of people. To keep this post relatively compact, I only included the recipes here.
• Observations and learning from applying this approach in practice

Now it’s time to write about the thinking behind the knowledge discovery process, the mapping techniques I presented, and the explanation of what I observed by applying them.

Simply put, we have to respect the complexity of the system – and the group of people working together to perform some creative tasks to deliver their service is a complex adaptive system. Basic understanding of the Cynefin framework is essential here.

The problem of evolving processes in our complex system and discovering its future improved state falls into the Complex domain. The Cynefin framework informs us of two kinds of things what should not be doing:

1. implementing best practices, which belong in the Obvious domain
2. applying expert analysis, which would be appropriate in the Complicated

A Model of a System Will Affect the System – How Weird Is That?

The Kanban method is an evolutionary method appropriate in the Complex domain. When we introduce a kanban system within the context of the Kanban method, the kanban system is essentially a probe launched into the complex system of workers, their organizational partners and customers. The probe will co-evolve with the system. How well or poorly this probe is designed may affect the effectiveness and success of the evolutionary change. Designing the kanban system and introducing it appropriately in the given context is one of the key skills of Kanban coaches.

In the last several decades, an approach known as Value Stream Mapping (VSM) has become very popular. A value stream map lets us see value-adding and non-value-adding activities that make up the process of delivery of value to the customer. The implication here is that we can improve the process by reducing the non-value-adding activities or waste. This has been done so many times as to create a wide-spread, though not accurate opinion that Lean is about eliminating waste. The hidden assumption here is that we are treating our process improvement problem as a Complicated-domain problem. It is the Complicated domain that permits such reduction and aggregation.

The process visualization we are trying to create as part of our kanban system introduction is a model of our system of work. In the Complicated domain, a good model would be detailed and accurate enough (and VSM certainly delivers that) to enable us to expertly analyze the system and find improvements. But in the Complex domain, which does not permit an approach based on reduction and aggregation, the quality of our model is determined primarily by what response it provokes from the system.

It was observed by Alisson Vale, one of the pioneers of Kanban in professional services and a 2010 Brickell Key Award winner, that workflow visualizations with too much detail provoke inertia. If a Kanban board has too many columns in it, perhaps appropriately considering the number of steps in the accurately mapped process, it fatigues the workers and slows down the pace of evolutionary improvement.

Heuristics

The approach to Kanban visualization and observations of using it in practice that I presented in the earlier posts in this series (1 and 2) are largely consistent with complex nature of the problem and the heuristics of the Complex domain.

One such heuristic (a negative one) is retrospective coherence. It warns us about the danger of trying to replicate successes from one system to another. A more effective approach is not to repeat the causes of failure. Inertia due to kanban board detail is one clear example. Mapping the process by a small group of experts is another. Yet another example: steering the conversations in front of the board away from “hey, this is waste, let’s eliminate it” towards safe-to-fail experimentation. Well, in kanban systems visualizations based on the knowledge discovery process, all dominant activities are value-adding!

Other heuristics (positive) are fine-grained objects and disintermediation. Indeed, groups of people participating in the mapping exercise find the right granularity of activities for them. The resulting workflow visualization comes directly from them, and not through an intermediary such as expert process analyst.

Complex systems are also known to be path dependent. We have seen this with “dev” and “test” captions on software delivery Kanban boards. Whereas in a naively visualized process these columns may continue to visualize functional silos, the groups that have taken the path through the knowledge discovery process mapping have a deeper understanding of them as collaborative knowledge-producing activities. “Dev” and “test” are merely convenient shortcuts.

As other kanban system users and Kanban method practitioners try the knowledge discovery process visualization approach, I expect their own ways, recipes and observations to differ from mine. However, I predict that we will have a lot in common when it comes to the complexity thinking behind what we do and the use of Complex domain heuristics. I would love to hear their stories.