[SL] Kanban, aber bitte mit WIP-Limits

Kanban-Boards sind attraktiv für das Projektmanagement, weil die spaltenweise Ansicht die anliegende Arbeit gut visualisiert. Ein Kanban-Board macht die unsichtbaren Warteschlangen in den einzelnen Phasen des Software-Lieferprozesses sichtbar.

Was aber manche Teams (und manche Werkzeuge wie Trello) ignorieren: Kanban ist in erster Linie ein Mittel zur Begrenzung der Arbeit im System (WIP - work in process). Es gilt also, Warteschlangen nicht nur sichtbar zu machen, sondern auch zu bändigen.

In der ursprünglichen Ausprägung im Toyota Production System ist ein Kanban eine Pappkarte, die zu einer bestimmte Anzahl eines bestimmten Teils gehört. So könnte es eine Kanban-Karte für 10 XY-Ventile geben, die ich zusammen mit den 10 Ventilen in einer Schachtel bekomme. Wenn ich die 10 Ventile verbaut habe, schicke ich die Kanban-Karte zurück an meinen internen Zulieferer (upstream), damit er die nächsten 10 Ventile für mich baut oder bereitstellt. Ich mache inzwischen mit der nächsten Schachtel weiter. Es gilt die Regel: es wird nur das hergestellt, wofür man auch eine Kanban-Karte vorliegen hat. Wenn ich also aus irgendeinem Grund mal in’s Stocken komme, und keine XY-Ventile mehr verbaue, dann gibt’s von mir keine Kanban-Karte für meinen internen Zulieferer (upstream). Er hält dann seine Ventil-Produktion an, statt auf Vorrat weiter zu produzieren.

In der ganzen Fabrik gibt es vielleicht nur 4 solcher Kanban-Karten für jeweils 10 XY-Ventile. Es kann also zu jedem Zeitpunkt nur 40 Ventile geben, die noch nicht verbaut sind – das WIP ist beschränkt.

Am Kanban-Board legen wir für die relevanten Spalten (z.B. Analysis, Development, Test, Deployed) ein WIP-Limit fest, z.B. dass in “Test” maximal 5 User stories, Tickets o.ä. sein dürfen. Damit beschränken wir in jeder Phase des Entwicklungsprozesses die Anzahl an Dingen, die gerade “in Bearbeitung” sind.

Weniger WIP bedeutet kürzere Durchlaufzeiten, mit einer Menge positiver Auswirkungen:

WIP Limits werden manchmal unbequem (sonst sind sie nicht streng genug). Die Regel ist ja: wenn eine Spalte “voll” ist, fange dort keine neue Arbeit an. Wenn also z.B. in “Development” das Limit 4 ist und dort gerade 4 Karten in Bearbeitung sind, kann keine neue Karte angefangen werden. Ein Entwickler ist dann vielleicht blockiert, das ist unbequem und am Anfang ungewohnt. Was kann er tun? Den Entwickler-Kollegen helfen, ihre Karten abzuarbeiten, z.B. durch Code Review. Oder in anderen Spalten helfen, z.B. etwas testen, ein Deployment machen usw.

Wenn Sie es also noch nicht getan haben sollten: Der nächste Schritt nach der Visualisierung von Aufgaben am Kanban-Board ist die Einführung von WIP-Limits.

Übrigens: Man kann WIP-Limits und weitere nützliche Kanban-Werkzeuge bei Trello nachrüsten mit Corrello bzw. dem kostenlosen Agile Tools Power up.

Matthias Berth

Alle Emails