Kanban

Agile development – for many people, this immediately brings to mind the highly popular Scrum system, but this method is not the only way to use agile project management in your company. Kanban is another method that has already proven to be beneficial in many areas. Does Kanban also make sense for your company or project? We’ll explain how the method works.

Kanban originally comes from Japan. Toyota developed the system internally, back in 1947. This also explains how the method got its name: a composition of the two Japanese syllables kan and ban which roughly translates as ‘signal card’. In those days, the company used Kanban to optimise material flow. Toyota wanted to avoid bottlenecks as well as an excessive stock of production materials at the same time. The result of these efforts is now also referred to as the pull method, as supplies are only ordered once stocks are coming to an end.

Based on this, the method also established itself in software development. At both Microsoft and Corbis (another one of Bill Gate’s companies), the idea of lean development – originally from the automotive industry – was reinterpreted and adapted in the 2000s. Rather than production materials, this time it involved going about tasks according to the pull method: Only once a team has processed tasks are more pulled from the backlog. This system also enables workflow improvements in many other areas of application.

Those who use Kanban in their team most likely want to improve their workflow, and thereby increase productivity as well as the quality of the end product. Kanban is an agile method and can be used to make workflows much more flexible. Tasks are divided into small steps and processed one after the other. There is also a fitting motto in Kanban that sums up this idea nicely: “Stop starting – start finishing!” Instead of starting a whole load of tasks and processing them together in a form of multitasking, each individual step should be finished first, before moving onto the next.

It’s quite easy to adjust to the new system. In contrast to other methods, Kanban can simply be integrated into existing workflows. This also makes it very open, and it is possible to apply other methods like Scrum in addition to Kanban.

In day-to-day work, sometimes certain tasks are more important than others. In order to show this prioritisation clearly on the Kanban board, “swimlanes” can be added. These are horisontal lines that partition the work-in-progress section. For example, the team can add all orders into an upper section (a fast lane) that have to be processed more quickly than others, and other less time-critical orders below. This provides each team member with a quick overview of current priorities.

This method of presenting tasks increases work transparency in a very simple way. With the Kanban system, the team not only opts for a helpful visualiation of workflows but also a method that limits the number of orders: Before starting to use Kanban in production, it is necessary to define how many orders team members should be able to process simultaneously. While there is no limit for the two outer columns, each inner column has its own maximum number. For instance, a team may only be able to process two cards per step at the same time. This is because – according to proponents of Kanban – multitasking tends to lead to delays.

Rather than pushing tasks from one step to the next, as is often the case, Kanban follows the pull method. In other words, the task is “pulled” from the previous column on the left when, and only when, the team members has capacity for a new task. This also means that the columns themselves are often subdivided into halves: on the one side are tasks that are currently being processed, and on the other are tasks than can move onto the next step.

Splitting the columns in this way enables capacities to be distributed even more efficiently. Especially when a task involves multiple steps before it is finished, otherwise jams can occur. If the first station works quickly but a problem arises in the second step, the team members from the first station should not carry on working, according to Kanban. Instead, they should use the freed-up capacities to help solve the problem in the second station.

Besides the limit for simultaneous orders, other rules can be presented clearly on the Kanban board. This includes when an order can be marked as completed and ready for transition to the next station. Moreover, it is important to note that these rules may change. After all, agile processes also involve regularly scrutinising and adjusting these rules!

To improve the workflow over the long term, it is necessary to exchange feedback. The Kanban method provides for regular meetings (known as cadences), but does not directly stipulate when or how often these should be. Instead, Kanban pioneer David J. Anderson offers some suggestions: a daily Kanban meeting (like the daily Scrum), various topic-specific reviews, and other meetings.

Dialogue among colleagues fits in with the general theme of Kanban: It is always about improving the workflow and product. Based on the actual situation, the team should gradually implement new improvements rather than organising a big shift. This approach is often compared with the Japanese philosophy Kaizen. The theory – meanwhile adopted primarily in business management – promotes the idea of continuous improvement (Kaizen is Japanese for “change for the better”). However, there is no end goal. According to Kaizen, it is always possible to make changes.

Altogether, six different Kanban practices can be identified:

1. Visualisation: The Kanban board is a visualization of workflows. The design itself is relatively flexible. However, it is important that stations are clear and the relevant limit is shown for each column.
2. Limitation: Each column may only contain a maximum number of orders. Only once an order card has moved right is the team able to take a new card from the left. This inevitably leads to a more efficient workflow.
3. Management: During the work process, blockades and bottlenecks can emerge. In these kinds of situation, it is necessary to focus the team on clearing these obstacles. Apart from that, observing the workflow can help to correctly distribute capacities for the long term.
4. Regulation: Defined process rules are intended to make workflows clearer and more transparent. These rules include the setting of limits as well as determining when a task is considered completed. Process rules must also be a visual and mutable part of the Kanban board.
5. Feedback: Feedback forms a necessary component of workflows and is a prerequisite for their improvement. Regular meetings (known as cadences) should be held for this reason. In contrast to Scrum, Kanban does not provide a strict framework for these meetings.
6. Kaizen: Processes within a team should always be a work in progress, as according to the theory no optimum can be achieved. Instead, it is important to strive for continuous improvement.

Kanban can easily be integrated into any team structure – and some companies are likely to already be working on a (trimmed) version of Kanban, without realising it. After all, the pull method is a highly straightforward technique, but the visualisation of a Kanban board, transparency over processes, and clear limitation of multitasking are also very practical.

Kanban is not only popular for its evident usefulness for teams, but also due to the method’s easy implementation. The barriers to entry are very low; a team or company must only perform a few initial changes before applying Kanban: First of all, a Kanban board is needed that can be adapted over time, as well as the clear decision to use the pull method. All the details can – and should – be determined by the team itself: What process rules will we set down? What limits will we place? What will our Kanban board look like?

In general, Kanban is a very open system that stipulates barely any rules at all. There are neither fixed schedules nor specific roles, unlike in the Scrum system. This means Kanban can be adapted to almost any situation. This applies to large and small teams alike; even individuals can use Kanban to organise their personal workflow more effectively.

• Small teams: Small groups of co-workers often tend to organise themselves according to agile principles in any case. In order to give more structure to work processes and thereby increase effectiveness, Kanban can easily be implemented here.
• Large companies: For large, established companies, it is far more difficult to integrate new processes. Particularly in these cases, Kanban is well-suited for starters. The easy and flexible method can gradually be adopted within the organisation.
• Individuals: Whether they are start-up founders or freelancers, Kanban can also help individuals organise their tasks.

The scope with which Kanban is used within a company can be represented by “flight levels”. Dr. Klaus Leopold, another Kanban pioneer, illustrates where Kanban can support workflows using three different levels:

• Flight Level 1 – Operational level: At this altitude – the lowest – the team of specialists can be found whose daily work centres around producing the product or providing the service. Oftentimes, these teams also only create a component of an overall product. In turn, this means that they only receive tasks as packages, which they need to subdivide into smaller subtasks before processing them. However, if only one team in the company works according to the Kanban system, problems can arise with other groups that pursue a different, non-agile method, such as the waterfall model.
• Flight Level 2 – Coordination: The second level therefore concerns coordination among teams. In Kanban, this is where it is ensured that all teams are processing tasks in the right order and are constantly being supplied with work. This prevents individual teams from becoming either idle or overstrained.
• Flight Level 3 – Strategic portfolio management: The third level is reached when not only a project is being coordinated with Kanban, but rather the whole portfolio is organised according to the agile method. It enables management to decide when which projects are to start. This can improve workflows throughout the entire company.

After all, Kanban is so flexible that it can also be easily combined with other methods. A combination of Kanban and Scrum is particularly popular. Scrum itself is a relatively restrictive system; the framework provides the team with detailed guidelines. Since Kanban is kept flexible in contrast, it can easily be integrated into the regular Scrum process.

However, there are a number of differences between the two methods: While Scrum places the team in the foreground, Kanban focuses on the production process and the result for the customer. The two systems complement each other in other respects: The highly frequent, fixed meetings that characterise Scrum, among other aspects, are not specifically required in Kanban, but they do fit in very well with the feedback element of the method.

The advantages of Kanban have already been mentioned in describing the method: easy integration, constant improvement of workflows, and increased transparency. But there are also some aspects that deter teams: for example, it is absolutely necessary that the work can actually be divided into steps. If this is not the case, the whole system won’t make any sense.

Another reason why this method is not the right choice for every team stems, in fact, from an advantage of the system. The work-in-progress limits ensure that problems at a station quickly become visible and capacities can be reallocated accordingly. However, this is only possible if capacities can actually be swapped around. Team members must be able to work at different stations. Otherwise, blockages and overstraining will occur for some co-workers, while others will become idle – precisely the opposite of what Kanban is intended to achieve.