Kanban (development)

Kanban is a process model for software development in which the number of parallel work, the Work in Progress ( WiP ), and hence of achieving faster turnaround times and problems - in particular bottlenecks - to be made quickly visible.

Roots and history

The Japanese word kanban originally means, signal card ' ( kan, signal ', ban, map ') and is a technology from the Toyota production system, can be reduced with the stocks and an even flow (Flow) to be produced in production. Although the Kanban in Information Technology (IT ) takes over the name, but does not attempt a direct transfer of certain techniques from the production to the IT. Rather, some basic principles of the Lean Production (, Lean Production '), and even more so the lean development (including Lean Product Development ), adopted and amended by the Theory of Constraints and the classic risk management. In particular, the ideas Don Reinertsen, who introduces different techniques of how to develop products in a much shorter time, play an important role in Kanban. As a " founder " of Kanban applies in the IT David Anderson, the concept presented in 2007 to the public for the first time.

Kanban practices

David Anderson describes six practices that integrate the company into the way they work, when they do Kanban:

• Visualize the flow of work: The value chain and the different process steps (eg, requirements definition, programming, documentation, testing, commissioning) is clearly visible visualized for all involved. For kanban board is used (usually a large white board ), on which the various stations are displayed as columns. The individual requirements ( it can tasks, features, user stories, Minimal Marketable Features (MMF ), etc.) nature are recorded on index cards or sticky notes and wander with time as the so-called ticket, the Kanban Board from left to right.
• Limit the amount commenced work: the number of tickets ( Work in Progress - WiP ) that can be processed simultaneously at a station is limited. For example, if the program works just two tickets, and is the limit for this station two, they may not accept a third ticket, even if the requirement definition could provide another. This creates a pull system in which each station picks up their work at the previous station, rather than simply handed over finished work to the next station.
• Miss and navigate the river: The members of a kanban process measure typical sizes such as lengths of queues, cycle time and throughput, in order to determine how well the work is organized, where you can improve something, and what promise can be given to the partners, you work for. This planning is facilitated and increased reliability.
• Make the rules for the process explicitly: To ensure that all participants in the process to know under what assumptions and laws to work, whenever possible, all rules that exist, made ​​explicit. These include, for example, a definition of "finished", meaning of the individual columns, answers to the questions: who is pulling when it pulls, how to choose the next ticket to be drawn from the set of existing tickets from, etc.
• Encourage leadership at all levels in the organization: Improvement can only work if all levels in the organization participate. It is particularly important that employees who directly perform the work, to show "Acts of Leadership" and contribute with concrete suggestions for improvement.
• Use models to identify opportunities for collaborative improvement: models are simplifications of the process. A popular model is, for example, the value of, river and waste from the " Lean IT ". Other models are based on the ideas of Deming or on the Theory of Constraints, on systems thinking or complexity theory. Models can help to achieve a better understanding of the process and to find experiments that lead to an improvement of the process.

The visualization and the limitation of the WiP is a simple means with which is quickly seen how quickly the tickets through the various stations and where to accumulate tickets. The bodies are piling up in front of those tickets while spare capacity is available at the following stations are referred to as bottlenecks. Through analysis of the Kanban board action can be taken again and again to achieve the most uniform possible flow (Flow). For example, the limits for individual stations can be changed, it can buffer are introduced ( especially against bottlenecks caused by only intermittently availability of resources ), the number of employees at the various stations can be changed, technical problems are eliminated, etc. This continuous improvement process (Japanese: Kaizen) is an essential component of Kanban.

Kanban Flight Levels - How Kanban fits into the company?

The core properties of Kanban are formulated quite broad and do not provide information about where in the corporate context embeds Kanban. Nevertheless, Kanban is often subject to the misconception that it was a more agile approach to team optimization. Kanban can be quite used to team level, however, it always has the entire value chain perspective. In order to provide better orientation where it can be used in the enterprise Kanban, Klaus Leopold developed the flight levels model.

• Flight Level 1 - Kanban for teams with uncoordinated inflow to the system: Flight Level 1 is characterized by a very easy start. Since the flow is not regulated to the system, there is a risk that the staff will be overloaded.
• Flight Level 2 - Kanban at the team level with coordinated inflow to the system: Due to the inflow regulation ensures that the team has just as much work as may enter into it. The disadvantage of Flight Level 2 is that it is a local optimization - companies are usually from several teams, all of which are required for generating value for the customer.
• Flight Level 3 - Kanban for the supply chain: the case of Flight Level 3 is not about the optimization of each team in a company, but the optimization of the overall value. Kanban is thus made ​​usable for multiple teams and / or departments in the organization.
• Flight Level 4 - Kanban for Portfolio: In most cases, there are several value chains (eg projects, products, customers, etc. ) in a company. On Flight Level 4 these different Undifferentiated value of a company to be optimized exactly. This flight level is therefore very close located at the business and corporate strategy.

Relative to other approaches in software development

Waterfall

Even if the stations often correspond exactly to a Kanban board the steps of the waterfall model, there is no necessary connection here. In particular Kanban is created that the individual tickets as quickly as possible through all the stations and are then released regularly. So Kanban works with small steps that are regularly reviewed and, if necessary corrected. However, Kanban can be to an existing waterfall model set up and can lead to make this gradually faster and more flexible.

The difference to the classic waterfall is in particular clear that in the waterfall, the entire product in parallel with the individual production goes through phases, in contrast, Kanban individual " pieces " or product requirements. Especially trying when kanban, the batch size, i.e. the amount of the same in the production system of input requirements, to be reduced.

Scrum

Kanban has many similarities with the agile management Scrum framework, however, is in no compelling relation to this. Neither one must first Scrum before introducing Kanban, yet both approaches close completely. In a way, Scrum can be regarded as one possible implementation of kanban. The main difference between the two approaches is that Scrum is a team- centered approach and Kanban primarily optimizes the value creation along the value chain.

After Henrik Kniberg the following similarities and differences between Scrum and Kanban can be identified.

Similarities between Kanban and Scrum

• Slim ( "lean" ) and agile
• Pull system
• Limit the WiP
• Rely on transparency to improve the process
• Focus on to deliver as quickly as possible and as frequently as possible release-capable software increments
• Based on self-organizing teams
• Require that requirements are broken down into small units
• In both the release plan is always optimized by empirical data is analyzed (team speed / throughput times )

Differences between Kanban and Scrum

Kaizen

Kanban contains as an integral part of a culture of continuous improvement process (CIP ), but gives no detailed practices for this. In many Kanban teams, but at least the following three practices have been established:

Value, Flow and Waste Elimination

Kanban is based on the principle of the Lean Thinking "Value Trumps Flow, Flow Trumps Waste Elimination" ( German: " value goes beyond River, goes over elimination of waste "). This means that although great emphasis is placed on ensuring to eliminate waste (eg unfinished tasks) and most uniform flow that in the first place, however, is always the value of the to-do tickets. Therefore, it may also be justified to break a kanban limit the short term to edit a very important ticket fast or detailed to specify features well in advance, although it is uncertain if / when they are actually realized.

Prioritization

In order to decide which stories / tasks / features are given at what time in the Kanban system, often after the delay cost scheme ( cost of delay) is prioritized, which goes back to Reinertsen / Smith. The idea behind this is that it not only costs money to develop new functionality, but that also costs arise because new functionality is introduced on the market with delay. Strictly speaking, these are not to "cost", but " not - made ​​profits," but ultimately it is running on the same thing ( opportunity costs). It will often be the case that a new functionality more causing more delay costs, the later it is on the market. The question then is, how expensive each additional day / week / month delay and how these costs behave in relation to the delay costs for other functionalities. However, there are cases in which multiple weeks / months / years incur no delay costs, but then abruptly rise at a date ( and even then may jeopardize the whole company ). For example, if an important fair, is presented at the usual new software a particular industry, takes place in November, but then the cost of delay from September after October very low ( or even zero ), from November to December is very high ( possibly so high that it is not economically sensible to the later date at all still release the software). Another example is the legal changes that apply from a certain date. If the software / hardware is not matched up to that date on the new rules, it may mean that the product should be taken off the market. On the other hand, it is not economical to use the amended rules already far in advance. Therefore, one would take into account in a kanban system, the average lead time for this functionality, schedule a sufficient buffer and provide the functionality productive just before the deadline.

Service Level Agreements ( SLA)

When a kanban system is installed, at the beginning of all tickets handled in the same rule. This means that those tickets that were first done from the first station, also first be processed by the next station. This approach is referred to as FIFO (First In - First Out ) refers. Often, however, it quickly becomes clear that tickets with different degrees of importance to be treated. It is therefore proposed in Kanban, different service types to define ( Classes of Service ). These are the common service types:

The service types are largely determined by the type of delay costs that are connected to the respective functionalities.

Applications

The areas of application of Kanban in IT are very diverse. Currently Kanban is mainly introduced in these cases:

• A team that is going on already agile (eg Scrum ), looking for further improvement. Kanban in this case represents a way more flexible to deal with the demands to shorten the lead times, often to release it and to work more focused.
• For classically oriented companies who act as according to the waterfall model, it often represents a major challenge to introduce an agile approach like Scrum because it requires quite far -reaching changes are needed. In this case, Kanban provides the advantage that changes can be introduced gradually, without this immediately makes major changes needed.
• For areas that are characterized by strong division of labor and specialization, Kanban is often more attractive than other agile methods, in which often required that the teams are composed of generalists and no knowledge areas are available. But this seems to be currently unrealistic for some areas.
• Because maintenance and IT operations are characterized by many interruptions and regular emergencies, here undisturbed work and iterations fixed length as in Scrum are hardly possible. Here Kanban may be a better choice, especially because the various service types fit well into Kanban of everyday life for system administrators and maintenance teams.

Variances

Unlike in automobile production, although it is unrealistic in the IT that all requirements have exactly the same size and can always be done in nearly the same time. Nevertheless, the objective in Kanban systems to come as close as possible to this ideal. A goal of kanban, therefore, is to reduce the variances. This is done by, for example, user stories into tasks as possible the same complexity are broken down.

Tracking

In kanban systems, various measurements ( " metrics " ) are recorded in order to collect empirical data for future improvements. These are the usual types of tracking in Kanban: