Kanban

Agile de­vel­op­ment – for many people, this im­me­di­ately brings to mind the highly popular Scrum system, but this method is not the only way to use agile project man­age­ment in your company. Kanban is another method that has already proven to be be­ne­fi­cial in many areas. Does Kanban also make sense for your company or project? We’ll explain how the method works.

Kanban ori­gin­ally comes from Japan. Toyota developed the system in­tern­ally, back in 1947. This also explains how the method got its name: a com­pos­i­tion of the two Japanese syllables kan and ban which roughly trans­lates as ‘signal card’. In those days, the company used Kanban to optimise material flow. Toyota wanted to avoid bot­tle­necks as well as an excessive stock of pro­duc­tion 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 es­tab­lished itself in software de­vel­op­ment. At both Microsoft and Corbis (another one of Bill Gate’s companies), the idea of lean de­vel­op­ment – ori­gin­ally from the auto­mot­ive industry – was re­in­ter­preted and adapted in the 2000s. Rather than pro­duc­tion 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 im­prove­ments in many other areas of ap­plic­a­tion.

Those who use Kanban in their team most likely want to improve their workflow, and thereby increase pro­ductiv­ity 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 pro­cessing them together in a form of mul­ti­task­ing, each in­di­vidu­al 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 in­teg­rated 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 pri­or­it­isa­tion clearly on the Kanban board, “swimlanes” can be added. These are hor­isont­al 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 pri­or­it­ies.

This method of present­ing tasks increases work trans­par­ency in a very simple way. With the Kanban system, the team not only opts for a helpful visu­ali­ation of workflows but also a method that limits the number of orders: Before starting to use Kanban in pro­duc­tion, it is necessary to define how many orders team members should be able to process sim­ul­tan­eously. 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 pro­ponents of Kanban – mul­ti­task­ing 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 them­selves are often sub­divided 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 ca­pa­cit­ies to be dis­trib­uted even more ef­fi­ciently. Es­pe­cially 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 ca­pa­cit­ies to help solve the problem in the second station.

Besides the limit for sim­ul­tan­eous orders, other rules can be presented clearly on the Kanban board. This includes when an order can be marked as completed and ready for trans­ition to the next station. Moreover, it is important to note that these rules may change. After all, agile processes also involve regularly scru­tin­ising 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 sug­ges­tions: a daily Kanban meeting (like the daily Scrum), various topic-specific reviews, and other meetings.

Dialogue among col­leagues 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 im­prove­ments rather than or­gan­ising a big shift. This approach is often compared with the Japanese philo­sophy Kaizen. The theory – meanwhile adopted primarily in business man­age­ment – promotes the idea of con­tinu­ous im­prove­ment (Kaizen is Japanese for “change for the better”). However, there is no end goal. According to Kaizen, it is always possible to make changes.

Al­to­geth­er, six different Kanban practices can be iden­ti­fied:

1. Visu­al­isa­tion: The Kanban board is a visu­al­iz­a­tion of workflows. The design itself is re­l­at­ively flexible. However, it is important that stations are clear and the relevant limit is shown for each column.
2. Lim­it­a­tion: 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 in­ev­it­ably leads to a more efficient workflow.
3. Man­age­ment: During the work process, blockades and bot­tle­necks 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 dis­trib­ute ca­pa­cit­ies for the long term.
4. Reg­u­la­tion: Defined process rules are intended to make workflows clearer and more trans­par­ent. These rules include the setting of limits as well as de­term­in­ing when a task is con­sidered 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 pre­requis­ite for their im­prove­ment. 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 con­tinu­ous im­prove­ment.

Kanban can easily be in­teg­rated 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 straight­for­ward technique, but the visu­al­isa­tion of a Kanban board, trans­par­ency over processes, and clear lim­it­a­tion of mul­ti­task­ing are also very practical.

Kanban is not only popular for its evident use­ful­ness for teams, but also due to the method’s easy im­ple­ment­a­tion. 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 de­term­ined 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 stip­u­lates 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 in­di­vidu­als can use Kanban to organise their personal workflow more ef­fect­ively.

• Small teams: Small groups of co-workers often tend to organise them­selves according to agile prin­ciples in any case. In order to give more structure to work processes and thereby increase ef­fect­ive­ness, Kanban can easily be im­ple­men­ted here.
• Large companies: For large, es­tab­lished companies, it is far more difficult to integrate new processes. Par­tic­u­larly in these cases, Kanban is well-suited for starters. The easy and flexible method can gradually be adopted within the or­gan­isa­tion.
• In­di­vidu­als: Whether they are start-up founders or freel­an­cers, Kanban can also help in­di­vidu­als organise their tasks.

The scope with which Kanban is used within a company can be rep­res­en­ted by “flight levels”. Dr. Klaus Leopold, another Kanban pioneer, il­lus­trates where Kanban can support workflows using three different levels:

• Flight Level 1 – Op­er­a­tion­al level: At this altitude – the lowest – the team of spe­cial­ists can be found whose daily work centres around producing the product or providing the service. Of­ten­times, 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 pro­cessing 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 – Co­ordin­a­tion: The second level therefore concerns co­ordin­a­tion among teams. In Kanban, this is where it is ensured that all teams are pro­cessing tasks in the right order and are con­stantly being supplied with work. This prevents in­di­vidu­al teams from becoming either idle or over­strained.
• Flight Level 3 – Strategic portfolio man­age­ment: The third level is reached when not only a project is being co­ordin­ated with Kanban, but rather the whole portfolio is organised according to the agile method. It enables man­age­ment to decide when which projects are to start. This can improve workflows through­out the entire company.

After all, Kanban is so flexible that it can also be easily combined with other methods. A com­bin­a­tion of Kanban and Scrum is par­tic­u­larly popular. Scrum itself is a re­l­at­ively re­strict­ive system; the framework provides the team with detailed guidelines. Since Kanban is kept flexible in contrast, it can easily be in­teg­rated into the regular Scrum process.

However, there are a number of dif­fer­ences between the two methods: While Scrum places the team in the fore­ground, Kanban focuses on the pro­duc­tion process and the result for the customer. The two systems com­ple­ment each other in other respects: The highly frequent, fixed meetings that char­ac­ter­ise Scrum, among other aspects, are not spe­cific­ally required in Kanban, but they do fit in very well with the feedback element of the method.

The ad­vant­ages of Kanban have already been mentioned in de­scrib­ing the method: easy in­teg­ra­tion, constant im­prove­ment of workflows, and increased trans­par­ency. But there are also some aspects that deter teams: for example, it is ab­so­lutely 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 ca­pa­cit­ies can be real­loc­ated ac­cord­ingly. However, this is only possible if ca­pa­cit­ies can actually be swapped around. Team members must be able to work at different stations. Otherwise, blockages and over­strain­ing will occur for some co-workers, while others will become idle – precisely the opposite of what Kanban is intended to achieve.