Kanban – Visualizing the value chain

Kanban Board Graphic

Introduction

In this article let me give you some tips on visualizing the value chain of the workflow using Kanban. In order to do so, we have to keep in mind that Kanban does not seek to install a new workflow, neither does it change job titles, roles, responsibilities or specific work practices.
The key to Kanban is to optimize the existing workflow process. Using this method not only gives results, but also allows you to avoid any kind of hostility from the co-workers who might identify themselves with their current position in the company.

The main goals of the improvement should be:

  • visualize the workflow
  • limit the Work in Progress
  • measure and manage flow
  • make process policies explicit
  • use models to recognize improvement opportunities

What is more, when we depict our workflow process, we should describe our current value chain’s actual process, not the official one which most of the time isn’t really used.

Defining a start and end point

Firstly, we must ask ourselves where the process visualization should start and where it should end. Since we want to visualize our own work process, those beginning and ending points are the interfaces to up- and downstream organization units. We receive tasks from the upstream unit and as soon as we move the task through the workflow process, we pass it on to the downstream organization unit.

Experience has shown that successful teams have managed to achieve this by using physical cards on a Kanban board for visualization restricting the WiP only in the area they’ve been able to control themselves defining new rules with their up- and downstream process partners

Task types

The next step should be to  define what task types we should use in our workflow. Common examples are as follows.

Basic task types:

  • feature
  • chore
  • bug
  • very important

More task types:

  • request
  • user story
  • use case
  • change request
  • production error
  • maintenance
  • refactoring
  • improvement request
  • blocker

We can extend these basic task types by having hierarchical task types, which are a collection of another type, for example epics are collections of user stories.
We can also indicate the source of a task, i.e. where it came from, in the task name, for example legal requests, external work requests or requests for strategical planning.

Tasks should have a specific size assigned to them. Typical task sizes are:

  • small (a few days)
  • medium (< 1 month)
  • large (≥ 1 month)

For some businesses like IT these sizes might evolve to smaller durations, like a few hours for a small task to several days for large tasks.

Drawing a Kanban board

For visualizing the Kanban process using a board, it is important to remember that Kanban visualizes the actual work, not people, functions or function transfers.

To be able to define the board and its work steps in columns, it is very helpful to sketch the current workflow using some sort of diagram. This could be a flowchart, a diagram using stick figure, etc.
Once we have done this, we have an idea which steps a task goes through during its life cycle. These steps will be represented by columns in our Kanban board. They represent how and in which order our work is completed, the column order is equivalent to the work order.

At the very beginning of introducing Kanban, it is very likely that there will still be changes to the Kanban board. Therefore one should use a wipeable pen or chalk or something similar to draw the board.
Later when we feel that the board structure is pretty much fixed, we can use something more permanent, like vinyl strips.

Columns can be split horizontally into two sub-columns, the first one depicting tasks currently in progress, which can be moved into the second one when they are finished regarding the current work step. They are then ready to be pulled into the next column.

The first column should represent the input queue where tasks are received from the upstream unit and the last column should be the output queue where tasks are passed on to the downstream unit.

It is also possible to have a buffer or queue column as a previous step to a column. These buffers and queues can prevent blockages in case a work step has reached its WIP limit and can’t pick up any more tasks at the moment.
The buffer/queue columns can be visualized by for example cards turned by 45° to make them distinguishable from the regular columns.

Demand analysis

To be able to estimate SLAs and work capacities for different task types, we perform a demand analysis for each one. If data from previous work already exists, great, we can use it for our quantitative analysis. If there is no such data, we can use a reconstructed, subjective analysis. Kanban is all about continuous improvement (kaizen), so it doesn’t need to be super-accurate. We can improve the data as we go.

The demand analysis shows at which rate the different tasks are arriving. For example:

  • PTCs (production text changes) might arrive in batches, they are small and quickly realizable and have negligible effects on the workflow
  • Change requests arrive at a continuous rate. It can be visualized on a diagram and the Kanban system can then be provided with the proper resources
  • Requests with seasonal demand arrive at one season at a higher rate than at another season. Here we assess the demand per season and adjust Kanban accordingly

Distribution of capacity by demand

After assessing the demand for each task type we can assign capacities to the tasks. These are represented by swimlanes in the board ( vertical divisions of the board) each with its own capacity in %.

Let’s look at the example. We can assign 60% to change requests, 10% to maintenance tasks and 30% to PTCs. This will ensure a pretty predictable workflow and cycle times, but will not use the full capacity of the board when at times little to no PTCs arrive.

Figure 1: Example for distribution of capacities per task type

To handle this, we can change the capacity for the PTCs to only 5% and add the gained capacity to the change requests. This will make a better use of the total board capacity, but will backfire on us when a batch of PTCs comes in, leading to reduced adherence to schedules, longer cycle times and a bad predictability.

Figure 2: Example for distribution of capacities per task type

A third solution would be to give PTCs no capacity at all but to introduce a rule that PTCs are allowed to exceed the WIP limits. This will prevent the idle time but also lead to a bad predictability with the arrival of many PTCs at the same time.

Figure 3: Example for distribution of capacities per task type

The ticket structure

Now we should define the ticket cards representing a work task on the Kanban board. The information on such a ticket must support the pull system of Kanban, it should enable employees to make their own decisions and should provide full transparency over the work processes, the project goals and risks.

Through this, we can achieve a self-organizing risk management system with respect for every individual, leading to a higher trust in the system.

Example:

Figure 4: Example for a typical Kanban ticket structure

Electronic tracking

Electronic tracking is essential for geographically distributed teams. It can also lead to a higher degree of organizational maturity.
There are already multiple solutions out there in the market, some desktop applications and some web based applications.

Examples for desktop applications which are not web based:

Examples for web based applications:

Additional examples for web based applications:

Defining in- and output boundaries

The in- and output boundaries are set at the interfaces with the up- and downstream organization units. Your Kanban process should provide transparency for your own work. Later, when trust and cooperation to up- or downstream units are built up, they might be included in the Kanban process as well.

An example for an input boundary would be the interface to the analysis unit. There might be little trust between that unit and our development unit and it also may report to a different manager.
Work tasks from that unit will go into the input column: Engineering Ready.
When the task is ready for deployment, it will be passed on from the according output column to the downstream distribution unit. The task is then no longer of concern for the development team.

Handling concurrency

Concurrent activities are two or more activities taking place at the same time, like software and test development. There are multiple solutions for modeling concurrency. One solution might be not modeling it at all. Both activities share a column, but different activities could  be visualized by multiple ticket colors or shapes.

Another solution would include splitting the board vertically into sections for each activity. Tasks are split when they are pulled into the column with multiple simultaneous activities and merged together again when they are ready to be pulled. We need some markup mechanism to connect the split tickets, for example connecting the upper right ticket corner by some band. Of course an electronic ticket system can also be able to visualize the connection in an stylish way.

Handling non-sequential activities

Non-sequential activities are sub-activities of a work task which can be finished in an arbitrary order. As with concurrent activities, there are multiple possible solutions for visualization.
The first solution might again be simply not modeling it at all. We use one column as the container for the activities. To know when a task can be moved into the ‘ready to pull’ area, we can introduce small checkboxes, so that the task is ready when all boxes are marked as done.

A second way would again incorporate splitting the column into vertical areas. The tickets move into the according area while working on a subtask.

Conclusion

At this point, let’s sum up. Visualizing the value chain of our work process consists of the following steps:

  • defining the borders to the up- and downstream organization units
  • defining the task types
  • modeling the flow of the different task types through the system
  • modeling the structure of the tickets
  • evaluating if it is sensible using an electronic ticket system
  • modeling concurrent activities
  • visualizing non-sequential activities

Sharing is caring!

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.