Kanban

Kanban stammt aus Japan und ist eine Methode zur Produktionssteuerung. Die Ziele sind dabei hauptsächlich ein gleichmäßiger Produktionsfluss und eine knappe Lagerhaltung für die Unterstützung einer just-in-time-Produktion. Die Anpassung der Methode für die Software beschreibt eine industrieller Softwareproduktion mit deutlichen Anleihen beim Konzept der lean production.
Der ideologische Hintergrund stützt sich auf sog. Grundprinzipien und Kernpraktiken. Die Grundprinzipien lassen sich wie folgt beschreiben:

• Man beginnt mit dem, was man gerade tut, also der aktuellen Arbeit, bevor etwas Neues angefangen wird.
• Ständige Verbesserungen sollen in kleinen, evolutionären Schritten erfolgen.
• Bestehenden Rollen und Prozesse sollen akzeptiert werden und auch weiter bestehen.
• Führung wird auf jeder Ebene der Organisation zugelassen, damit Mitarbeiterinnen und Mitarbeiter, die direkt die Arbeit verrichten, "Acts of Leadership" zeigen und konkrete Verbesserungsvorschläge einbringen können.

Die Kernpraktiken sind:

• Visualisierung des Flusses der Arbeit in allen Projektschritten (Anforderungsdefinition, Programmierung, Dokumentation, Test, Inbetriebnahme) auf einem großen Whiteboard, dem sog. Kanban Board, wobei die einzelnen Aufgaben als Karteikarten die Spalten auf dem Board durchwandern.
• Die Menge der angefangenen Arbeit wird begrenzt gehalten. Dabei holt sich jede Arbeitsstation ihre in Tickets beschriebene Arbeit bei der Vorgängerstation ab.
• Der Arbeitsfluss wird durch ständige Messung des Fortschritts gesteuert (Warteschlangen, Bearbeitungszeiten usw).
• Transparenz und Erläuterung sämtlicher Regeln der Prozesse.
• Implementierung von Feedbackzyklen (Betrachtung der bisherigen Zusammenarbeit, Absprache anstehender Arbeiten, Erfahrungsaustausch mit anderen Teams).
• Anwendung von Modellen, um Chancen für kollaborative Verbesserungen zu erkennen (z.B. LeanIT).

Die Stellen, vor denen sich Tickets häufen, während an den nachfolgenden Stationen freie Kapazitäten vorhanden sind, werden als Bottlenecks bezeichnet. Sie sollen schneller erkannt werden, und alle Beteiligten sollen sich um technische wie organisatorische Verbesserungen im Sinne eines kontinuierlichen Verbesserungsprozesses (Kaizen) bemühen.
Auch wenn die Stationen auf einem Kanban-Board häufig den Schritten des Wasserfallmodells entsprechen, besteht hier kein zwingender Zusammenhang. Insbesondere ist Kanban darauf angelegt, dass die einzelnen Tickets möglichst schnell alle Stationen durchlaufen und dann auch regelmäßig freigegeben werden. Kanban arbeitet mit kleinen Schritten, die regelmäßig überprüft und gegebenenfalls wieder korrigiert werden. Die Methode lässt sich auch auf ein existierendes Wasserfall-Modell aufsetzen und soll dazu führen, dieses schneller und flexibler zu gestalten.
Kanban weist auch viele Gemeinsamkeiten mit Scrum auf. Weder muss man zuerst Scrum einsetzen, bevor man Kanban einführt, noch schließen sich beide Ansätze komplett aus. Der Hauptunterschied zwischen beiden Ansätzen besteht darin, dass Scrum ein team-zentrierter Ansatz ist und Kanban primär die Wertgenerierung entlang der Wertschöpfungskette optimieren soll.
In vielen Kanban-Teams haben sich die folgenden drei Praktiken etabliert:

• Tägliche Statusmeetings (ca. 15-minütige Standup-Meetings) vor dem Kanban-Board,
• Operations Reviews als Meetings für Vorschläge zur kontinuierlichen Verbesserung, an denen auch das Management beteiligt werden soll,
• Root Cause Analysis zur Behebung erkannter Fehler (z.B. Arbeitsstaus, Unterauslastungen einzelner Stationen, zu lange Durchlaufzeiten)

Genau wie bei Scrum lässt sich die Kanban-Methode IT-technisch gut unterstützen, wobei die behandelten Tickets mit Prioritäten versehen werden und somit vom standardmäßigen FIFO-Prinzip (first in – first out) abweichen können.
Momentan wird Kanban hauptsächlich in folgenden Fällen eingeführt:

• Ein Team, das bereits agil vorgeht (zum Beispiel nach Scrum), will weitere Verbesserungsmöglichkeiten finden um flexibler mit den Anforderungen umzugehen, die Durchlaufzeiten zu verkürzen, häufiger Arbeiten freizugeben und fokussierter zu arbeiten.
• Für klassisch, z.B. nach dem Wasserfall-Modell ausgerichtete Unternehmen, stellt es häufig eine zu große Herausforderung dar, ein Vorgehen wie Scrum einzuführen, weil hierfür recht weit reichende Veränderungen nötig sind. Hier bietet Kanban den Vorteil, dass Änderungen allmählich und nicht auf einmal in großem Umfang eingeführt werden können.
• Für Bereiche, die durch starke Arbeitsteilung und Spezialisierung gekennzeichnet sind, ist Kanban häufig attraktiver als andere Methoden, in denen oft gefordert wird, dass die Teams aus Generalisten bestehen.
• Weil Wartung und IT-Betrieb durch viele Unterbrechungen und regelmäßige Notfälle gekennzeichnet sind, sind hier ungestörtes Arbeiten und Iterationen fester Länge wie in Scrum kaum möglich. Hier wird Kanban oft als die bessere Wahl angesehen, insbesondere, weil die verschiedenen Service-Arten in Kanban gut zum Alltag von Systemadministratoren und Wartungsteams passen.

Karl Schmitz, Dezember 2019