Es gibt inzwischen eine Fülle von Artikeln, Büchern und anderen Ausführungen zum Thema Kanban, so daß ich hier das Kanban-Prinzip nicht erschöpfend vorstellen werde. Die folgende Zusammenfassung mit den vier Grundprinzipien folgt einem Vortrag, den ich bei einer Kundenkonferenz von it-agile hören durfte.
Erfunden von Taiichi Ohno, dem damaligen Chef von Toyota, sollte Kanban die Prozesskettensteuerung optimieren und die Lagerhaltung minimieren. David Anderson hat dann vor einigen Jahren diese Idee auf die Softwareentwicklung adaptiert, und seitdem laufen auch hier Signalkarten (japanisch: Kanban) durch die Prozesskette der Softwareentwicklung. Eine „Kanban“ entspricht in etwa einem Task in Scrum, darunter können sich zumindest diejenigen, denen Scrum vertraut ist, etwas vorstellen. Mir ist die Definition des „Minimal Marketable Feature“ lieber, mit der der ideale „Umfang“ einer Karte am besten beschrieben ist: Die kleinste Einheit, die man dem System hinzufügen kann, so daß am Ende ein Mehrwert entsteht. Auch die Definition ist noch flexibel. Am besten funktioniert Kanban, wenn alle Karten in etwa gleich „groß“ sind.
Visualisierung
Diese Karten wandern über das Kanban-Board, auf dem die Prozesskette abgebildet ist. Oft findet man hier die „Phasen“, die man aus dem typischen Wasserfall-Modell kennt. Und doch ist es kein wirklicher Wasserfall, da hier nur jeweils ein Feature, also eine Karte, unabhängig von den anderen die Phasen durchschreitet. Damit sind wir bei einem iterativen Vorgehen mit sehr kleinen Entwicklungsstufen. Jede der Phasen hat zwei Spalten, eine „in work“-Spalte und eine „done“-Spalte. Ist die Phase abgearbeitet, wandert die Karte aus „in work“ in „done“. Von dort wird sie in die nächste Phase in die „in work“-Spalte gezogen (siehe „Pull-Prinzip“).
Am Board sieht man zu jeder Zeit den aktuellen Status der verschiedenen Aufgaben. Hält man den Status des Boards in regelmäßigen zur Kartengröße passenden Zeitabständen fest, bekommt man eine sehr einfache Möglichkeit, Statistik zu führen. Eines der in meinen Augen wichtigsten Charts ist dabei das CFD (Cumulative Flow Diagram), an dem man am besten eventuelle Probleme oder Engpässe ablesen kann. Welche Patterns man dort erkennen kann, hat Christian nach dem Treffen der Limited WIP Society München im November 2011 festgehalten.
Limited work in progress
Um den „Flow“ zu erhalten sollen möglichst wenige Aufgaben gleichzeitig in Bearbeitung sein. Ein enormer „Aha“-Effekt ist in meinem aktuellen Team eingetreten, als wir bei der Einführung von Kanban das Board aufgebaut haben, und das erste Mal vor Augen hatten, wieviele Tasks wir parallel in Arbeit hatten. Abgesehen vom Taskswitch-Overhead, also der Zeit die beim geistigen Umschalten von einer Aufgabe zur anderen verlorengeht, führt die gleichzeitige Bearbeitung mehrerer Aufgaben ja nicht dazu, daß auch nur eine davon schneller fertig ist. Vielmehr blockieren sich diese Aufgaben im Gesamtbild gegenseitig. Dem steuert ein Kanban-System entgegen, indem die gleichzeitige Arbeit limitiert wird.
Wir können hier die Schwangerschafts-Gleichung in die andere Richtung erweitern. In ihrer Urform lautet die ja: 1 Frau braucht für 1 Kind 9 Monate. Wie lange brauchen 9 Frauen für 1 Kind? In Kanban fragen wir: Wie lange braucht 1 Frau für 9 Kinder? Wir tauschen zwischendurch die Kinder nicht aus, sie kommen tatsächlich nacheinander zur Welt. Zwillinge sind ausgenommen. Sehen Sie das WIP-Limit von 1 pro Frau?
Pull-Prinzip
Bleiben wir bei unserem Schwangerschafts-Analogon. Von einer Schwangeren im sechsten Monat wird kein geistig gesunder Mensch verlangen, doch bitte sofort mit dem (parallelen) Austragen eines zweiten Kindes anzufangen. Da kann man noch so viel „pushen“, es wird nicht zum Ziel beitragen. Hier endet das Gleichnis, denn wir setzen jetzt voraus, daß ein Mitglied eines Kanban-Teams sofort nach Erledigung einer Aufgabe mit der nächsten weitermachen möchte, die Frau also sofort nach einer Geburt ein weiteres Kind haben will.
Das Pull-Prinzip gebietet, daß ein Entwickler dann eine neue Aufgabe beginnt, wenn er die vorherige Aufgabe beendet hat, er sich also „das nächste Ticket zieht“, oder wie immer man die Übersetzung von „pull“ in den Kontext bringen möchte. Es steht im Gegensatz zum „Push-Prinzip“, bei dem ein an sich geistig gesunder Stakeholder die Parallel-Schwangerschaft verlangt und nach neun Monaten fragt, warum das erste Kind nicht fertig ist, oder gar beide Kinder.
Kaizen
Kontinuierlicher Verbesserungs-Prozess (KVP), eines der schon nicht mehr modernen Buzz-Words, heißt in Kanban „Kaizen“. Dahinter steht eine regelmäßige Retrospektive, bei der eine Betrachtung des Prozesses stattfindet, und Änderungen am Board, an WIP-Limits oder am Prozess selbst vorgenomen werden. In Kanban heißt das eigentlich „Operations Review“, nach Projekten nennt man das oft „Lessons learned-Workshop“, die Aussage ist immer die gleiche. In einem funktionierenden Kanban-System ändert man den Prozess jedoch mit sofortiger Wirkung. Nach meiner Erfahrung ist die Kopplung der Retrospektiven an den gelebten Prozess viel enger als bei Lessons-Learned-Workshops, die man oft aus Zeitmangel entweder ganz entfallen oder tatsächlich erst nach Projektende stattfinden läßt, wenn keiner mehr die rechte Erinnerung an die genauen Zusammenhänge und Gründe für eventuelle Probleme hat.
Nimmt man diese vier Grundprinzipien zusammen, hat man die besten Voraussetzungen für ein funktionierendes Kanban-System geschaffen. Die Betrachtung, wie wir das in der Software Maintenance brauchen können, folgt.