Fig. 1 – Naive process visualization as hand-offs back and forth between functional silos

Fig. 2 – Pseudo-Kanban board resulting from the naive visualization

Fig. 3 – The process understood as accumulation of knowledge and information through a sequence of dominant activities

Fig. 4 – Kanban system design resulting from understanding the process as collaborative knowledge discovery and identifying the dominant activities

I’m continuing the series of posts dedicated to visualization of creative processes. Earlier in this series, I wrote about:

1. understanding such processes as sequences of dominant collaborative activities, resulting in knowledge discovery and information arrival – with an example from software delivery
2. examples of such processes from other fields (one example, another)
3. mapping an existing process with a group of people working in it

As a reminder, what we’re interested here is mapping the process as it actually happens – through the daily interactions and irrational decisions of the people involved. Instead of naive, siloed visualization of the process (Fig. 1), which can lead to ineffective information radiators (Fig. 2), we try to understand the process as collaborative knowledge discovery (Fig. 3) and incorporate its identified dominant activities into our kanban system design (Fig. 4).

Because my last post only presented a recipe for process mapping, the purpose of this one is to present the most important observations, surprises and pitfalls, what was learned from using this approach in practice.

Map the process with as large a group as possible

This is probably the most important bit of advice and it’s an easily avoidable pitfall. The knowledge accumulation chart (such as the example in Fig. 3 with three dominant activities; you are likely to identify anywhere between two and six) looks very simple. But no matter how simple it looks, resist the temptation to draw it alone as a process coach or consultant or manager, or to do it with a small group of people, such as managers or team leads. Invite the largest practically possible number of people actually involved in the work.

What I observed with the groups I coached when we did try to map processes in smaller groups is that those few people would eventually come to dominate the conversations happening on the daily basis in front of the Kanban board. People who were not included in the mapping exercise were less engaged. Inviting them is a very cheap (and therefore, high-return) investment into the health of your evolving process.

Durability instead of “board churn”

I had many opportunities to compare stories of groups who used this approach with those taking a more simplistic approach: “let’s just visualize our work, we kind of know what our process steps are.”

The groups taking the more simplistic approach encountered the following situation much more often. Soon enough after designing their Kanban board, a work item would arrive that would need some variation of the process visualized by the board. It might need more process steps, skip some steps, or sometimes even need a separate swimlane. The group would change their board accordingly, but another work item would arrive soon enough and upset their new board design. Such Kanban boards exhibited evolutionary behaviour, but most of their changes didn’t constitute improvements – they were simply rework of earlier visualizations.

By contrast, the groups using my knowledge discovery process mapping techniques found their boards to be more durable. The changes were less frequent, but there was very little churn as changes mostly resulted from meaningful process improvements.

Short Captions and Collaboration

As groups chose captions for Kanban board columns representing the dominant activities of their processes, they often preferred shorter ones. “Dev” and “Test” were very popular.

Surprisingly, even if the group understood, for example, the code construction phase of their process as a collaborative, cross-functional activity, they preferred to label it simply as “Dev.” Similarly, the collaborative, cross-functional activity of exploratory testing would get labelled simply as “Test.” So, there would be “Dev” and “Test” next to each other on the Kanban board as if there was a functional silo of developers throwing batches of code over the wall to testers.

This observation contains two lessons. First, it is important not to judge groups of people by the looks of their visualizations. “Dev” and “test” next to each other may or may not be functional silos. Two visual boards may look the same, but the respective groups of people may have taken very different paths that to get there. Second, the mapping exercise I described in the previous post and continuing to reflect on in this one, can be used to promote cross-functional collaboration.

Manage work, not the workers

Managing work and not the workers is what we try to do with Kanban and other modern management methods. It is easier to do when the Kanban board columns represent activities and not functional groups.

“Linearized” workflow; easier to limit WIP?

The Kanban systems created by mapping the knowledge discovery process seem to be more linear. A better word is “sequential.” Indeed, since we’re visualizing accumulation of information, it should be sequential, as the information continues to accumulate during the process. It is important to remember that the arrival of this information throughout the process is still accomplished through complex, non-linear activities.

The sequenced order of dominant activities tends to eliminate one problem that people often ask about in training. If we found a problem in the work item at a later phase of the process and need to send it back, do we move the ticket back? For example, if the tester found a bug and needs to send the feature back to the developer, do we move the ticket from “test” to “dev?” (The answer: since the ticket was in “Test”, that means we have already exited the dominant activity of coding, which means our current dominant activity is getting any remaining bugs out before the release, therefore, “Test” is the right place of the ticket, although we might want to place a sticky note on it to indicate blockage.)

Reducing the backflows may also help some groups limit work in process. Tickets that flow back to Kanban board columns already filled to their capacity usually complicate attempts to limit WIP.

The Minimum Viable Process?

One of my workshop participants expressed the need for what she called “the minimum viable process (MVP).” It would be a process definition that doesn’t need a complicated block diagram in Visio, extensive documentation in SharePoint or enforcement by the process improvement office or the logic of application lifecycle management (ALM) software. She wanted the process to fit the brain, perhaps with the help of a few visual aids, not overburden the brain with information, and let her and her colleagues focus on the real work and not on the process.

Knowledge discovery process visualizations with sequences of two to six dominant activities, previously implicit policies turned explicit can be close to meeting such needs.

Integration with STATIK

The process mapping techniques I’ve presented are fully compatible with STATIK (the systems thinking approach to introducing Kanban). After taking the first two steps of STATIK – first, understanding the existing sources of dissatisfaction, and second, the demand analysis, after which we know all work item types – the third step is mapping the process for each work item type. This is where we can use these process mapping techniques. The introduction of the kanban system can then be completed by identifying the classes of service that are provided for each work item type, designing other kanban system elements and rolling the system out.

As the STATIK process tends to be iterative, the coach and the working group may choose to apply it again in the future to refresh the design of their kanban system. When it comes to step three, these process mapping techniques can be applied again.

I have observed that the demand analysis exercise with groups of people working in creative fields often reveals more work item types then people think they have. Each work item type represents some organic connection to either external customers or an internal work group. It is therefore more important to find all work item types than to map the process of any of them more accurately.

Simple, but not simplistic

The process visualization techniques I’ve presented so far are really uncomplicated. But they are grounded in the understanding of groups of people doing some creative work as complex adaptive systems. The simpleness of these techniques comes from appreciating this complexity and finding the few useful heuristics and constraints we need to manage in the Complex domain. This simpleness is not the same as the simplicity of best practices or the simplification of complicated analysis performed by experts.

I plan to explain this thinking in the last post of this series.