Support Is Crucial

All tasks, each represented by a card, move from left to right across the columns. Additional information (e.g., who's responsible or the date the task was assigned) can also be documented on the cards.

Corresponding to the capacity of each station, each column is given a fixed WIP limit. The success of the Kanban method hinges on staying within these limits. The support of management is crucial in this respect because, without it, the benefits of the method would soon be drowned in a power struggle between the various interest groups. Only in very rare exceptions, which must be clearly defined beforehand, should the WIP limits be overstepped (e.g., to restart a halted process).

However, setting WIP limits has a certain amount of flexibility. One variation suitable for small teams simply limits the total number of cards that refer to an individual team member.

Next, tasks need to be added to the backlog column so they can begin their journey across the board. Tasks are gathered and prioritized at regular meetings between client and operations team. The time between meetings should be long enough that room becomes available for more projects but short enough that capacity is not wasted.

What Comes Next

In agile projects, prioritizing backlog candidates has proven to be challenging. Planning Poker [5] and other methods can help decide which tasks should go to the fore. Experience has shown that estimating the time and effort needed is not very efficient when it comes to IT operations because the complexity of IT infrastructures makes it necessary to involve diverse specialists (DBA, network architect, etc.) and the costs for coordination do not scale. A more pragmatic approach would be a weighted round robin between project leaders on the basis of their budgets. Additionally, cost of delay – what costs will arise if the task starts later – are a possible weighting characteristic.

These meetings need to be held regularly; a weekly cycle has proven useful. For one, the routine creates transparency, but more importantly, the WIP limits can be kept relatively small, allowing the teams to concentrate on individual tasks and minimizing cycle time, which together with the visualization of progress on the Kanban board, serves to create confidence in the team and method.

To strengthen confidence even more, finished tasks should be delivered regularly. In contrast to Scrum, the Kanban method does not include timeboxing, giving the Ops team more room for flexibility. In urgent cases, ad hoc delivery might be required. Teams that have reached a certain process maturity can even make this a rule in the form of continuous deployment.

Daily Communication

Communication plays an important role in the Kanban method, and the most important place for it is in the daily stand-up meeting. Its purpose is to uncover problems in the process and work together to find solutions. Above all, the members of the admin team should take part in the stand-up meetings, and it is also a good investment of time for project leaders. At larger, irregular intervals, an operations review, similar to the retrospective in Scrum, is helpful in achieving the goal of continually improving the entire project process. Consequently, it is vital that management also take part in the meetings.

In a comic book style, "One Day in Kanban Land" [6] vividly illustrates how these stand-up meetings promote continual improvement and give all participants the chance to make a contribution. Some excerpts from the story are shown in Figures 2 to 5.

At first, everything is running perfectly. The developers have already passed Project A on to Deployment, and Project B is already waiting for the only place in the Deployment column to become free. Normally, the developer team with free capacity would now pick up Project D, but its WIP limit prevents them from doing that (Figure 2).

Figure 2: A problem in deployment blocks the whole process. The developers' WIP limit prevents projects from constantly pouring in.

Does Kanban turn the developers into a bottleneck, although they have free capacity? No! The method reveals the true bottleneck, deployment. The workflow stagnates because of problems with Project A. Instead of complaining about the admins always holding things up, the developers invest their capacity more effectively in removing the blockage (Figure 3).

Figure 3: In this case, the developers can invest their capacity helping deployment, where the problem is.

The situation gets worse when the other development team finishes Project C (Figure 4). The project manager cannot enjoy the accomplishment for long because, instead of pushing more jobs into the traffic jam, projects must wait until the problem has been solved (Figure 5). In the end, Project A finally goes into successful production, and the people involved immediately take measures to prevent the same problem from occurring again.

Figure 4: The jam in front of deployment keeps growing.

Figure 5: As soon as the cause of the blockage has been removed, the whole process can start running again.

This example graphically illustrates how the Kanban method focuses attention on the weak links in the workflow and forces all who are involved to grapple with the problem.