Get best of the week

Kanban Method: Understanding Your Process as a Collective Knowledge Process - Part 1 (recipes)

With this post, I return to the topic of process visualization in professional services. As I wrote earlier, we can interpret such processes as the joint accumulation and enrichment of knowledge , and gave some examples. Their key part is the emphasis on the accumulation of knowledge and obtaining information through a sequence of joint activities, rather than production centers, process steps and delegation.

Now let's turn to the problem associated with this: how to start with real-life processes and create the correct reflection in the visual management system. For teams and organizations using the Kanban system, such visualization represents a significant part of their system. For those who develop their services using the Kanban method, this is an essential part of the visualization practice, which is one of the practice of the method.

In a nutshell, the knowledge / information accumulation diagram presented like this,


we can imagine such a Kanban board:



The process mapping method has three important aspects:

  1. What to do, in fact, and how - a specific recipe.
  2. Observations made by actually working with groups of people: the pros, cons, surprises and pitfalls - we learn only in practice.
  3. The rationale for doing or not doing something in a specific way is what we need to understand in order to be more like chefs, not chefs.

Before we continue, it is worth noting here that we have already moved away from the notion that a process is a prescribed sequence of steps. Missing flowcharts built in Visio and stored in SharePoint. A process is what happens in real life, and occurs mainly through the myriad of decisions made (mostly irrational) by people who are imperfect in nature. What happens is the norm that we want to improve.

Simple things: what to do and how


To begin reflecting our process, we need information:

  • : , , ;
  • , ( ), ;
  • .

It is very important to use real examples of work items . Without them, people will only discuss their vision of the ideal process, refer to existing documentation on the process, or argue about how this process should occur. Using examples, we can trace what is really going on: various activities and decisions made in the process of these activities. Three to six examples are usually sufficient for each type of work item. There must be people who directly worked on these work items. Do not rely on the vision of a manager, team leader or process coach.


Work items should be lined up on the right side of a large, empty board. In this case, we have ten recently set elements of four types.

Then each person in the room takes a stack of stickers, records the activities in which he participated or the decisions he makes leading to the delivery of each of these work items, and places his sticker on a white board. The main attention should be paid to what knowledge or information was obtained as a result of each activity, and not to the fact of the procedures and meetings. The facilitator asks the participants to stick one sticker at a time and arrange them in chronological order. We want to track what actually happened during the delivery process.

It turns out that this activity is complex and social. People do not remember much of what they did, but they tend to stimulate each other's memories. For example, a software developer may write a sticker stating that he wrote code for the supplied function. A tester may recall that they actually tested an unfinished function, found errors in it, and provided a report to the developer. Then the developer can recall that this function was indeed incomplete then, that they consulted with their colleague and planned to add several automatic tests to prevent the occurrence of such errors, and, accordingly, it was necessary to implement the plan. It is thanks to this complex joint game that the dominant activity of the existing process, turning points, patterns of interaction are visualized, and explicit rules emerge.


Over time, the group will begin to notice the similarities between them (of course, within the same type of work item). The host should clarify with the participants the order of building stickers with similar activities. Sometimes the order becomes obvious quickly enough, so there is no need to write down each separate step for each work item on the sticker. The main, dominant activities can then be determined by arranging them on a timeline and grouping the stickers accordingly. As a reminder ( this was described in detail in a previous post ), one of the main types of activity dominates the accumulation of knowledge for a while, but ultimately fades and is replaced by a new dominant type of activity.


In this example, the group recreated the timeline for six deliveries of a specific type of work item and identified five dominant activities.

Explicit Policy


The results of this workshop can be easily transferred to the new Kanban board. Each identified dominant activity will be represented by a column. The group must decide how to name each activity — these names become the column headers on the physical board. Since there are several types of work items and each of them can have different sets of dominant activities, the Kanban board will generally have several tracks, each of which has a slightly different set of columns to display differences in the process.

This workshop also helps identify implicit but implied rules. Remember that one of the key practices of the Kanban method is to make the rules explicit. It may include:

  •  criteria of readiness (Definition of Ready);
  •  criteria of completion (Definition of Done);
  • rules for ordering or selecting items to execute (some call this prioritization);
  • cadence replenishment and supply;
  • etc.

All this can be detected and fixed on a new board.

A workshop usually takes two and a half hours . In my experience, it’s better not to rush, to explain well, to keep up the discussion with good questions and to give people enough time to understand each other’s thoughts and understand their work process. Only in simple cases did we finish it in less than two hours, and there was never a case when it took more than three hours. I believe that the complexity of the process is offset by the limited amount of attention and the degree to which people need to dive into the details.

More articles:


All Articles