With this post, I return to the topic of process visualization in professional services. I wrote previously how we can understand such processes as collaborative discovery and enrichment of knowledge and gave some examples. They key part is the focus on knowledge creation and information arrival through a sequence of collaborative activities rather than work centres, process steps and handoffs. (Additional examples can be found in the posts that followed: here and here.)

Now let’s turn to a different, related problem: how to start with actual existing processes and actually create such maps for using them in visual management systems. For teams and organizations using kanban systems, such visualization would be the visible part of their kanban system. For those evolving their ways with the Kanban method, it would be substantial part of their visualization practice, which is one of the methods’ practices.

In a nutshell, given a knowledge/information accumulation chart like this,

we could turn it into a Kanban board looking like this:

The method for mapping processes has three important aspects:

What to do, actually, and how – the recipe.
Observations made by actually doing it with groups of people, dos, don’ts, surprises and pitfalls – and we can only learn this by actually doing it.
Rationale behind doing or not doing things a certain way – what we need to understand to be more like chefs and not cooks.

It is also worth noting here, before we proceed, that we have already departed from the notion that a process is a prescribed sequence of steps. There is no block-diagram drawn in Visio and stored in SharePoint. The process is what actually happens and it happens largely through countless daily decisions (mostly irrational decisions) made by fallible human beings. What actually happens is the standard that we want to improve upon.

The simple stuff: what to do and how

To start mapping our process, we need the following information:

identify the organizational unit and its boundaries: usually a business unit, team, department or several related teams
identify the interfaces and services this groups delivers (to external and internal customers) and its work item types
find several examples of recently delivered work items of each type

It is very important to use actual examples. Without them, people can only debate their visions of ideal process, refer to any existing process documentation or argue how the process should be happening. With examples, we can trace what actually happens: various activities and decisions along the way. Three to six items for each work item type is usually enough. People who actually did some work on those items should be in the room. Don’t leave this to the manager, team lead or a process coach.

The examples should be lined up on the right hand side of a large, empty whiteboard. In this example, we have ten examples of recently delivered work items of four types.

Then every person in the room takes a stack of sticky notes, writes down the activities they performed or the decisions they made leading up to the delivery of each of these specific work items, and places their note on the whiteboard. The focus should be on what knowledge or information was gained as a result of such activities, rather than the mere fact of procedures and meetings taking place. The facilitator should ask the participants to do this one sticky note at a time and place them in the chronological order. We are tracing back what actually happened in the delivery process.

This activity turns out to be complex and social. People do not remember most of what they did, but they tend to activate each others’ memories. For example, a software developer may write a note that they wrote the code for the delivered feature. A tester may then recall they actually tested an incomplete feature, found several bugs in it and provided feedback to the developer. The developer may then recall that the feature was indeed incomplete at that point, that they consulted their colleague and devised some automated checks to prevent occurrence of such bugs, and that there was some coding to do after that. It is through this complex, co-operative game that the visualizations of the existing process’ dominant activities, turning points, collaboration patterns, and explicit policies emerge.

As the timelines emerge, the group should start notice similarities between them (within the same work item type, of course). The facilitator should consult with the participants to line up the sticky notes with similar activities. Sometimes, this becomes obvious quickly enough so there is no need to write down every single step for every work item example on a sticky note. The major, dominant activities can then be identified by reading out the timelines and clustering the sticky notes accordingly. As a reminder (this has been described in detail in the earlier post), one major activity dominates knowledge creation at any time, but eventually fades and is replaced with a new dominant activity.

In this example, the group reconstructed the timelines of six deliveries of a particular work item type and identified five dominant activities.

Explicit Policies

The results of this workshop can be easily transferred onto the new Kanban board. Each identified dominant activity will be represented by a column. The group should decide how to name each activity – these names become column captions on the physical board. Since there may be multiple work item types and each may have different sets of dominant activities, the Kanban board will in the general case have several swimlanes, each having a somewhat different column structure to reflect those differences.

This workshop also helps reveal the previously implicit policies of the process. Remember, one of the key practices of the Kanban method is to make policies explicit. These can include:

definitions of ready
definitions of done
sequencing or selection policies (some may refer to them as prioritization)
input and delivery cadences
and so on.

These can be immediately captured and transferred onto the new board.

The workshop typically takes two and a half hours. In my experience, it is best not to rush it, explain it well, facilitate it with good questions, and give people enough time to pick each other’s brains and reveal their process. Only in simple cases, we finished it in less than two hours. But we never took three hours or longer – I suppose the complicatedness of the process is offset by the limited attention span and degree to which people should care about details.

What’s Next

For the sake of keeping this post compact (more than 1000 words, but not much more), I only present recipes here. I plan the next two posts to be about:

Stay tuned.