Kanban ist eine agile Vorgehensweise in der Softwareentwicklung. Die Methode zielt darauf ab, den Fluss von Arbeit transparent zu machen, Überlastungen zu vermeiden, Engpässe zu identifizieren und den Durchsatz zu erhöhen.
Ursprung
Kanban (看板) heißt so viel wie Schild oder Tafel (Englisch: signboard) und ist 1947 bei Toyota im Produktionssystem entstanden. Kanban ist eine Umsetzung des Pull-Prinzips zwischen Konsumenten und Produzenten. Konsumenten bedienen sich selbst und Produzenten erzeugen nur so viel, wie die Konsumenten verbrauchen können.
Es müsste doch möglich sein, den Materialfluss in der Produktion nach dem Supermarkt-Prinzip zu organisieren, das heißt, ein Verbraucher entnimmt aus dem Regal eine Ware bestimmter Spezifikation und Menge; die Lücke wird bemerkt und wieder aufgefüllt.
Taiichi Ohno (Erfinder des Toyota-Produktionssystems mit der Kanban-Methode)
Kanban in der IT
David J. Anderson gilt als Begründer von Kanban in der Softwareentwicklung. Anderson formuliert vier Grundprinzipien (GP), um Kanban im Unternehmen einzuführen und zu leben:
- GP1: Beginne mit dem, was du gerade tust: Schließe die aktuelle Aufgabe ab, bevor du eine neue in Bearbeitung nimmst.
- GP2: Vereinbare, dass evolutionäre Veränderung verfolgt wird: Verbessere den Prozess in kleinen, nachhaltigen Schritten.
- GP3: Respektiere initial bestehende Prozesse / Rollen / Verantwortlichkeiten: Die Einführung von Kanban soll einfach sein.
- GP4: Ermutige dazu, Führung auf jeder Ebene der Organisation zu zeigen: Verbesserung erfordert die Beteiligung aller und insbesondere derjenigen, die die direkte Arbeit ausführen.
Darüber hinaus beschreibt er sechs Kernpraktiken (KP), die die Arbeit mit Kanban ausmachen:
- KP1: Visualisiere den Fluss der Arbeit
- KP2: Begrenze die Menge angefangener Arbeit
- KP3: Miss und steuere den Fluss
- KP4: Mache die Regeln für den Prozess explizit
- KP5: Implementiere Feedbackzyklen
- KP6: Verwende Modelle, um Chancen für kollaborative Verbesserungen zu erkennen
Kanban-Board
Wer schon einmal mit Kanban in Berührung gekommen ist, hat vermutlich auch mit einem sogenannten Kanban-Board gearbeitet. Das Kanban-Board visualisiert den Fluss der Arbeit (KP1). Es kann physisch oder virtuell bestehen und wird immer aktuell gehalten.
Das Board besteht aus mehreren Spalten, die von links nach rechts zu lesen sind und den Entwicklungsprozess repräsentieren. Es kann innerhalb eines Teams, aber auch teamübergreifend verwendet werden. Die einzelnen Spalten sollten auf die Arbeitsweise bzw. das Umfeld des Teams abgestimmt sein. Das folgende Beispiel zeigt ein sehr einfaches Modell:
Neue Aufgaben für das Team, die bereit zur Umsetzung sind, werden ins Backlog geschoben. Wird eine Aufgabe angefangen, so wird sie in die Spalte Work in Progress bewegt. Ist eine Aufgabe umgesetzt und kann durch den Fachbereich abgenommen werden, kommt sie in die Spalte Review. Ist eine Aufgabe abgeschlossen, so landet sie in der Spalte Done.
Wann eine Aufgabe als done verstanden werden kann, sollte in einer Definition of Done genau spezifiziert werden. Dazu kann z.B. gehören, dass der Code in den Hauptzweig eingecheckt ist, eine ausreichende Testabdeckung erhalten hat, die Build-Pipeline durchläuft, die Software mit den Änderungen auf einem Testsystem zur Verfügung steht und dort vom Fachbereich fachlich abgenommen worden ist.
Die Bedeutung der einzelnen Spalten, die möglichen Transitionen und der gesamte Prozess müssen dem Team und allen Beteiligten transparent sein, damit ein gutes, gemeinsames Arbeiten möglich ist (KP4).
Pull-Prinzip
Kanban arbeitet nach dem Pull-Prinzip. Sobald ein Entwickler seine aktuelle Aufgabe abgeschlossen hat, kann er eine neue Aufgabe aus dem Backlog in Bearbeitung nehmen. Kanban wird üblicherweise nach dem FIFO-Prinzip (first in first out) gelebt, kann je nach Umfeld aber auch um ein Prioritätensystem ergänzt werden, so dass Aufgaben als high prio deklariert oder mit einer festen Deadline versehen werden können.
Das Pull-Prinzip ist das Gegenstück zum sehr weit verbreiteten Push-Prinzip. Neue Aufgaben werden, sobald es sie gibt, von den Führungskräften an ihre Mitarbeiter übergeben, ungeachtet deren aktueller Auslastung. Hat der Mitarbeiter viele Aufgaben zur gleichen Zeit in Arbeit, kann dies zu Druck, Stress und Überforderung führen. Die Bearbeitung der Aufgaben erfordert mehr Zeit und die Ergebnisse sind schlechter, als wenn der Mitarbeiter nur wenige Aufgaben zur gleichen Zeit in Arbeit und die Kontrolle darüber hat, wann er neue Aufgaben aus einem Aufgaben-Pool zur Bearbeitung entnimmt.
Das Pull-Prinzip erhöht die Selbstständigkeit des Teams. Das Team entscheidet selbst, welche Obergrenze für die gleichzeitige Bearbeitung von Aufgaben definiert wird und wann neue Aufgaben aus dem Backlog nachgezogen werden können (KP2). Das Kanban-Board unterstützt auch im Konfliktfall. Soll eine neue Aufgabe mit sehr hoher Priorität sofort umgesetzt werden, so kann am Board aufgezeigt werden, dass dafür eine andere Aufgabe zurück ins Backlog gestellt werden muss und es zu Verzögerungen und Reibungsverlusten bei dieser Aufgabe kommt, gerade wenn später ein anderes Teammitglied die angefangene Aufgabe fortsetzen muss.
Arbeitsweise und Aufteilung
Kanban gibt keine Rollen vor und ist damit vielseitig einsetzbar. Ein Team kann aus Spezialisten oder Generalisten entstehen, Wissensinseln sind erlaubt. Der Einsatz beschränkt sich nicht auf die Softwareentwicklung. Kanban kann überall eingesetzt werden, wo es organisatorisch möglich ist.
Für einen gleichmäßigen und hohen Durchsatz ist es sinnvoll, Aufgaben möglichst klein und ähnlich umfangreich zu schneiden. Eine Aufgabe, die das ganze Team über einen großen Zeitraum bindet, ist nicht zielführend. Je kürzer die Durchlaufzeit für Aufgaben ist, desto schneller können Aufgaben aus dem Backlog nachgezogen werden.
Kanban strebt einen kontinuierlichen Arbeitsfluss an und lässt sich gut mit Continuous Delivery verbinden. Feste Release- oder Planungszyklen gibt es nicht. Änderungen sind damit jederzeit möglich und es wird permanent gewährleistet, dass sich genug Aufgaben im Backlog befinden und immer Aufgaben in Bearbeitung sind.
Lead Time / Cycle Time
Um den im Team gelebten Prozess zu optimieren, die Planung zu erleichtern und Partnern verlässliche Aussagen machen zu können, ist es wichtig, ein gutes Bild davon zu haben, wie lange es dauert, bis eine ins Backlog gestellte Aufgabe umgesetzt ist (KP3).
In Teams, die nach Kanban arbeiten, werden dafür oft zwei Metriken verwendet:
Die Lead Time misst, wie lange es dauert, bis eine neu ins Backlog eingestellte Aufgabe nach der Definition of Done abgeschlossen ist. Die Cycle Time misst die Zeit von Beginn der Bearbeitung einer Aufgabe bis zur Fertigstellung nach der Definition of Done. Die Lead Time beinhaltet damit die in der Cycle Time gemessene Zeit plus die Wartezeit, die eine Aufgabe im Backlog verbringt.
Um Ausreißer in der Statistik besser darstellen zu können, kann es sinnvoll sein, die Laufzeit für jede Aufgabe einzeln zu betrachten und dann den Durchschnitt bzw. die maximale Laufzeit für Percentiles (Quantile) zu betrachten: Wie hoch ist die Durchlaufzeit für (die schnellsten) 80% / 90% / 95% der Aufgaben?
Kontinuierlicher Verbesserungsprozess
Kanban ist ein lebender Prozess und das Team ist gefragt, seine Denk- und Arbeitsweise ständig zu hinterfragen und in kleinen Schritten weiter zu optimieren (KP5). Dieser kontinuierliche Verbesserungsprozess (KVP) geht auf den japanischen Begriff Kaizen (改善) zurück, der etwa mit Veränderung zum Besseren übersetzt werden kann.
In Kanban-Teams wird dieser KVP durch tägliche Statusmeetings und regelmäßige Retrospektiven gestützt, in denen Feedback gegeben, Probleme thematisiert und Lösungen entwickelt werden.
Engpasstheorie
Durch die Visualisierung der Arbeit und tägliche Statusmeetings werden Engpässe sichtbar: Sammeln sich viele Aufgaben in einer bestimmten Spalte an? Bleiben bestimmte Aufgaben immer besonders lange in einer bestimmten Spalte? Gibt es Aufgaben, die sich nicht kontinuierlich von links nach rechts, sondern auch immer mal wieder in die Gegenrichtung bewegen? All dies können Signale für einen Engpass sein, wobei die erste Variante davon die offensichtlichste ist. Kanban orientiert sich an der sogenannten Engpasstheorie (Theory of Constraints) von dem israelischen Physiker Eliyahu M. Goldratt.
Die Engpasstheorie besagt, dass es in einer Prozesskette immer einen Engpass gibt, also einen limitierenden Faktor, der die Durchlaufzeit begrenzt. Die Engpasstheorie beschreibt die Schritte, um einen Engpass zu identifizieren und zu beheben, wodurch ein weiterer Engpass offengelegt wird, der wiederum behoben werden kann und damit der Prozess kontinuierlich weiter optimiert wird. Kanban bietet zum Umgang mit Engpässen das Pull-System und die Begrenzung der gleichzeitig in Arbeit befindlichen Aufgaben. Die Cycle Time zeigt an, wie sich die Behebung eines Engpasses auf den Durchsatz auswirkt.
Wie kann der richtige Umgang mit einem Engpass aussehen? Angenommen, es stauen sich Aufgaben in der Review-Spalte. Die Entwicklung gerät in Leerlauf, weil der Fachbereich mit der Abnahme der Aufgaben nicht hinterherkommt. Eine Lösung wäre es, den Fachbereich personell aufzustocken. Eine zweite Lösung kann sein, dem Fachbereich mehr Zeit für Abnahmen zur Verfügung zu stellen, indem andere Aufgaben abgegeben werden.
Der vielleicht beste Weg ist es, die Entwicklung bei der Abnahme mit einzubeziehen und den Abnahmeprozess zu optimieren. Handelt es sich wirklich um ein reines Kapazitätsproblem? Wie lange dauert eigentlich eine Abnahme und warum? Kann die Entwicklung dem Fachbereich unter die Arme greifen, indem bereits eine Zielumgebung mit der richtigen Konfiguration für die Abnahme der jeweiligen Aufgabe bereitgestellt wird, damit der Fachbereich dies nicht händisch einrichten muss? Ergibt sich aus dieser Anforderung vielleicht weiteres Automatisierungspotenzial?
Die Vermeidung von Engpässen ist ein wichtiger Faktor für ein erfolgreiches Team. Da jedes Team individuelle Herausforderungen und Probleme in der Zusammenarbeit hat, fordert Kanban explizit, im Rahmen der Kanban-Methode weitere Modelle zur erproben, die diese adressieren (KP6).
Ziele und Einsatzbereiche
Kanban verbessert die Sichtbarkeit des Arbeitsflusses, die Sichtbarkeit von Engpässen und stellt Mittel zur Verfügung, um Engpässe besser zu vermeiden. Kanban kann den Durchsatz erhöhen und durch das kontinuierliche Messen desselbigen bessere Vorhersagen treffen und damit die Verlässlichkeit des Teams verbessern. Kanban zielt auf auf eine hohe Qualität und ein gutes Risikomanagement ab und darauf, die Projektkosten zu verringern.
Kanban eignet sich gut für Teams, die bereits agil arbeiten und ihren Prozess weiter optimieren wollen. Kanban ist ideal für Entwicklungsteams, die auf Continuous Delivery hinarbeiten. Gegenüber Scrum bietet Kanban mit seinen vier Grundprinzipien Unternehmen, die gerne agil arbeiten wollen, aber noch nicht so weit sind, eine geringere Einstiegshürde. Kanban eignet sich ebenfalls gut als agile Methode für serviceorientierte Teams, die jederzeit mit Prio-1-Störungen konfrontiert werden können, z.B. Datenbank-, Security-, Server- und Plattform-Administrationsteams.