Kanban ist eine Change-Management-Methode, die aus dem Bereich Lean/Agile kommt und vor allem auf zwei Kernregeln setzt: Visualisierung und Begrenzung des „Work in progress“ (WIP Limit, an wie viel gleichzeitig gearbeitet wird). Wie in einem T3N-Artikel zu Kanban im Januar gezeigt, geht es dabei vor allem darum, über WIP Limits den Arbeitsfluss zu verbessern und Engpässe schneller zu identifizieren.

Das Prinzip ist nun wirklich recht einfach: Post-It-Zettel an ein Whiteboard hängen, die Zahl der Post-Its pro Spalte begrenzen und täglich kurz im Team besprechen, was zu tun ist (Daily Standups). Wozu braucht man hier ein Training? Und wozu gar eine Zertifizierung für Trainer?!

Einfach gesagt: Kanban kann mehr als nur Visualisierung und WIP Limits. Die oben genannten Punkte sind nur die ersten beiden Core-Praktiken der Kanban-Methode, insgesamt werden 5 solche Core Properties angegeben:

1. Visualisierung
2. Limit WIP
3. Flow Management (inkl. Metriken)
4. Explizite Policies
5. Kollaborative Verbesserung mit (Denk-) Modellen

Je genauer man sich auch um die restlichen drei Praktiken kümmert, desto mehr holt man aus Kanban heraus. Zum Beispiel ist es auf Dauer wichtig, sich den Flow genauer anzuschauen – nicht nur auf dem Board, das ja immer nur eine Momentaufnahme ist, sondern mit Tools wie dem Cumulative Flow Diagram (CFD), Histogrammen oder Control Charts. Der bereits genannte t3n-Artikel zeigt, was es mit CFDs auf sich hat. Werfen wir jetzt kurz einen Blick auf Control Charts.

Im Control Chart sieht man unter anderem, welche Tasks besonders lange brauchen, und kann so überprüfen, ob es sich um ein systematisches Problem handelt. Informativ ist auch das sogenannte Upper Control Limit (UCL), im Control Chart unten als rote Linie dargestellt. Es wird berechnet über die zeitliche Verteilung aller Tickets (manche brauchen sehr lang, manche sehr kurz, die meisten „normal“ lange). Die sogenannte Standardabweichung dieser Werteverteilung ist eine wichtige statistische Kennzahl. Hat man Tickets oberhalb der roten Linie, also Tickets, die länger brauchen als der Durchschnitt (schwarze Linie) plus 3x die Standardabweichung, hat man ein Problem. Das sollte nämlich – statistisch gesehen – fast nicht vorkommen, also stimmt etwas am Prozess nicht (manchmal wird als UCL auch Durchschnitt plus 1x Standardabweichung verwendet),

Zwar weiß man natürlich auch ohne Statistik, dass es nicht gut ist, wenn etwas zu lange dauert. Control Charts geben aber die Möglichkeit, über die Zeit hinweg zu visualisieren, was passiert, und statt schwammiger Angaben wie „besser kurz als sehr lang“ klare, empirisch abgesicherte Vorgaben zu machen: Ein Ticket darf nicht länger als n Tage brauchen, sonst ist Krisensitzung angesagt.

Kanban einfach anwenden. Unser Videokurs zeigt dir, wie es geht.

Diese „wissenschaftliche“, also statistische Herangehensweise führt dazu, dass man sich nicht nur auf das Bauchgefühl verlassen muss, ob noch alles im Rahmen ist. Man kann – wieder statistisch gesehen – genau vorhersagen, dass ein Ticket mit beispielsweise 85 oder 99 Prozent Wahrscheinlichkeit nach n Tagen fertig ist. Diese Information wiederum wird für Service Level Agreements (SLA) mit dem Kunden genutzt, denn aufgrund der Erfahrung aus der Vergangenheit kann man vorhersagen: Wir können ein Ticket (fast) mit Sicherheit in n Tagen fertig bearbeiten. David Anderson pflegt in seinen Präsentation zu sagen: Wer kann schon mit herkömmlichen Methoden vorhersagen und damit versprechen (!), dass er einen Task mit 99 Prozent Wahrscheinlichkeit bis zum Datum X fertig bekommt? Im Grunde niemand, wenn man ehrlich ist, so seine Meinung.

Punkt 4, Explizite Policies, soll vor allem sicherstellen, dass das Team eine gemeinsame Vorstellung vom Ablauf, Arbeitsprozess und den Bedingungen hat, wie etwa eine „Definition of Done“ (DoD). Diese Policies sollen dabei immer wieder geprüft und besprochen werden. Die DoD muss z.B. klarstellen, wann etwas wirklich fertig ist. Ein „so gut wie fertig“, das schon so manches Projekt an die Wand gefahren hat, gibt es dann nicht mehr, denn über dem Kanban-Board hängt die Definition von „Done“ in Stichpunkten klar festgehalten. Erst, wenn alles erfüllt ist, darf das Ticket in die nächste Spalte.

Die in Punkt 5 genannten Modelle, die zur Verbesserung der Arbeit verwendet werden können, basieren zum Beispiel auf Deming (PDCA Cycle), Systems Thinking, der Theory of Constraints (zu Deutsch Engpasstheorie) oder Überlegeungen zu „Waste“ aus der Lean-Management-Tradition. Je komplexer das Projekt und je größer das Team, desto eher lohnt es, sich mit solchen theoretischen Grundlagen zu beschäftigen.

Fazit: Geht man über die Basics hinaus, kann man aus Kanban als Methode noch mal deutlich mehr Nutzen ziehen als nur Visualisierung und Flow-Verbesserung. Deshalb ist ein Training beim Profi eventuell sinnvoll.

Die Lean-Kanban University hat nun in einer internationalen Gruppe von 18 Firmen unter der Federführung von David J. Anderson ein Akkreditierungsprogramm für Kanban-Trainings verabschiedet, ein entsprechendes Kurrikulum wird demnächst veröffentlicht. Wer eine Kanban-Schulung bei einer der Partner-Firmen macht, kann sich sicher sein, dass er nicht nur eine flache Einführung in Kanban bekommt, sondern das ganze Wissensspektrum, das die langjährige Arbeit mit der Kanban-Methode für die Softwareindustrie inzwischen bereithält. Zertifizierungen für Schulungsteilnehmer sind ebenfalls angedacht, existieren derzeit aber noch nicht.

Übrigens, wer sich für Kanban interessiert und im Raum Hamburg unterwegs ist: Am 30.3. findet das Gründungstreffen der deutschen Limited WIP Society statt, auf dem sich im Barcamp-Style die deutschen Kanban-Usergroups treffen. Sicher ein hochspannendes Event!

• Limited WIP Society Deutschland (Dach der deutschen Kanban Usergroups)
• Limited WIP Society Yahoo Group (Haupt-Diskussiongruppe)
• Die Lean-Kanban University, Dachorganisation der Akkreditierung/Zertifizierung
• Blogpost von David J Anderson zum Akkreditierungsprogramm der LKU
• t3n-Artikel Kanban: Entwicklungsprozesse im Produktionsablauf geschickt verschlanken