An introduction to Kanban (2nd part)

As we have seen, the Kanban system as applied to software development is quite far removed from its original form, which was devised in Japan to build cars. The only thing the two still have in common is similar objectives and the use of cards to regulate work flows. The first recommendation in applying the system is to concretely visualise work flows and processes. This means using a Kanban dashboard.

The WIP Limit

The basic idea of Kanban is to avoid bottlenecks and to maintain the balance between demand and production capacity. The premise is that overloaded, overextended workers are less efficient. This can be easily verified, though some will say that multitasking doesn’t necessarily mean overloading. In any case, the person managing demands (user stories), usually the product owner, must limit the number of simultaneous requests to the capacity of the first downstream team, usually developers. When properly executed, the Kanban system rests heavily on the shoulders of the person or persons who prepare tasks upstream, especially when it comes to prioritizing and dividing user stories into tasks.

Prioritizing and assigning tasks involves assigning a maximum number of current tasks (WIP, Work-In-Progress Limit) to each functional team. This system has a two-fold purpose: to make it impossible to impose a workload that exceeds the team’s capacity, and to protect developers’ health by allowing well-being to override other considerations such as client expectations, bosses’ requirements, sellers’ needs, etc. This avoids putting excessive pressure on the developers, thus enhancing product quality.

The Dashboard

The lynchpin of the system is the Kanban dashboard, a table presenting successive activities in columns from left to right. The process starts on the left and ends on the right. The first column shows the queue, or backlog, of tasks to complete, usually the result of dividing user stories into tasks. Each operational team has its own column in order of appearance in the process. Each activity can be subdivided into two sub-columns, for example “To be Completed” and “Completed”, if you need a buffer.

Of course, to create this dashboard, managers must already have a good idea of the process required to deliver the product. Therefore, the first step is to formalize the current process, or map it out, in consultation with all stakeholders. The Kanban method does not push any particular process; it merely seeks to control flows within current processes in order to optimize them. Indeed, Kanban adapts to existing processes, needing no organizational revolution, unlike the Scrum methodology, for example. That said, Kanban can help you revisit and improve your process later.

Getting back to the Kanban dashboard: tasks enter it on the left, then progress to the right. No task can move to the next column if it is full, i.e. if it is already at its maximum limit of work in progress. The basic principle is that an existing task must be completed before a new task can be accepted.

In our example, we can see the backlog of tasks in the full column labeled ‘backlog’. A product owner must select and prioritize the first six tasks, which will then be taken on by a team of two systems analysts, then by a team of five developers, and finally by the person in charge of deployment.

The cross-hatched sub-columns are overflow columns for completed tasks that are awaiting the next step of the process.

The number of tasks is arbitrarily limited to six in this example. It is just there to give the team glimpse of what is coming in the near future, particularly when the backlog column is full. Here, the ‘to do’ column can be seen as the visible tip of the iceberg. It was determined in advance that the analysts can only process two tasks at a time, the developers can only process four tasks at a time, and only one task can be put into production at a time. Those are the WIP (Work-In-Progress) limits.

Six tasks have been selected and prioritized: the first task to be processed is at the top of the column, in this case task A.

A little while later… Tasks A, B, C and D are done. Every team is at its maximum WIP limit. After consulting the entire team, the product owner decides to put P back in the backlog column to be able to replace it with R, which is now a higher priority – the limit of 6 tasks must never be exceeded.

The Kanban dashboard enables managers to quickly identify systemic bottlenecks in the workflow (a constantly full “Completed” sub-column is a sign), as well as accidental, or circumstantial sticking points. The goal of all actors should be to limit the length of the work cycle, i.e. the amount of time it takes for tasks to travel from left to right. Constantly monitoring cycle duration is a good indicator for management purposes.

Incident Management

Houston, we have a problem… We can’t put E into production! We’ve been trying for hours, and we can’t get it done!

It’s a major bottleneck. The developers have completed their tasks and have nothing to do, the same goes for the analysts. You might think that the developers could take on J and K, and the analysts could start on L and M while they wait for the production problem to be solved but that’s not the Kanban way. Kanban philosophy dictates that the WIP limit must not be exceeded, even if all tasks have been completed. The main goal is to achieve and maintain a constant flow, with regular deliveries. When an incident occurs, the priority is to get things back up to speed by removing the workflow block as quickly as possible.

Here, in this example, all of the people who can help with deployment must pitch in and lend a hand. Those who can’t help must do something else, but must not take on new tasks if they have reached their limit. They can do online courses, tidy up their desk, organize a foosball championship, or engage in other similarly productive activities. But they cannot, and I repeat: cannot exceed their WIP limit.

Express Lane

It is possible to create an express lane on a Kanban dashboard to be able to manage things like a critical bug discovered in a version that is already in production; or a security flaw, which is a good example of a situation requiring an immediate solution. That lane is strictly for real emergencies. A task on that lane means that all other tasks must be suspended in order to deal with the emergency task immediately. That is the one exception to the rule about not exceeding WIP limits.

Keep in Mind

One thing to remember is that the Kanban process is not static, nor is it perfect from the word go. It is a dynamic representation of a process that can be adapted and improved over time. It is a tool that visually reveals problems in a process and opens the door to improvements. Furthermore, Work In Progress limits are not absolutely set in stone; they can be overridden or adjusted in cases of force majeure. In short, Kanban is a truly flexible tool for workflow optimization.

There are, of course, many other things you can do, and more sophisticated ways of using Kanban, but that would take us beyond the scope of a general introduction.

—

⇨ “An Introduction to Kanban (1st part).”