Kanban Kompakt

Das Kanban-Prinzip ist inspiriert vom Toyota-Produktionssystem (TPS), welches der Prozesssteuerung in der Fertigung dient. Mit Karten signalisiert man im TPS dem jeweils vorgelagerten Produktionsbereich, was in welchen Mengen produziert werden soll. Die so entstehende Just-in-time-Produktion stellt nur genau das her, was wirklich gebraucht wird.

Genau dieses Prinzip lässt sich auch in der Software-Entwicklung anwenden. David Anderson übertrug dieses Konzept auf den Bereich der Software-Entwicklung. Er integrierte die Grundidee von Kanban mit grundlegenden Prinzipien aus sowohl der Lean Production als auch dem Lean Product Development und ergänzte diese durch die Theory-of-Constraints sowie das klassische Risikomanagement.

"People ask me: What is the difference between lean and kanban? Answer: lean is a destination; kanban is means to get there."
– David J. Anderson

Das evolutionäre Change Management war geboren, und David J. Anderson formulierte folgende fundamentale Prinzipien:

• Dort beginnen, wo man sich gerade befindet.
• Inkrementelle, evolutionäre Veränderungen anstreben.
• Auf bestehenden Rollen, Abläufen und Prozessen aufsetzen und diese respektieren.
• Leadership auf allen Ebenen in der Organisation fördern.

„Evolutionär“ heißt: Die Einführung von Kanban krempelt die bestehende Arbeitsweise nicht um. Existierende Prozesse und Rollen innerhalb der Organisation, des Projekts oder Teams bleiben erhalten, und es werden auch keine neuen Verantwortlichkeiten hinzugefügt. Man vereinbart jedoch, permanent kleine Verbesserungen an der bestehenden Arbeitsweise vorzunehmen – und das überall.

Kanban beginnt also stets beim Status quo und hat kein Ziel, außer dem kontinuierlichen Wandel zum Besseren. Kanban ist immer auf wirtschaftliche Wertschöpfung ausgerichtet, aber verliert den Menschen nicht aus den Augen. Denn nicht Prozesse, sondern Menschen treiben letztendlich die stetigen Verbesserungen voran. Kanban-Teams halten sich dabei an folgende grundlegenden Prinzipien:

• Visualisierung, indem die laufende Arbeit sichtbar gemacht wird.
• Limitierung der laufenden Arbeiten, indem die Anzahl offener Pakete pro Prozessschritt beschränkt wird, um Engpässe erkennbar zu machen.
• Steuerung des Arbeitsflusses und Messung von Kennzahlen, zum Beispiel der Durchlaufzeiten, um anhand der Ergebnisse eine Optimierung des Durchsatzes durchführen.
• Formulierung expliziter Regeln für Prozesse, denn nur so können Fehler erfasst und objektiv bewertet werden.
• Kontinuierliche Verbesserung mittels bewährter Modelle und wissenschaftlicher Methoden

 

Zentrales Element der Visualisierung des Arbeitsflusses ist ein Kanban-Board. Hierbei kann es sich um ein klassisches Whiteboard mit Karten oder Software handeln.

Auf einem Kanban-Board werden Aufgaben in Form von Karten angebracht. Ein Kanban-Board ist in Spalten (Lanes) unterteilt, welche den Arbeitsfluss visualisieren. Ausstehende Aufgaben werden in die linke Spalte (To Do, auch: Backlog) gegeben. Die Lanes bilden die Schritte innerhalb eines Prozess ab, Karten wandern im Laufe ihrer Fertigstellung also von ganz links nach ganz rechts.

Die Anzahl der ausstehenden Arbeiten pro Spalte werden in Kanban eingeschränkt: Das Work in Progress-Limit (WIP-Limit) basiert auf der einfachen Überlegung, dass eine hunderprozentig abgeschlossene Arbeit sinnvoller als zehn angefangene, aber nur zu zehn Prozent fertige, Arbeiten ist. Mit zunehmender Zahl angefangener Arbeiten erhöhen sich die Durchlaufzeiten. Ist also das WIP-Limit einer Station bei maximal zwei, und es werden gerade zwei Aufgaben bearbeitet, darf keine dritte Arbeit angenommen werden, selbst wenn die vorigen Stationen diese bereitstellen könnte.

In Kanban werden erledigte Arbeiten nicht zum nächsten Berarbeiter weitergereicht (Push-Prinzip). Jeder Bearbeiter holt sich seine Arbeit (Pull-Prinzip) vom Vorgänger, sobald er bereit für weitere Arbeiten ist. Durch diese Pull-Dynamik entsteht ein Arbeitsfluss (Flow). Etwaige Engpässe sind sofort ersichtlich: Ist ein Bereich ausgelastet, staut sich die Arbeit, und der Flaschenhals wird auf dem Board sichtbar.

Installiert man ein Kanban-System, besitzen alle Arbeiten die gleiche Priorität. Im Alltag funktioniert so etwas nicht: Sicherheitsprobleme, Ausfälle und andere unvorhergesehene Ereignisse können die Geschäftsfähigkeit eines Unternehmens beeinflussen. Kanban setzt hier Serviceklassen ein, um Aufgaben nach Auswirkungen, Risiken und Kosten zu bewerten und verlässliche Aussagen gegenüber Kunden bezüglich zu erbringender Leistungen zu treffen – die Basis für SLAs (Service Level Agreements).

Um eine Arbeit einer Serviceklasse zuordnen zu können, verwendet man häufig das Prinzip der Verzögerungskosten (Cost of Delay), das auf Reinertsen/Smith zurückgeht. Pro Serviceklasse erhält man so objektiv nachvollziehbaren Risikoinformationen zu etwaigen ökonomischen Auswirkungen für den Fall, dass eine Arbeit nicht oder erst verspätet fertiggestellt werden sollte. Die Idee des Cost of Delay-Prinzips ist, dass nicht nur die Entwicklung neuer Funktionalität Kosten verursacht, sondern auch Kosten dadurch entstehen, dass neue Funktionalität erst mit Verzögerung auf den Markt gebracht wird.

Deshalb wird in Kanban vorgeschlagen, verschiedene Service-Arten (Classes of Service) zu definieren. Gängige Serviceklassen sind „beschleunigt“, „fester Liefertermin“, „Standard“ und „unbestimmbare Kosten“.

 

Mittels Begrenzungen der Zahl der Tickets pro Serviceklasse, lässt sich die richtige Zuteilung von Arbeiten fördern. Beispielsweise kann festgelegt werden, dass innerhalb des Systems maximal fünf Prozent der Tickets „Expedite“ und zehn „Fixed“, maximal jedoch eines „Intangible“ sein darf.

Dies oben aufgeführten Klassen sind lediglich Beipsiele; die Zeit-Auswirkungs-Zusammenhänge – und damit die Basis von Serviceklassen – sind in jeder Organisation individuell. Serviceklassen beruhen stets auf historischen Messdaten oder auf eigenen qualifizierten Schätzungen!

Mit der Formulierung von von expliziten Prozessregeln schafft man eine gemeinsame objektive Basis für alle Beteiligten, welche genau definiert, unter welchen Annahmen oder Gesetzmäßigkeiten gearbeitet wird. Ziel ist es, wo immer möglich, Regeln im Arbeitsfluss explizit zu formulieren. Beispiele dafür sind unter anderem: die Definition, wann eine Aufgabe fertig, also „Done“ ist, die Bedeutung der einzelnen Spalten, wer pullt wann usw.

Die Summe aus expliziten Regeln gepaart mit Metriken bildet somit die Grundlage für Kaizen, den Prozess der kontinuierlichen Verbesserung.

Kanban ist transparent. Auf Engpässe kann umgehend reagiert werden. Mithilfe von messbaren Kennzahlen lassen sich die Gründe für aufgetretene Engpässe identifizieren und beheben. Durch kleine, sanfte Änderungen am Vorgehen optimiert man den Prozess stetig. Alle Optimierungen basieren auf bewährten Methoden und werden nicht nach Bauchgefühl durchgeführt.

Als Basis der Optimierungen müssen Teams laufend Messungen der Arbeit durchführen. Messungen wie Durchlaufzeit, Durchsatz und Flusseffizienz sind gängige Beispiele. Gemessen wird in Kanban jedoch stets das System, niemals die Leis­tung einzelner Mitarbeiter.

Metriken in Kanban
Metriken sind in der Arbeit mit Kanban ein wichtiges Instrument. Nur so kann man Veränderun­gen und Verbesserungen in den Prozessen eines Teams verlässlich nachvollziehen. Die Messung der Leistung eines des Systems hat immer zum Ziel, zu sehen, ob das System so arbeitet, wie erwartet, wo Verbesserungspotential herrscht und ob Verbesserungen greifen. Empfehlenswerte Basismessungen sind Durchlaufzeit, Durchsatz und Flusseffizienz eines Prozesses. Gängige Metriken dafür sind unter anderem das Cumula­tive Flow Diagramm sowie das Tracking und Spektralanalysen von Lead- und Durchlaufzeiten (Cycle Times).

Elimination von Verschwendung
Ein beliebtes Modell, welches Kanban-Teams beim Verbessern und bei der Optimierung unterstützt, ist das von Wert, Fluss und Verschwendung aus der „Lean IT“. Der Fokus liegt bei Reduktion von Verschwendung (Waste) im Arbeitsfluss. Als Verschwendung werden alle Aufwendungen betrachtet, die dem Kunden keinen Mehrwert bieten und für die dieser nicht bereit wäre zu zahlen.

"Value trumps flow, flow trumps waste elimination, eliminate waste to improve efficiency."
– David J. Anderson

Wie lassen sich Engpässe beseitigen?
Mit der Theory of Constraints nach Goldratt / Cox ist Kanban-Teams eine Methode zur Optimierung des Arbeitsflusses gegeben. Diese geht von der Erkenntnis aus der Systemtheorie hervor, welche besagt, dass der Durchsatz eines Systems ausschließlich von einem begrenzenden Faktor bestimmt wird. Das bedeutet, dass die Spalte im Kanban-Board, deren Bearbeitung am längsten dauert, den Gesamtdurchsatz des Systems vorgibt.

Die Beseitigung von Engpässen lässt sich im wesentlichen in fünf Fokussierungsschritten ausführen:

1. Identifiziere den Engpass.
2. Nutze den Engpass maximal aus.
3. Optimiere den Prozess auf die Ausnutzung des Engpasses.
4. Beseitige den Engpass.
5. Fange wieder bei Schritt 1 an.

Ziel ist stets der maximale Durchsatz der gesamten Wertschöpfungskette, also des Produktionsprozesses. Bevor wir spezifische Verbesserungsmethoden anwenden, sollten wir uns die Frage stellen, warum die Situation so ist, wie sie ist. Die Ursachenanalyse ist beispielsweise dabei ein Instrument, um die Gründe zu identifizieren.

Die Kanban Flight Levels nach Klaus Leopold sind ein Modell, das die möglichen Anwendungsbereiche bzw. den Anwendungsumfang von Kanban beschreibt. Flight Levels sind ein Weg, um das Potential von Kanban aufzuzeigen und zu klären, wo eine Organisation optimalerweise mit Kanban eine Change Initiative ansetzt.

Man unterscheidet zwischen vier Flight Levels:

Auf der ersten Ebene (Flight Level 1) setzt man Kanban in kleiner Organisationseinheit wie einem Team oder einer Abteilung ein. Ein Beispiel können cross-funktionale Teams aus Spezialisten sein, welche gemeinsam an Teilbereichen eines großen Gesamtsystems arbeiten. Charakteristisch ist, dass es keine Koordination der ankommenden Aufgaben gibt – also Stakeholder ihre Aufgaben nicht untereinander priorisieren. Innerhalb des Teams lässt sich der Prozess kontinuierlich verbessern, die Effizienz des Gesamtsystems ist jedoch limitiert.

Flight Level 2 führt auf dieser „Flugebene“ die Koordination von Input mithilfe von Queue Replenishment Meetings ein. In diesen Meetings priorisieren Stakeholder ihre Aufgaben gegeneinander und lernen, dass ein Team oder eine Organisationseinheit keine Black Box ist, in welche nach Belieben Arbeit hineingekippt werden kann, und auf der anderen Seite kommt das Gewünschte heraus. So werden mehr von den richtigen Aufgaben bearbeitet, und die Gesamteffizienz kann steigen.

Flight Level 3 optimiert nicht mehr die einzelnen Teams, sondern ihre Zusammenarbeit. Das Hauptaugenmerk richtet sich von nun an auf das Verbessern des Wertstroms, denn einen Wert für den Kunden zu schaffen ist wichtiger als ein hyperproduktives Team. Duch die Optimierung des Arbeitsflusses über den gesamten Wertstrom hinweg verringern sich die Wartezeiten an den Schnittstellen. Daraus resultierend werden Engpässe deutlich sichtbar.

Auf Flight Level 4 wird das Portfolio eines Unternehmens und Kanban eingesetzt, um mehrere Projekte und Produkte zu managen. Somit werden mehrere Wertströme optimiert. Das führt zu einem besseren Verständnis darüber, wie Bedarf und Möglichkeiten ausbalanciert werden und wie man Risiken managen kann. Die Arbeiten auf diesem Flight Level werden üblicherweise in kleinere Teile heruntergebrochen (z.B. Epics, User Stories oder Requirements), die dann durch Kanban-Systeme auf Flight Level 3, 1 oder 2 fließen.

Auch wenn dieser kurze Überblick Kanban natürlich nur oberflächlich darstellen kann, lassen sich dessen Kernprinzipien erahnen. Das Meistern im Alltag ist meist der spannendere Teil.

• Wie findet man heraus, ob Kanban für ein Projektverhaben, Team oder die gesamte Organisation geeignet ist?
• Wie führt man am besten agile Methoden wie Scrum in der Praxis ein?
• Wie kann man mit Kanban Flight Levels Kanban effizient in seinem Unternehmen einführen?

Wenn Sie möchten, beantworten wir diese und viele andere Fragen mit Ihnen gemeinsam.