Kanban in der Praxis

2	Kanban-Systeme betreiben und verbessern

2.1	Visualisierung, WIP-Limits und Arbeitsfluss

Mich fasziniert immer wieder aufs Neue die unglaubliche Kreativität, die in den Visualisierungen des Arbeitsflusses an Kanban-Boards steckt. Wenn Menschen sehen, was und wie viel sie eigentlich den ganzen Tag tun, wie alle Aufgaben miteinander verknüpft sind und sich allmählich zu einem lieferbaren, wertvollen Ergebnis für den Kunden zusammensetzen, entfacht das oft eine beeindruckende Dynamik. Die Beteiligten beginnen zu verstehen, dass ihnen dieses Board eine Fülle an Informationen über die Funktionsweise ihres Arbeitssystems zeigt, die sie nutzen können, um das System weiter zu verbessern. Natürlich sehe ich aber auch Boards, die diese Aufgabe nicht erfüllen und allmählich verwaisen, weil ihre Besitzer damit nichts anzufangen wissen. Überraschenderweise ist das selten der Fehler des Kanban-Boards. Die Besitzer wissen einfach nicht, wie dieses Instrument funktioniert und worauf sie achten sollten, um verwertbare Informationen aus ihrem Board zu gewinnen. Ich möchte hier einige Punkte sehr deutlich hervorheben, die oft missverstanden werden und daher die Aussagekraft eines Boards schwächen.

Die Frage klingt trivial: Was visualisiert man in Kanban eigentlich? Die instinktive Antwort darauf lautet wohl: „Na, was man halt so tut!“ Daher sehen sehr viele sogenannte Kanban-Boards auch so aus wie in Bild 2.1.

Warum führt ein solches Board nirgends hin, zumindest nicht, wenn man das Ziel der evolutionären Verbesserung verfolgt? Im Kanban-Kontext könnte man ein Board mit den Spalten To do ‒ doing ‒ done verwenden, wenn man ausschließlich den Überblick über seine eigenen Aufgaben bewahren und regelmäßig kleine Erfolgserlebnisse haben will. Man könnte das als Flight Level 0 oder auch als Personal Kanban bezeichnen ‒ Jim Benson und Tonianne DeMaria Barry haben dazu ein preisgekröntes Buch geschrieben (vgl. Benson, DeMaria Barry 2013). Ab Flight Level 1 helfen solche Boards aber nicht mehr, denn wenn das Arbeitssystem eines Service in Fluss gebracht werden soll, müssen die einzelnen Aktivitäten sichtbar gemacht werden, die eine Arbeitseinheit zur Wertgenerierung durchfließt. Diese Aktivitäten lassen sich konkret benennen. Visualisierung beginnt daher mit der Überlegung, welche Aktivitäten in einem Service in welcher Reihenfolge ausgeführt werden, um Wert zu generieren ‒ bezeichnen wir sie für den Anfang mit A, B und C (siehe Bild 2.2). Diese Aktivitäten sind die Namensgeber für die Spalten des Boards ‒ in der Realität sollten über den Spalten natürlich konkrete Aktivitäten, zum Beispiel „entwickeln“, „ausliefern“ etc. zu lesen sein. Die nächste Überlegung lautet: „An welchen konkreten Aufgaben arbeiten wir gerade?“ Diese Frage generiert die einzelnen Arbeitseinheiten, die als Tickets nun in den jeweiligen Aktivitäten platziert werden.

Ganz links am Board befindet sich die Input Queue, die manchmal auch als „Next“ oder „Bereit“ bezeichnet wird, je nach Geschmack. Idealerweise wird in der Spaltenüberschrift aber genau gesagt, wofür eine Arbeitseinheit bereit ist, also zum Beispiel „bereit für Entwicklung“. In dieser Spalte werden alle Arbeitseinheiten gesammelt, die als Nächstes erledigt werden sollen. Es ist also das Wartezimmer für Arbeitseinheiten, die im Zuge eines Spice Girls Meetings bereits in eine Reihenfolge gebracht wurden. Alle anderen Ideen oder Wünsche, die irgendwann umgesetzt werden könnten, landen zunächst in einem Ideen- oder Optionenpool und die Spice Girls entscheiden, was und wann es umgesetzt wird. Ich bezeichne dieses Sammelbecken bewusst als Optionenpool, denn es sind Möglichkeiten für die Zukunft, die es bewusst abzuwägen gilt, bevor sie endgültig in Auftrag gegeben werden. Erst dann wandern sie als Arbeitseinheiten in die Input Queue. Das bedeutet also: Zu allen Arbeitseinheiten, die sich in der Input Queue und in den Aktivitäten befinden, wurde bereits eine eindeutige Zusage (ein Commitment) abgegeben. Wenn diese zugesagten Arbeitseinheiten schließlich in der letzten Spalte landen, wurde im Idealfall für den Kunden ein Wert generiert. Ich würde diese letzte Spalte nicht prinzipiell mit „done“ oder „abgeschlossen“ übertiteln, weil nicht automatisch der gesamte Wert für den Kunden generiert wurde, nur weil der eigene Prozess (manchmal nur vorerst) abgeschlossen ist. Vielmehr empfiehlt sich, auch hier wieder den gesamten Wertstrom bis zum Kunden im Auge zu behalten und für diese letzte Spalte eine Bezeichnung zu finden, die signalisiert, wie es ab diesem Punkt weitergeht. Zum Beispiel können sich weitere Services an diesen Punkt anschließen, dann könnte diese Spalte als „bereit für . . .“ bezeichnet werden (z. B. „bereit für Kundenabnahme“ ‒ das impliziert, dass es auch noch Feedback des Kunden geben kann).

Was sollte noch sichtbar werden? In den meisten Arbeitssystemen treten Probleme und Hindernisse auf, die den Arbeitsfluss ins Stocken bringen können. Also ist es naheliegend, deutlich zu machen, in welchen Aktivitäten diese Probleme auftreten und die beteiligten Personen am Weiterarbeiten hindern. In Bild 2.2 werden solche Blockaden anhand der kleinen Sticker auf den Tickets in den Spalten B und C dargestellt (in der Praxis sind diese Sticker meistens rot). Auf diesen Stickern wird vermerkt, um welche Blockade es sich handelt. Genauso lässt sich mit andersfarbigen Stickern signalisieren, ob eine Arbeit in einer Aktivität bereits abgeschlossen ist. Ist das der Fall, kann die Arbeit ‒ und das ist nun der wichtige Punkt ‒ in die nächste Aktivität geholt werden, wann immer es dort Kapazität gibt. Kurze Erinnerung an das Flussexperiment: Durch das Heben der Hände wird signalisiert, dass eine Aktivität abgeschlossen ist. Kanban ist also ein Pull- und kein Push-System. Eine andere Variante der Visualisierung ist, Spalten noch einmal in „in Arbeit“ und „fertig“ zu unterteilen.

Verglichen mit der sonst üblichen völligen Unsichtbarkeit von Wissensarbeit lässt sich mit wenigen Mitteln bereits sehr viel Sichtbarkeit herstellen. Bis zu diesem Punkt ist bereits erkennbar,

• wie der Arbeitsfluss aussieht.

• wo sich die einzelnen Arbeiten gerade befinden, wie weit die Arbeit insgesamt also bereits fortgeschritten ist.

• welche Arbeiten als Nächstes abzuschließen sein werden (Next-Spalte).

• welche Ideen und Optionen es gibt.

• welche Blockaden im Arbeitsfluss bestehen.

• welchen Grund diese Blockaden haben.

• welche Arbeiten abgeschlossen sind.

2.1.1

Mit WIP-Limits arbeiten

Kanban ist nicht nur ein Pull-System, sondern ein WIP-limitiertes Pull-System, und das heißt: Die Menge der Arbeit in einem System wird beschränkt. Beim Falten der Schiffe habe ich in jeder Aktivität (am Board wären es Spalten) ein WIP-Limit von 1 gesetzt. Es durfte sich also immer nur ein Schiff in einer Aktivität befinden ‒ egal, ob daran gearbeitet wurde oder nicht. Die Menge der Arbeit in...