Kanban (software development)

from Wikipedia, the free encyclopedia

Kanban is a method in software development in which the number of parallel work, the work in progress (WiP) , is limited and thus shorter processing times are achieved and problems - especially bottlenecks - are to be made visible quickly.

Roots and history

The Japanese word Kanban originally means ' signal card ' ( kan 'signal', ban 'card') and is a technology from the Toyota production system with which a steady flow is to be created in production and thus to reduce stocks. The focus is on the optimal flow of each individual product through production. Kanban in information technology (IT) adopts the name, but does not attempt a direct transfer of individual technologies from production to IT. Rather, some basic principles from lean production (' lean production '), and even more so from lean development (also lean product development ), are adopted and supplemented by the theory of constraints and classic risk management . In particular, the ideas of Don Reinertsen, who introduces various techniques for developing products in a much shorter time, play an important role in Kanban. The founder of Kanban in IT is David Anderson, who was previously involved in the development of Feature Driven Development and who published the first book on Kanban in 2010.

Kanban principles and practices

David Anderson outlined four core principles and six core practices that companies incorporate into the way they work when using Kanban:

Basic principles

GP1: Start with what you are currently doing

There are two things in this rationale. By starting what you are doing, you finish the current work before something new is started. The statement that Kanban can be easily introduced is also included here.

GP2: Agree that evolutionary change will be pursued

Further development is essential, but here improvements should mainly be achieved through small / evolutionary steps.

GP3: Initially respect existing processes / roles / responsibilities

Kanban can be introduced very easily, all existing roles, processes, etc. remain.

GP4: Encourage leadership to be shown at every level of the organization

Improvement can only work if all levels in the organization participate. It is particularly important that employees who do the work directly show "Acts of Leadership" and make specific suggestions for improvement.

Core Practices

KP1: Visualize the flow of work
The value chain with its various process steps (e.g. definition of requirements , programming , documentation , testing , commissioning ) is visualized in a clearly visible manner for all parties involved. A Kanban board (usually a large whiteboard ) is used for this, on which the different stations are displayed as columns. The individual requirements (it can be tasks , features , user stories , minimal marketable features (MMF), etc.) are recorded on index cards or sticky notes and, over time, wander through the Kanban board from left to right as so-called tickets.
KP2: Limit the amount of work started
The number of tickets ( Work in Progress - WiP) that can be processed at a station at the same time is limited. For example, if the programming is currently processing two tickets and the limit for this station is two, it cannot accept a third ticket, even if the requirements definition could provide another. This creates a pull system in which each station picks up its work from the previous station instead of simply handing over finished work to the next station.
KP3: Miss and steer the flow
The members of a Kanban process measure typical parameters such as queue length, cycle time and throughput to determine how well the work is organized, where there is still room for improvement and what promises can be made to the partners you work for. This makes planning easier and increases reliability.
KP4: Make the rules for the process explicit
In order to ensure that all those involved in the process know the assumptions and principles under which one is working, as many rules as possible are made explicit. These include B.
  • a definition of the term "done", similar to the definition of done in Scrum ,
  • Meaning of the individual columns,
  • Answers to the questions: who draws, when do you draw, how do you choose the next ticket to be drawn from the set of tickets available, etc.
KP5: Implement feedback cycles
The team (or the teams among themselves) gives each other feedback at set times.
Examples:
  • Retrospectives: reviewing collaboration
  • Stand-up meeting: discussing upcoming tasks / addressing blockages / coordinating flow
  • Operation reviews: The company's Kanban teams meet and share experiences
KP6: Use models to identify opportunities for collaborative improvement
Models are simplifications about the process. A popular model is e.g. B. that of value, flow and waste from “Lean IT”. Other models are based on Deming's ideas or on bottleneck theory , on systemic thinking or on complexity theory . Models can help to achieve a better understanding of the process and to find experiments that lead to an improvement in the process.

The visualization and the limitation of the WiP are simple means with which it is quickly visible how quickly the tickets pass through the various stations and where tickets are jammed. The places in front of which tickets pile up while there is free capacity at the following stations are known as bottlenecks . By analyzing the Kanban board, measures can be taken again and again in order to achieve the most even flow possible. For example, the limits for individual stations can be changed, buffers can be introduced (especially in front of bottlenecks that arise due to the temporary availability of resources), the number of employees at the various stations can be changed, technical problems can be eliminated, etc. This continuous Improvement process (Japanese: Kaizen ) is an essential part of Kanban.

Kanban Flight Levels - How does Kanban fit into the company?

The core properties of Kanban are formulated quite broadly and do not provide any information about where in the company context Kanban is embedded. Nevertheless, Kanban is often subject to the mistake that it is an agile approach to team optimization. Kanban can definitely be used at team level, but it always has the entire value chain in view. In order to provide a better orientation where in the company Kanban can be used, Klaus Leopold developed the Flight Levels model.

Flight Level 1 - Kanban for teams with an uncoordinated flow to the system
Flight Level 1 is characterized by a very easy start. Since the flow into the system is not regulated, there is a risk that the team will be overloaded.
Flight Level 2 - Kanban on team level with coordinated flow to the system
The flow regulation ensures that the team only gets as much work as it can complete. The disadvantage of Flight Level 2 is that it is a local optimization - companies are usually made up of multiple teams, all of which are needed to generate value for the customer.
Flight Level 3 - Kanban for the value chain
Flight Level 3 is not about optimizing individual teams in a company, but about optimizing overall value creation. Kanban is therefore made usable for several teams or departments in an organization.
Flight Level 4 - Kanban for the portfolio
In most cases there are several value chains (e.g. projects, products, customers, etc.) in a company. At Flight Level 4, it is precisely these different value added of a company that are optimized. This flight level is therefore very close to business and corporate strategy.

Relation to other approaches in software development

waterfall

Even if the stations on a Kanban board often correspond exactly to the steps of the waterfall model , there is no mandatory relationship here. In particular, Kanban is designed so that the individual tickets pass through all stations as quickly as possible and are then released on a regular basis. Kanban therefore works with small steps that are checked regularly and corrected again if necessary. However, Kanban can be based on an existing waterfall model and can gradually make it faster and more flexible.

The difference to the classic waterfall is particularly clear in that in the waterfall the entire product runs through the individual production phases in series, whereas with Kanban individual "workpieces" or product requirements. In particular, one tries with Kanban, the batch size , i. H. Reduce the number of requirements entered into the production system at the same time.

Scrum

Kanban has a lot in common with the agile management framework Scrum , but is not necessarily related to it. You don't have to use Scrum before you introduce Kanban, nor are both approaches completely mutually exclusive. In a way, Scrum can be seen as a possible implementation of Kanban. The main difference between the two approaches is that Scrum is a team-centered approach and Kanban primarily optimizes value generation along the value chain.

According to 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 WiP
  • rely on transparency to improve the process
  • focus on delivering releasable software increments as quickly as possible and as often as possible
  • are based on self-organizing teams
  • require requirements to be broken down into small units
  • In both the release plan is optimized again and again by evaluating empirical data (team speed / throughput times)

Differences between Kanban and Scrum

Kanban Scrum
Iterations are optional. There can be different cycles for planning, releases and process improvement. Iterations with the same length are required.
Commitments are optional. The team agreed to do a certain amount of work during the next iteration.
The cycle time is used as a basic metric for planning and process improvement. The team speed ( velocity ) is the basic metric for planning and process improvement.
Cross-functional teams are optional. Expert teams are allowed. Cross-functional teams are required.
No requirement on the size of requirements. Requirements must be divided up so that they can be dealt with within one iteration.
WiP is limited directly. WiP is limited indirectly (by the amount of requirements that fit into a sprint).
Estimates are optional. Estimates are mandatory.
New requirements can be given to the team at any time if capacities are free. No new requirements can be given to the team during an ongoing sprint.
Doesn't specify roles. Prescribes three roles ( Product Owner , Scrum Master , Team).
A Kanban board can be shared by multiple teams and / or individuals. A scrum board belongs to a single team.
A Kanban board is continuously updated. The scrum board is deleted and set up again after each sprint. The product backlog is continuously updated.
Prioritization is optional. Prescribes that all entries in the backlog must be prioritized.

Kaizen

Kanban contains a culture of the continuous improvement process (CIP) as an integral part , but does not specify any detailed practices for this. In many Kanban teams, however, at least the following three practices have become established:

Daily status meetings ( stand-up meetings )
The team meets daily (usually in the morning) in front of the Kanban board. The progress of the project since the last meeting is made clear on the basis of the tickets. In addition, problems are clarified and solutions are discussed. The meeting is, however, designed to be short (around 15 minutes) so that longer discussions are outsourced.
Operations Reviews
So-called operations reviews are held in Kanban . These are meetings that serve continuous improvement. They show similarities to retrospectives, as they are known from other agile methods. However, operations reviews take place irregularly. And they strive for a high level of objectivity by making more reference to the collected data from the past. We also try to have participants from the entire organization (including management), and not just the development team, take part in these meetings.
Root cause analysis
Problems should not be managed in Kanban, but rather resolved. This is mainly done by the fact that errors quickly become apparent through the Kanban board, for example because work is jammed, individual stations are underutilized, throughput times are too long or individual tickets constantly remain at the same station. The causes of errors should be found quickly and eliminated quickly (if necessary, through the cooperation of the entire team).

Value, flow and waste elimination

Kanban is based on the principle of Lean Thinking “ Value Trumps Flow, Flow Trumps Waste Elimination ” (German: “Value goes over flow, flow goes over the elimination of waste”). This means that while great emphasis is placed on eliminating waste (for example unfinished tasks) and ensuring a smooth flow as possible, the value of the tickets to be done always comes first. Therefore, it can also be justified to break a Kanban limit at short notice in order to process a very important ticket more quickly or to specify features in detail in advance, although it is uncertain whether / when they will actually be implemented.

prioritization

In order to decide which stories / tasks / features are to be added to the Kanban system at what point in time, priority is often given to the cost of delay scheme , which goes back to Reinertsen / Smith . The idea behind this is that not only does it cost money to develop new functionality, but it also incurs costs because new functionality is delayed on the market. Strictly speaking, these are not “costs”, but waiver costs . It will often be the case that a new functionality causes more delay costs the later it is on the market. The question then is how expensive each additional day / week / month delay is and how these costs relate to the delay costs for other functionalities. However, there are also cases in which there are no delay costs for several weeks / months / years, but these suddenly increase on one date (and then even endanger the entire company). For example, if an important trade fair, where new software from a particular industry is usually presented, takes place in November, then the delay costs are very low (or even zero) from September to October, but very high from November to December (possibly so high that it does not make economic sense to release the software at all at a later date). Another example are legal changes that apply from a certain key date. If the software / hardware has not been adapted to the new regulations by this deadline, it may mean that the product has to be withdrawn from the market. On the other hand, it is not economical to implement the changed regulations well in advance. Therefore, in a Kanban system, one would take into account the average lead time for this functionality, plan a sufficient buffer and put the functionality into production shortly before the key date.

Service Level Agreements (SLA)

When a Kanban system is installed, all tickets are usually treated the same at the beginning. This means that the tickets that were processed first by the first station are also processed first by the next station. This procedure is called FIFO ( First In - First Out ). However, it often quickly becomes clear that tickets are treated with different levels of importance. This is why Kanban suggests defining different types of service ( classes of service ). These are the most common types of service:

Accelerated ( Expedite )
These tickets must be treated with high priority. Depending on the domain, it may be necessary for the entire team to stop its current activity in order to process this ticket. This is the case, for example, if servers for an important Internet service fail and the service can no longer be reached. The capacity limits of the individual stations are often temporarily overridden for these types of service.
Fixed date ( Fixed Date )
If a functionality is only required on a fixed date (for example because a change in the law then takes effect), the corresponding tickets are channeled through the Kanban system in such a way that the functionality goes live shortly before this deadline.
Vague ( intangible )
If the business value and / or the cost of delay for a new functionality is vague, the corresponding tickets will be given secondary priority. For example, the team can define that only one such ticket may be in the system at any given time .
Standard ( standard )
All other tickets are in the standard class of service. As a rule, you will be treated according to FIFO. However, the team can also define other / additional rules.

The service types are largely determined by the type of delay costs associated with the respective functionalities.

Areas of application

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

  • A team that is already adopting an agile approach (e.g. using Scrum) is looking for further opportunities for improvement. Kanban represents an opportunity to deal with the requirements even more flexibly, to shorten throughput times, to release more frequently and to work more focused.
  • For classically oriented companies that use the waterfall model, for example, it is often too great a challenge to introduce an agile approach such as Scrum, because this requires far-reaching changes. In this case, Kanban offers the advantage that changes can be introduced gradually without making major changes immediately.
  • For areas that are characterized by a strong division of labor and specialization, Kanban is often more attractive than other agile methods, in which it is often required that the teams consist of generalists and that there are no islands of knowledge. However, this currently seems unrealistic for some areas.
  • Because maintenance and IT operations are characterized by many interruptions and regular emergencies, undisturbed work and fixed-length iterations as in Scrum are hardly possible. Here, Kanban can be a better choice, especially because the different types of service in Kanban fit well with the day-to-day lives of system administrators and maintenance teams.

Variances

Unlike in automobile production, it is unrealistic in IT that all requirements are exactly the same size or can always be completed in almost the same time. Nevertheless, the aim in Kanban systems is to come as close as possible to this ideal. One goal of Kanban is therefore to reduce the variances. This is done, for example, by breaking down user stories into tasks of the same complexity as possible.

Tracking

Various measures ( metrics ) are recorded in Kanban systems in order to collect empirical data for future improvements. These are the common types of tracking in Kanban:

Cumulative Flow Diagram (CFD)
This diagram can be viewed as a further development of the burnup diagrams used in XP and (partially) Scrum. However, a CFD not only shows when and how many tasks are being done, but it also visualizes the statuses at all stations of the Kanban system (programming, documentation, testing, etc.). It quickly shows where the bottlenecks are.
Work in Progress (WiP)
This very simple diagram shows how the number of tasks and stories that are in the Kanban system at the same time is developing. A steadily rising curve usually signals a problem (for example more and more blocked tickets).
Throughput
A simple line diagram shows how many tickets were dealt with each week.
Error rate
This graph controls how the number of bugs develops over time. Because Kanban is geared towards short throughput times and a basic assumption is that short throughput times can only be achieved through high quality, an important goal of Kanban is always to reduce the error rate.

literature

  • David J. Anderson: Kanban. Evolutionary change management for IT organizations . dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-730-4 (English: Kanban. Successful Evolutionary Change for Your Technology Business .).
  • Klaus Leopold, Siegfried Kaltenecker: Kanban in IT. Create a culture of continuous improvement . 3rd edition (1st edition 2012). Hanser Verlag, Munich 2018, ISBN 978-3-446-45360-9 .
  • Jim Benson, Tonianne DeMaria Barry: Personal Kanban. Visualization and planning of tasks, projects and appointments with the Kanban board . dpunkt.verlag, Heidelberg 2013, ISBN 978-3-89864-822-6 (English: Personal Kanban. Mapping Work, Navigating Life .).
  • Mike Burrows: Kanban. Understand, introduce, apply . dpunkt.verlag, Heidelberg 2015, ISBN 978-3-86490-253-6 (English: Kanban from the Inside .).
  • Klaus Leopold: Kanban in Practice. From team focus to value creation . Hanser Verlag, Munich 2017, ISBN 978-3-446-44343-3 .
  • David J. Anderson, Andy Carmichael: The essence of Kanban compact . dpunkt.verlag, Heidelberg 2018, ISBN 978-3-86490-531-5 (English: Essential Kanban Condensed .).
  • Florian Eisenberg: Kanban more than just notes. How the methods give you real added value . Hanser Verlag, Munich 2018, ISBN 978-3-446-45672-3 .
  • David J. Anderson, Alexei Zheglov: Fit for Purpose. How companies find, satisfy & retain customers . dpunkt.verlag, Heidelberg 2019, ISBN 978-3-86490-579-7 (English: Fit for Purpose. How Modern Businesses Find, Satisfy, & Keep Customers .).
  • Donald G. Reinertsen: The Principles of Product Development Flow: Second Generation Lean Product Development . Celeritas Publishing, Redondo Beach CA 2009, ISBN 978-1-935401-00-1 .
  • Preston G. Smith, Donald G. Reinertsen: Developing Products in Half the Time. New Rules, New Tools . Van Nostrand Reinhold, New York 1998, ISBN 0-442-02548-3 .
  • Corey Ladas: Scrumban - Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press, Seattle 2008, ISBN 978-0-578-00214-9 .

Web links

Individual evidence

  1. ^ D. Anderson: Agile Management for Software Engineering - Applying the Theory of Constraints for Business Results . Prentice Hall, 2004, ISBN 0-13-142460-2
  2. ↑ Biography David J. Anderson. (No longer available online.) April 12, 2004, archived from the original on January 10, 2010 ; accessed on May 20, 2020 (English).
  3. ↑ Burrows, Mike: Kanban: Understand, Introduce, Apply . Heidelberg 2015, ISBN 978-3-86490-253-6 .
  4. ↑ Kanban and its flight levels ( Memento from February 3, 2014 in the Internet Archive )
  5. ↑ Henrik Kniberg: Kanban vs Scrum. (PDF; 2.4 MB) June 29, 2009, accessed on January 24, 2014 (English).