JugglingProjects

IT projects often fail, or at least cause a lot of headaches, for a number of reasons. First, a multitude of people approach the operative staff, each with their own ideas of how their individual projects should proceed; however, they all agree on one thing: Their project must be handled urgently. Projects are initiated by almost every part of an enterprise (e.g., marketing, product management, personnel), and, of course, no project is unimportant, so the people responsible expect the operations team to give their project top priority. When all projects are supposed to receive preferred treatment, the admin is left to solve the resulting unavoidable conflicts.

Second, internal projects necessary to ensure stable operation of the IT infrastructure and equip it for the future need attention. Backup systems must be scaled up, monitoring must keep up with an ever increasing number of checks and metrics, and the admin might have a long-hedged wish to introduce a configuration management utility like Puppet or Chef. However, a plan to reserve manpower for these internal tasks usually harvests about as much approval outside of IT as a proposal for a week-long department excursion.

Third, the situation is made more complicated by the large spectrum of responsibilities that fall under the "operations" roof. Layer models like ISO/OSI graphically document just how far the work of a network administrator is removed from that of a database manager. But the diversity is great even on the same layer; you only need to think of Apache and nginx, Varnish and Squid, MySQL and Oracle.

Finally, one of the most important differences between a software development team and an operations team is the amount of unplanned work. Every problem that interrupts normal operations means that one or more admins gets torn from their planned tasks. Unfortunately, such interruptions are frequent.

The Big Picture

All this has a large effect on daily processes. With insufficient staffing, the team must juggle a multitude of tasks, leading to more tasks begun than can be completed and personnel shifted to deal with unplanned incidents.

Under such circumstances, the admin needs an overview of all projects: who is working on which task, which projects are on course, and which projects are threatening to derail. Without this information, neither operations nor the company can plan ahead.

Often admins cannot even answer the basic question: What is my next job, and when can I start working on it? The answer usually comes from outside the team, which dampens job satisfaction and prevents the Ops team from utilizing its resources optimally.

The Agile Solution

More than 10 years ago, lack of capacity, no overview, insufficient planning certainty, and general dissatisfaction lead software developers to depart from the established waterfall model and look for project management methods that allowed more agility. In the waterfall model, a product goes through the phases of planning and development to production and delivery. Mistakes made in early stages are often noticed only later, when the cost of correcting them are high.

Agile processes, on the other hand, focus on product fragments that are easier to handle and go through specific stages, either consecutively or simultaneously, making it possible to make corrections or even radical changes when the costs are relatively low. The most prominent example of this model is the Scrum method.

As attractive as such approaches as Scrum may be, it is a part of human nature to resist profound changes. Quite often, it is this resistance in an organization, sometimes on the part of management, sometimes from colleagues, that causes well-meant initiatives to fail.

Approaches that do without a radical break with the past and instead introduce gradual steps to improvement have a better chance of success. Every step then can be assessed individually and generate confidence.

Scrum

Many who have implemented Scrum [1] in IT operations teams have discovered that some approaches lead to improvements, whereas others cause problems, often because the work of development teams and operations teams is similar, but not identical. The daily routine of an admin differs from that of a software developer in some decisive aspects. This becomes especially apparent in the DevOps approach, which considers the entire life cycle of an IT product from conception to end.

In the area of IT operations, the distribution of different roles is not clear enough for the Scum method; for example, who is the owner of a Postfix cluster? Also, admins are jealous of the planning horizons of their development colleagues. Shorter and shorter deployment cycles are not a suitable framework for inflexible sprints, which do not allow changes to the concept on the one hand and threaten to cause idle time with timeboxing [2] on the other.

Kanban

The Kanban method is another agile approach for modeling workflow processes. It is enjoying increasing popularity, especially in the area of IT, because it is easy to understand, easy to implement, and easily adapted to individual needs.

Kanban [3] is a term put together from the Japanese words "kan" (signal) and "ban" (card). It is the name of a principle that Taiichi Ohno used to organize the production processes at Toyota in 1947. He effectively oriented his concept on the central goals of lean manufacturing – namely, to reduce processing time, increase productivity, and create satisfaction and confidence.

Based on the insight that no method ever reaches perfection, the principle of continual improvement ("kaizen") also plays an important part in Kanban.

Pull and WIP

The core of the Kanban method is the pull system, in which the various stations in the process fill up their free capacity without external influence. At Toyota, signal cards (i.e., "Kanban") were used for this purpose, with which a station signaled that they had capacity available for processing the product of the previous station. The number of cards available corresponded to the total capacity of the respective station, so an overload could be ruled out. Thus the system introduced a work-in-progress (WIP) limit that was the decisive factor for the success of the Kanban principle.

An example that graphically demonstrates the pull system can be found in the Imperial Gardens in Tokyo. Upon entrance, each visitor is given a card with a request to return the card upon leaving the gardens. Entrance to the gardens is free, but it is only allowed as long as free cards are available. Because the cards are limited to a reasonable number, there can never be more visitors in the gardens than would allow for a pleasant stay.

Kanban has become known as an organizational method in the field of IT, above all, through David J. Anderson [4] and his book "Kanban: Successful Evolutionary Change for Your Technology Business." Anderson names the following core practices that characterize the Kanban method:

• Visualizing: The individual jobs in a project and their relationship to the steps of the process are made visible for everyone.
• Limiting work in progress: The pull system, together with a limit on the number of simultaneous tasks, prevents a station (e.g., the QS team in an IT context) from becoming overloaded.
• Managing flow: Informed decisions can be made on the basis of important metrics – for example, the processing time for a certain task, the number of unfinished tasks at a station, or the amount of time a task remains at a particular station.
• Making policies explicit: Agreements are formulated not only for the tasks at each station but for the criteria that must be met for the task to be considered complete and how the transitions between stations are to take place.
• Implementing feedback loops: Daily stand-up meetings on the team and colleague level, as well as cross-team operations reviews, ensure that everyone involved has influence on the continued improvement of the processes.
• Collaborative improvement, evolving experimentally: Scientific models, like the "theory of constraints," for example, and specific experiments help gain insights from which targeted measures for improving the processes can be derived.

Kanban in Practice

The nice thing about the Kanban principle is that only two things are needed to put it into practice: The explicit permission to introduce WIP limits and a board.

The board, whether a whiteboard, bulletin board, or virtual board in the form of a Kanban application, serves to visualize the workflow. On the Kanban board, each process step is represented by a column. Figure 1 shows a very simple example for such a Kanban board. A typical development project could be modeled with columns called "Backlog," "Analysis," "Development," "Test," "Change Preparation," "Production," and "Done." To the other extreme, very large projects might even use multiple, hierarchically staggered boards, whereby one reflects the overall status and others are used to manage individual parts of the project.

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).

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).

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.

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.

Kanban Compared

Like the other agile methods, Kanban is far better than the waterfall model. The advantages are that results can be seen more quickly, and much more reliable forecasts and commitments can be made.

The Kanban method fares well compared with Scrum, because it is easier to introduce, has no fixed roles, and requires very simple materials – a bulletin board is enough. Specialists, instead of generalists, are favored, which better reflects the reality of IT operations with network admins and DBAs. The method also allows much flexibility because iteration is optional (even if it is helpful in the beginning) and planning and deployment are independent of each other.

New projects can be introduced at any time without leading to overload (thanks to WIP limits), which increases job satisfaction. Because project size is not prescribed, you save the expense of preparing a cost estimate. One of the most important advantages over Scrum is no timeboxing, giving Ops teams the freedom necessary to make optimal use of their capacity.

Kanban Online

Just because a bulletin board is all you need to start working with the Kanban method doesn't mean you give up technology. The use of digital tools helps communication, especially in large teams or with multiple locations. Moreover, a large spectrum of tracking solutions includes the humble spreadsheet, as well as specialized Kanban applications.

Among these, Trello [7] distinguishes itself as a free product with a continually growing list of functions. Among other alternatives, Kanban Tool [8] and Agile Zen [9] are worth a closer look.

Further Information

Those who want to learn more about the Kanban method can read David J. Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business [10]. Anderson also publishes current information on the evolution of the Kanban method on his website [4].

Some adherents to the Kanban method have come together under the motto "YES WE KANBAN" as the Limited WIP Society [11]. Their website continually provides new information on the topic with a forum for exchanging experiences as well. And, if you want to stay on top of developments concerning Kanban while traveling, the "ITK Podcast" [12] is recommended.