Kanban. Die Methode für einen konstanten Arbeitsfluss.
Was bedeutet Kanban in der Softwareentwicklung? Wie wird ein Kanban-Board eingesetzt? Wie misst man damit den Produktionsprozess?
Kunde und Service vereinbaren, dass eine Arbeitseinheit ausgeführt, geliefert und abgenommen werden soll. Ein Ticket wird in den Fertigungsprozess gegeben. Dieser Übergang wird als Zusage bezeichnet.
Die Teammitglieder holen sich selbstständig nach dem Pull-Prinzip die eingeplanten Aufgaben als Ticket zur Bearbeitung. Die Anzahl der Tickets für die jeweiligen Bearbeitungsschritte wird begrenzt durch ein WIP (Work-in-Progress)-Limit.
Wenn Tickets nicht abgearbeitet werden, können sie von der nachfolgenden Abteilung nicht zur Bearbeitung geholt werden. Aufgrund des festgelegten WIP-Limits können aber auch keine neuen Tickets aus dem Bereich davor geholt werden. Es kommt zum Stau.
Die Übergabe der fertigen Arbeitseinheit wird als Lieferung bezeichnet. Was fertiggestellt bedeutet, muss klar definiert sein.
Was bedeutet Kanban?
Das japanische Wort Kanban ist ein Kompositum aus kan = Signal und ban = Karte und bedeutet folglich Signalkarte. Als Technik wurde Kanban erstmals von dem Toyota Produktionsleiter Taiichi Ohno 1978 in einem Buch über das Toyota Produktionssystem (TPS) beschrieben. Kanban ist Bestandteil des Just-in-Time Prinzips, das besagt, dass nur das produziert wird, was auch tatsächlich gerade zur Erfüllung der Kundenaufträge benötigt wird. Die Information, was in welcher Menge zu produzieren ist, wird vom nachgelagerten Bereich mittels einer sogenannten Kanbankarte an den vorgelagerten Bereich weitergegeben. Dadurch soll ein gleichmäßiger, sequentieller Produktionsfluss entstehen, der Lagerbestände reduzieren hilft. Ziel des Vorgehens ist eine kontinuierliche Verbesserung der Prozesse (Kaizen) und das Vermeiden von Verschwendung (Muda). Eine Studie des International Motor Vehicle Programs von 1985 bis 1991 machte im Abschlussbericht diese schlanke Produktionsorganisation unter der Bezeichnung Lean Production bekannt.
David J. Anderson:
Leute fragen mich: „Was ist der Unterschied zwischen Lean und Kanban?“ Meine Antwort: „Lean ist ein Ziel; Kanban ist ein Weg dorthin.“
Kanban in der Softwareentwicklung
Als Begründer von Kanban in der IT gilt David J. Anderson, der die Methode mit dem Buch Kanban: Successful Evolutionary Change for Your Technology Business erstmals 2007 publik machte. 2011 startete er die Lean Kanban University (LKU), die Qualitätsstandards für die Art und Weise, wie Kanban gelehrt und praktiziert wird, etabliert hat. Kanban ist laut Anderson kein Softwareentwicklungsprozess, sondern eine Methode zum Management, zur Gestaltung und Verbesserung von Fluss-Systemen für die Wissensarbeit. Das sind Systeme, in denen sich unbestimmbare Arbeitseinheiten durch verschiedene Phasen bewegen und schließlich einen Wert für Kunden stiften. Ein Kanban-System soll die Menge paralleler Arbeit (Work in Progress, kurz WIP) durch den Einsatz visueller Signale begrenzen. Arbeit wird ins System geholt (pull), sobald andere Arbeiten abgeschlossen sind und Kapazität verfügbar wird, anstatt hineingeschoben (push), sobald neue Arbeit aufkommt.
Die Kanban-Grundwerte
Diese Werte verkörpern die Motivation, durch die Methode Dienstleistungen zu verbessern. Kanban kann nicht sinngetreu angewendet werden, ohne diese Werte anzunehmen.
- Transparenz
- Balance
- Kollaboration
- Kundenfokus
- Arbeitsfluss
- Führung
- Verständnis
- Vereinbarung
- Respekt
Die Kanban-Agenden
Diese drei überzeugenden Aufrufe zum Handeln aufgrund organisatorischer Bedürfnisse gibt es:
- Die Nachhaltigkeits-Agenda richtet ihren Blick in das Innere der Organisation. Sie soll die Nachfrage mit dem vorhandenen Leistungvermögen ausbalancieren und wirkt sich positiv auf die Motivation der Mitarbeiter aus.
- Die Serviceorientierungs-Agenda richtet ihren Blick ausgehend vom Zweck des Unternehmens nach außen auf seine Kunden. Sie ist ein Schlüssel zum Erfolg.
- Die Überlebensfähigkeits-Agenda wirft einen Blick in die Zukunft und stellt sicher, dass die Organisation auch in Zeiten von Disruption und Change überlebt.
Die Kanban-Prinzipien
Change-Management-Prinzipien
Sie verfolgen das Ziel der evolutionären Verbesserung auf allen Ebenen der Organisation.
- Beginne mit dem, was du gerade tust (verstehe aktuelle Prozesse und respektiere vorhandene Rollen und Verantwortlichkeiten).
- Vereinbare, dass evolutionäre Veränderung verfolgt wird.
- Fördere Führung auf allen Ebenen der Organisation.
Service-Delivery-Prinzipien
Sie fokussieren den Nutzer einer Dienstleistung und den Wert, der für den Nutzer entsteht.
- Verstehe und fokussiere die Bedürfnisse und Erwartungen der Kunden.
- Manage die Arbeit, lass die Menschen sich selbst organisieren.
- Entwickle Regeln für eine Verbesserung der Ergebnisse.
Die Kanban-Praktiken
Alle, die Kanban-Systeme managen, sollten diese Aktivitäten durchführen:
- Visualisiere
- Limitiere die parallele Arbeit (WIP)
- Manage den Arbeitsfluss
- Mache Prozessregeln explizit
- Implementiere Rückkopplungsschleifen
- Verbessere gemeinsam, entwickle experimentell weiter
Diese Praktiken beinhalten, die Arbeit und die Prozessregeln zu sehen und den Prozess evolutionär zu verbessern.
Arne Roock (Lean Kanban University):
Stop starting, start finishing.
Das Kanban-Board
Das Kanban-Board dient der Visualisierung eines Arbeitsfluss-Systems. Arbeitseinheiten durchfließen darauf verschiedene Stadien eines Prozesses von links nach rechts. Optische Signale beschränken parallele Arbeit, d.h. in jeder Spalte ist ein WIP-Limit eingetragen. Außerdem müssen Kanban-Systeme Punkte für die Zusage und die Lieferung kennzeichnen. Der Punkt Zusage wird passiert, wenn Kunde und Service miteinander vereinbaren, Anforderungen/Ideen ins System zu übernehmen. Der Punkt Lieferung ist erreicht, wenn Arbeitseinheiten als abgeschlossen betrachtet werden. Die Zeit, die eine Arbeitseinheit braucht, um von Zusage zur Lieferung zu kommen, wird als (System)Durchlaufzeit bezeichnet. Will man andere Teile des Systems als diese Zeitspanne untersuchen, nennt man das Zeit im Prozess (Time in Progress, kurz TIP). Die Lieferrate wird bestimmt durch die gelieferten Elemente pro Zeiteinheit. Wenn das Ende der betrachteten Zeit nicht die Lieferung ist, wird diese Rate Durchsatz genannt.
Lernen Sie das Kanbanboard für alle Anwendungsmöglichkeiten kennen
Testen Sie 30 Tage lang kostenlos objectiF RPM
die Software für Anforderungs- und Projektmanagement »
Das Gesetz von John D.C. Little angewendet auf den Arbeitsfluss in einem Kanban-System:
Durchsatz = Work in Progress / Time in Process
Das Cumulative Flow Diagramm
Wie misst man, ob die durchschnittliche parallele Arbeit (WIP) in einem idealen Verhältnis zur Durchlaufzeit steht? Dafür gibt es eine passende Visualisierung in Form eines kumulativen Flussdiagramms (engl.: Cumulative Flow Diagram).
Während in der Kanban-Methodenbeschreibung vor allem die approximative durchschnittliche Work in Progress (WIP) mit der approximativen durchschnittlichen Durchlaufzeit ins Verhältnis gesetzt wird, zeigt das Cumulative Flow Diagramm rechts zusätzlich die Anforderungen vor dem Punkt Zusage (in gelb) und innerhalb der Entwicklung noch, was gerade getestet wird (in blau). Im besten Falle überlagern sich die Linien nicht, sondern fließen mit gleichbleibendem Abstand bergauf.
Was man sonst noch am Verlauf der Linien ablesen kann, erfahren Sie auf unserer Wissenseite zum Cumulative Flow Diagramm.
Rollen in Kanban
Die Methode Kanban sah ursprünglich keine neuen Rollen, Verantwortlichkeiten und Berufsbezeichnungen vor. In der Praxis haben sich jedoch zwei Rollen ausgeprägt, die jetzt auch in der Methode selbst definiert sind. Diese Rollen sind keine Jobtitel, sondern geben in erster Linie den Zweck der Positionen wieder:
Der Service Request Manager ist dafür zuständig, die Ziele und Bedürfnisse der Stakeholder zu verstehen und zu analysieren. Er ist für die Auswahl und Anforderung von Arbeitseinheiten im Replenishment-Meeting verantwortlich. Im Replenishment-Meeting wird entschieden, mit welchem Input die Warteschlange für einen Service befüllt wird.
Der Service Delivery Manager ist dafür zuständig, ausgewählte Elemente für den Kunden bereitzustellen. Er ist außerdem für die täglichen Kanban-Meetings und die Delivery-Planungsmeetings verantwortlich und wird manchmal auch Flow Manager oder Flow Master genannt.
Kanban in Organisationen einführen
Dafür gibt es ein Konzept, genannt STATIK (Systems Thinking Approach to Introducing Kanban). Anstatt isoliert Komponenten eines Systems zu betrachten, muss man verstehen lernen, wie sich ein System als Ganzes verhält. Ziel ist die Verbesserung der Wertschöpfung für den Kunden. Dafür werden acht Schritte empfohlen, die nicht unbedingt nacheinander, sondern iterativ im Team durchlaufen werden sollen:
Schritt 0: Services identifizieren
Schritt 1: Verstehen, was den Service für den Kunden zweckmäßig (Fit for Purpose) macht
Schritt 2: Quellen von Unzufriedenheit mit dem gegenwärtigen System erkennen
Schritt 3: Die Anforderungen analysieren
Schritt 4: Die Leistungsfähigkeit analysieren
Schritt 5: Den Workflow modellieren
Schritt 6: Serviceklassen finden
Schritt 7: Das System und Board-Design sozialisieren und die Implementierung aushandeln
Schritt 0: Services identifizieren
Schritt 1: Verstehen, was den Service für den Kunden zweckmäßig (Fit for Purpose) macht
Schritt 2: Quellen von Unzufriedenheit mit dem gegenwärtigen System erkennen
Schritt 3: Die Anforderungen analysieren
Schritt 4: Die Leistungsfähigkeit analysieren
Schritt 5: Den Workflow modellieren
Schritt 6: Serviceklassen finden
Schritt 7: Das System und Board-Design sozialisieren und die Implementierung aushandeln
Damit Organisationen ihre Fortschritte mit Kanban prüfen können, sollen Sie einen sogenannten Lackmustest machen. Er besteht aus 4 übergeordneten Fragen (die jeweils 4 detailliertere Fragen enthalten):
1.
Hat sich das Führungsverhalten verändert, um Kanban zu ermöglichen?
2.
Hat sich die Kundenschnittstelle im Einklang mit Kanban geändert?
3.
Haben sich Vereinbarungen mit dem Kunden durch Kanban verändert?
4.
Hat sich das Geschäftsmodell Ihrer Service Delivery verändert, um Kanban auszuschöpfen?