Kanban richtig einführen
Seite 2: Konsens als Grundlage
Konsens ist die Grundlage des Kanban-Change
Verordnung von Veränderung funktioniert nicht. Genauso wenig funktioniert es, wenn Teams die Veränderung an sich reißen, Management und Stakeholder (wie Produkt- oder Salesmanager) als "Impediments" sehen und vor vollendete Tatsachen stellen. Change Management durch Kanban forciert den konsensuellen Weg. Für alle – Team, Management und sonstige Stakeholder im Software-Entwicklungsprozess – muss die Veränderung nachhaltige Vorteile bringen, sonst schert immer eine Partei aus. Ziel ist eine "Win-Win-Win"-Situation. Im besten Fall durchlaufen dazu alle Parteien die drei Phasen des Veränderungsprozesses:
- Sondierung: Alle verstehen, dass eine Veränderung nötig ist.
- Engagement: Gemeinsam entwickelt man eine Vision und vereinbart Aufgaben und messbare Ziele für die Veränderung.
- Durchführung: Die Vision wird in Schritten umgesetzt und nach den vereinbarten Kriterien beurteilt.
In der Praxis überspringt man häufig die ersten beiden Phasen und daher scheitern auch Veränderungsprojekte – egal ob klassisch oder agil. Denn dem Initiator ist meistens klar, was er warum verändern will – allen anderen nicht.
Ziele als Ausgangspunkt
Kanban in sieben Schritten
- Grenzen ziehen
- Arbeitsweisen visualisieren
- WiP-Limits (Grenzen für die Work in Progress) festlegen
- Serviceklassen definieren
- Regeln festlegen
- Messungen durchführen
- Betrieb installieren
Ziele sind auch dann zu definieren, wenn in Kanban keine bestehenden Prozesse, Abläufe und Hierarchien über Bord zu werfen sind. Zweck jeder Kanban-Einführung soll es sein, Prozesse und Arbeitsweisen zu verbessern. Wenn darüber Einigkeit herrscht, müssen Management, Team und Stakeholder weitere Ziele definieren. Sinnvoll ist es, mit dem dringendsten Problem zu beginnen (vielleicht mangelhafte Termintreue) und nicht gleich alle weiteren Sorgen mit auf die Agenda zu nehmen. Am Weg zur Umsetzung zeigen die sich später von selbst, und im Laufe der Zeit werden alle Beteiligten immer geübter darin, diese Probleme kurzfristig zu beseitigen. Ausgehend von den gemeinsam definierten Zielen wird so schrittweise das Kanban-System aufgebaut.
Herrscht schließlich Konsens über den Willen zur Veränderung und sind die primären Ziele festgelegt, geht es mit den Mechaniken von Kanban an die Visualisierung des Arbeitsflusses. Damit ist das Kanban-System mit seinen Werkzeugen selbst ein "Motor" des "Change", des Wechsels.
Erster Schritt: Grenzen ziehen
Wieder gilt der evolutionäre Ansatz: Die gesamte Wertschöpfungskette eines Unternehmens im ersten Schritt abbilden zu wollen, ist zu viel des Guten. Daher identifizieren zunächst ein oder mehrere Teams (Entwicklung, Support, Qualitätssicherung), an welcher Stelle der Wertschöpfungskette sie sich befinden. Was zählt zu ihren Aufgaben und was nicht, wo gehen sie in den Verantwortungsbereich von anderen über? Es lassen sich schließlich nur die Dinge verändern, auf die man direkten Einfluss hat.
Zweiter Schritt: Visualisierung
In Form eines Kanban-Boards macht man im zweiten Schritt Arbeit und Arbeitsweisen sichtbar. Hier sollten Anwender sich nicht auf rein schriftliche Prozessdefinitionen stützen, denn es ist der gelebte Arbeitsprozess, nicht der theoretisch erwünschte zu visualisieren. Dabei kommt das Team zum Zug, denn es weiß selbst am besten, wie es tatsächlich arbeitet. Danach stellt das Team fest, von wem es welche Informationen erhält und an wen es eigene Informationen weitergibt. Das macht dem Team bewusst, welche Arten von Arbeit (Arbeitstypen) es eigentlich erledigt. Im Anschluss verteilt man die Kapazitäten auf die einzelnen Arbeitstypen. Auf dieser Basis lässt sich der Arbeitsfluss gezielt steuern, da hinter jedem Arbeitstyp ein bestimmter Bedarf und Grad an Dringlichkeit liegt. Bugs müssen zum Beispiel umgehend bearbeitet werden, Features brauchen eventuell hohe Liefertreue. Die Analyse des Inputs und der Arbeitstypen ermöglicht es auch, Stehzeiten einzuplanen, die für schnelle Reaktionen auf unvorhergesehene Ereignisse genutzt, oder auf regelmäßige "Bursts" verwendet werden (zum Beispiel Findings der QA-Abteilung).
WiP-Limits beschränken die Zahl der parallelen Arbeiten pro Arbeitsschritt. Die einfache Idee dahinter: Es ist sinnvoller, eine Arbeit zu 100 Prozent abzuschließen, als zehn Arbeiten zu je nur zehn Prozent. Das Setzen von WiP-Limits am Kanban-Board verdeutlicht, wo gerade Engpässe bestehen oder der Arbeitsfluss immer wieder ins Stocken kommt. Sie signalisieren visuell, wo gehandelt werden muss.
Damit WiP-Limits funktionieren, ist wieder eins gefragt: Konsens zwischen Team, Management und Stakeholdern. Nur wenn sich alle einig sind, dass mit WiP-Limits gearbeitet wird, was diese Begrenzungen darstellen und signalisieren, lässt sich eine permanente Überschreitung der Grenzen verhindern. Die Stakeholder müssen die Funktionsweise nicht bis ins Detail verstehen, wohl aber, welchen Vorteil die Arbeit mit WiP-Limits hat. Hier kann es helfen, wenn ein Stakeholder selbst vor dem Kanban-Board steht und sieht, wie sich zusätzliche Aufgaben auf die Durchlaufzeit im Team auswirken.
Wie hoch man das WiP-Limit am Anfang ansetzt, ist zunächst eine Bauchentscheidung und sekundär. Wichtig ist die Einigung darauf, dass man in einem WiP-limitierten Pull-System arbeitet, weil das der Motor der Veränderung ist. Beim Pull-System holt (pull) sich der Bearbeiter des nächsten Arbeitsschritts seine Arbeit dann vom Vorgänger, wenn dieser bereit dazu ist. Die "realistischeren" Anpassungen der WiP-Limits an die Kundenbedürfnisse geschehen dann im laufenden Betrieb. Ziel ist die Balance aus flüssiger operativer Arbeit sowie Zeit für Fehlererkennung und Problemlösung. Gerade für das Management ist dieser Gedankensprung oft schwierig: Freie Kapazitäten der Mitarbeiter sind nichts Schlechtes, sondern zeitliche Kapazitäten für Verbesserung.
