Kanban. Die Methode für einen konstanten Arbeitsfluss.
Was ist Kanban in der Softwareentwicklung? Wie wird ein Kanban-Board eingesetzt? Wie misst man damit den Produktionsprozess?
Was ist Kanban in der Softwareentwicklung? Wie wird ein Kanban-Board eingesetzt? Wie misst man damit den Produktionsprozess?
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:
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.
Diese Werte verkörpern die Motivation, durch die Methode Dienstleistungen zu verbessern. Kanban kann nicht sinngetreu angewendet werden, ohne diese Werte anzunehmen.
Diese drei überzeugenden Aufrufe zum Handeln aufgrund organisatorischer Bedürfnisse gibt es:
Sie verfolgen das Ziel der evolutionären Verbesserung auf allen Ebenen der Organisation.
Sie fokussieren den Nutzer einer Dienstleistung und den Wert, der für den Nutzer entsteht.
Alle, die Kanban-Systeme managen, sollten diese Aktivitäten durchführen:
Diese Praktiken beinhalten, die Arbeit und die Prozessregeln zu sehen und den Prozess evolutionär zu verbessern.
Arne Roock (Lean Kanban University):
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.
Das Gesetz von John D.C. Little angewendet auf den Arbeitsfluss in einem Kanban-System:
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.
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.
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 Kanban-System gestalten |
Schritt 8 | 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?