Der häufigste Fehler bei einer Kanban-Einführung

Bild: Unsplash / Eden Constantino - Lizenz

Bei der Einführung von Kanban gibt es so einiges auf das man achten sollte. Zum einen Dinge die man tun sollte (einige davon finden sich hier) aber solche bei denen es besser wäre wenn man sie lässt. Nach über einem Jahrzehnt Erfahrung glaube ich, dass ich mittlerweile genug anekdotische Evidenz für eine starke Aussage gesammelt habe: unter allen möglichen Fehlern gibt es einen der mit weitem Abstand am häufigsten auftritt (und auf dem Foto in diesem Beitrag ist er zu sehen).

Die Rede ist davon, dass in einem ersten Schritt alle Mitglieder der sich umstellenden Einheit alles was sie machen auf physische Post-Its oder in digitale Kacheln schreiben und die dann auf ein Board mit den Spalten To Do, in Progress und Done platzieren.¹ Die Absicht dahinter ist auch gut, es soll visualisiert werden woran gearbeitet wird und wie hier der Fortschritt ist. In den meisten Fällen ist das Ergebnis aber das genaue Gegenteil.

Warum das so ist: fast alle Tätigkeiten in klassisch arbeitenden Organisationen beziehen sich nur auf einen kleinen Teil einer langen Be- oder Verarbeitungskette. Vorne wird geplant und konzipiert, in der Mitte gebaut, entwickelt oder getestet, am Ende finden Betrieb, Verkauf oder Kundenbetreuung statt. Nur in Summe ergeben alle der aufeinanderfolgenden Schritte Sinn, für sich genommen wirkt jeder einzelne von ihnen generisch und hat wenig Aussagekraft (und viel zu viele sind es auch).

Beispiele gefällig? Vorne könnte "Marktanalyse" stehen oder "Konzept schreiben". In der Mitte könnte es "Eingabemaske im Frontend erweitern" sein oder "Software auf die Hardware aufspielen". Am Ende finden sich schliesslich "Auslieferung" oder "Übergabe an den Kundenservice". Oft sind sie noch generischer, z.B. "Test" oder "Entwicklung", jeweils mit Ticket-Nummer. Genau so sind übliche Arbeitspakete eben geschnitten, damit sie von einzelnen Fachkräften schnell erledigt werden können.

Wenn wir uns jetzt ein mit solchen Aufgaben gefülltes Board vorstellen wird das Problem offensichtlich: Tätigkeiten die eigentlich sequentiell stattfinden hängen ohne die richtige Reihenfolge über- oder nebeneinander in einer der drei Spalten To Do, in Progress und Done. Es wird nur noch klar mit welchen Riesenmengen an Detailschritten die Kollegen gerade beschäftigt sind, wie diese zusammenhängen und aufeinander aufbauen ist völlig intransparent. Das ist nicht im Sinn der Kanban-Idee.

Alleine das wäre bereits ausreichend problematisch, in der Regel geht es aber sogar noch darüber hinaus. Häufig arbeiten Teams an mehr als einem Feature-Set, Produkt oder Service parallel, die Folge davon ist, dass die dazugehörigen Einzelaufgaben auf dem gemeinsamen Board nicht klar voneinander abgrenzbar nebeneinanderhängen. Zu welchem dieser Aufgaben-Pakete eine Aufgabe wie "Integrationstest" dann gehört ist fast nur noch für den Bearbeiter nachvollziehbar.

Wie es besser geht: bevor damit begonnen wird Post-Its oder Tickets zu erstellen sollte zuerst die Abfolge der jeweiligen Arbeitsschritte explizit gemacht und visuell festgehalten werden. In einem Fall den ich in einer Einheit miterlebt habe, die kleinteilige Erweiterungen einer Altanwendung machte, hatten wir z.B. nach einem ersten Workshop die folgenden Schritte identifiziert (vereinfachte Darstellung, in Wirklichkeit war es ein kleines bisschen komplizierter):

Auf Basis einer solchen Darstellung kann dann das Board erstellt werden, mit einer Entsprechung von jeweils einem Arbeitsschritt zu einer Spalte. Und ja, in diesem Fall würde das bedeuten, dass das Board acht Spalten hat, wenn die jeweils in die jeweiligen Unterspalten Doing und Done unterteilt werden sogar sechzehn. Das kann sich zuerst nach (zu) viel anfühlen, es ist aber nichts anderes als die Realität, die nun mal irgendwie so entstanden ist.

Selbst wenn man Kanban-Systeme (meiner Meinung nach) nicht zu früh komplizieren sollte ist in den meisten Fällen noch eine weitere Ergänzung sinnvoll: die Regel, dass Arbeitspakete die zu einem gemeinsamen Feature-Set, Produkt oder Service gehören kenntlich gemacht werden sollten, etwa durch eine gemeinsame Farbe oder eine gemeinsame Zeile. Dann (aber auch wirklich erst dann) sollte mit dem Schreiben der Post-Its oder Tickets begonnen werden.

Wie an diesem Beispiel zu sehen ist,² kann die ganze Art wie Aufgaben geschnitten werden jetzt eine andere sein. Statt Detailaufgaben werden ganze Features beschrieben, deren genauer Arbeitsfortschritt sich aus der Spalte ergibt in der sie hängen. Das ist deutliche informativer. Und auch weitere Informationen fallen sofort ins Auge, die sonst schwerer erkennbar sein würden: in Feature-Set A gibt es einen Nachzügler, Feature-Set B hängt anscheinend in der Genehmigung fest.

Natürlich ist der Weg zu einem solchen Kanban-System deutlich anspruchsvoller als das einfache Aufhängen eines To Do, in Progress, Done-Boards voller Detailaufgaben. Daher scheuen viele Teams diesen Weg (oder kennen ihn gar nicht). Es sollte aber klar sein - wer sich auf die (scheinbar) einfache Lösung beschränkt wird bestenfalls die einfachste der möglichen Kanban-Varianten haben: irgendetwas Sichtbares. Wirklich besser wird dadurch kaum etwas werden.