Kanban-Missverständnisse, Teil 1

In den letzten Tagen gab es auf Twitter einige interessante Fragen zu Kanban. Diese zeigen, dass es in der Community noch so manche Missverständnisse über die neue Methodik gibt.

Johannes Link stellte auf Twitter eine sehr interessante Frage:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer wasserfall-artigen Arbeitsaufteilung?

(Im Dialog mit Johannes, den Sie auf Twitter nachlesen können, hatte ich Probleme, in 140 Zeichen darzustellen, was ich meine, deshalb hier dieser ausführliche Blog-Artikel.)

Der Grund für das, was die Kanban-Fans tun, ist wohl dieser: In Kanban gibt es sechs Schritte oder Kern-Eigenschaften der Methode:

1. Visualisiere
2. Limitiere angefangene Arbeit (work in progress)
3. Manage den Fluss
4. Mache Prozessrichtlinien explizit
5. Implementiere Feedbackschleifen
6. Verbessert Euch gemeinsam, evolviert durch Experimente (durch Nutzung von Modellen und der wissenschaftlichen Methode)

Der erste Schritt „Visualisiere“ tut genau das: Auf einem Taskboard stellt man dar, wie der aktuelle Workflow des/der Teams gerade ist. Nicht mehr und nicht weniger. Manche Teams beginnen mit Spalten wie „backlog, in progress, done“ wie in XP oder Scrum und machen gute Erfahrungen damit. Andere Teams fügen weitere Spalten hinzu, wenn sie glauben, dass es nötig ist.

Beispiele für Workflow-Visualisierung

Ein Beispiel: In einem Scrum-Team, das ich aktuell coache, erkannten wir in einer Retrospektive, dass die Entwickler die Features oft sehr zeitnah entwickelten, die Karten auf dem Taskboard aber trotzdem sehr lange Zeit in der Spalte „in progress“ verbrachten.

backlogin progressdone………

Der Grund war: Unsere Definition of Done schrieb vor, dass der Akzeptanztest durch den Product Owner Bestandteil des Begriffes „done“ sein musste. Der Product Owner war jedoch in weiteren Projekten involviert und hatte fast nie sofort Zeit zu testen, sobald ein Feature fertig geworden war. Es bildete sich beim P.O. ein „Test-Stau“ mit unangenehmem Ergebnis: Es gab öfters einmal ungetestete Karten, die dann eben nicht zum Sprint-Ergebnis gezählt werden konnten und sollten.

Dies wollten die Entwickler sichtbar machen und fügten dem Taskboard eine Spalte „acceptance test“ hinzu. Nun konnte man erkennen, wie sich dort die Karten stapelten bis der Product Owner sie gegen Ende des Sprints abräumte – eine risikoreiche Vorgehensweise.

backlogin progressacceptance testdone…………

Ein anderes Scrum-Team, das ich kenne, verwendet eine separate Spalte mit der Überschrift „GUI design“. Dort werden Karten aufgehängt, die fast fertig entwickelt und auch schon inspizierbar sind, jedoch noch ohne eine richtig schöne und ergonomische Oberfläche, die danach erst durch eine externe UI-Designagentur geschaffen wird. Erst wenn die UIs von dort zurückkommen, wird die Karte auf „acceptance test“, danach auf „done“ geschoben.

backlogin progressGUI designacceptance testdone……………

Vom Workflow zum Wasserfall

Zurück zur Frage von Johannes: Warum zeigen die Kanban-Leute wasserfall-artige Taskboards? Antwort: Sie tun es nicht – sie zeigen lediglich Workflows. Was ist der Unterschied? Ein Workflow ist einfach eine Reihe von Arbeitsschritten, die hintereinander ausgeführt werden. Um daraus einen Wasserfall zu machen, muss man mindestens noch folgende negative Eigenschaften hinzufügen:

1. Das „100% Losgröße“-Syndrom: Man führe jeden Workflow-Schritt mit 100% aller Anforderungen durch und gehe erst danach zum nächsten Schritt des Workflows. Auf keinen Fall das, was schon getan ist, schon mal in den nächsten Workflow-Schritt weiterreichen – das könnte ja unvollständig aussehen!
2. Das Isolations-Syndrom: Man lasse die Leute, die in einem Workflow-Schritt arbeiten, auf keinen Fall mit den Leuten aus einem anderen Workflow-Schritt zusammenarbeiten. Also darf ein Analyst niemals mit einem Architekten und dieser auch niemals mit einem Entwickler reden – alle dürfen nur über Dokumente miteinander kommunizieren, die durch ausführliche Reviews abgesichert und dann unterschrieben sind.

Kanban geht gegen den Wasserfall vor

In Kanban ist beides nicht der Fall. Mit der Kanban-Methode versucht  man im Gegenteil die Durchlaufzeit eines Features durch den Workflow zu minimieren. Wer Littles Gesetz kennt, weiß, dass das mit 100% aller Anforderungen nicht geht, sondern je weniger „work in progress“ (angefangene Arbeit) man hat, desto kürzer ist die Durchlaufzeit. Deshalb limitiert man in Kanban die Zahl der gleichzeitig in Arbeit befindlichen Features.

Jeder, der arbeitet, soll die Gelegenheit haben, sich zu konzentrieren – also limitiert man die Zahl der Features z.B. auf 4, wenn man 3 Entwickler hat. Die drei Entwickler sollten im wesentlichen immer an je einem  Feature arbeiten, es sei denn, dieses ist blockiert, weil man auf eine Antwort wartet oder weil eine Ressource fehlt, die man braucht. Dann darf man sich ausnahmsweise ein 4. Feature ziehen.

Je geringer die Menge gleichzeitig angefangener Arbeit, desto geringer ist auch die Zahl der Fehler, die man einbaut. Menschen arbeiten wesentlich korrekter, wenn sie konzentriert sind. Dies reduziert die Zahl der Überarbeitungen, die notwendig sind, um ein Vielfaches!

Auch die Isolation, die im Wasserfall typisch ist, gibt es in Kanban nicht. Da Kanban aus dem agilen Umfeld stammt, ist Kommunikation ein hohes Gut. Man sollte immer mit den Leuten reden, die am selben Feature gearbeitet haben oder arbeiten werden wie man selbst. Der Entwickler wird den Business Analysten oder den Architekten fragen, der Tester wird den Entwickler fragen, was hinter gewissen Zusammenhängen eigentlich steckt. Viel besser ist es natürlich, wenn Business Analyst und Entwickler zum selben cross-funktionalen Team (wie in Scrum) gehören und das Feature gemeinsam analysieren und realisieren.

Die Kraft des Vakuums

Oben habe ich das Beispiel mit dem überlasteten Product Owner erwähnt, bei dem sich ein Test-Stau bildete. In Scrum würde man dies jetzt auf die Impediment-Liste des Scrum-Masters schreiben und dieser würde gegen den Effekt zu kämpfen beginnen. In Kanban würde man das vermutlich folgendermaßen lösen: Man würde für die Spalte „acceptance test“ ein WIP-Limit einführen und z.B. auf die Menge einschränken, die der Product Owner in einem Time-Slot, den er sich bei seinen vielen Projekten nimmt, bewältigen kann. Hat er ab und zu mal zwei Stunden Zeit und kann darin 3 Features sauber testen, so würde man das „work in progress“(WIP)-Limit auf 3 setzen. Was würde dann passieren?

Schließen Sie die Augen und überlegen Sie eine Minute, bevor Sie weiterlesen!

Die Entwickler würden jedesmal, wenn sie etwas fertig haben, eine Karte in die Spalte „acceptance test“ schieben. Kommt der Product Owner nicht zum Testen und enthält die Spalte nun 3 Karten, würden die Entwickler einfach aufhören zu entwickeln. Sie würden stattdessen vielleicht refaktorisieren, Urlaub machen, Schulungen besuchen, Kaffee trinken oder andere sinnvolle Tätigkeiten durchführen. Beim morgendlichen Stand-Up würden sie diese Tatsache auch sofort bekanntgeben.

Das Risiko, den Sprint mit einer ungetesteten Featuremenge zu beenden, würde dadurch drastisch abnehmen. Das Team inklusive P.O. wäre plötzlich als Gesamtsystem erkennbar, das einfach nicht in der Lage ist, mehr zu leisten als der P.O. fertigbekommt. Der P.O. wäre ganz klar als Bottleneck erkennbar.

Was würde als nächstes passieren, wenn niemand interveniert? Denken Sie einen Moment nach…

Das Vakuum greift um sich

Wenn die Entwickler weniger tun, staut sich plötzlich alles im Backlog zurück. Nehmen Sie an, wir hätten mittels Kanban auch die Länge des Backlogs limitiert. Die Leute, die bisher dem Product Owner geholfen haben, Features zu beschreiben und ins Backlog zu bringen (nennen wir sie „fachliche Analysten“), wären dann plötzlich ebenfalls arbeitslos, weil sie nichts mehr in das bereits volle (weil limitierte) Backlog stellen dürfen.

Oh, hier haben wir Analysten, also fachlich geschulte Leute, die frei sind! Was tun wir mit denen? Wir machen sie zu Testern, die zunächst einmal den Stau von Akzeptanztests abbauen und dadurch den P.O. entlasten. Damit wird die Spalte „acceptance test“ wieder frei, die Entwickler nehmen die Arbeit wieder auf und produzieren wieder. Im Backlog werden dadurch wieder Plätze frei, also können die Analysten ihre eigentliche Arbeit wieder aufnehmen und neue Backlog-Items produzieren. Der Propfen löst sich.

Von der Taktik zur Strategie

Das gerade geschilderte Verhalten ist sicherlich nicht optimal, doch hat es erst einmal geholfen. Das Management wird inzwischen von der Aktion gehört haben und sich entscheiden, mehr Tester einzustellen, die dem Product Owner helfen. Die Tester kommen langsam auf Touren und der Propfen wird sich dann nicht mehr bilden müssen.

Die Antwort auf die Frage nach dem Wasserfall

Johannes Frage von oben könnte man nun anders formulieren:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer so ausführlichen Arbeitsaufteilung (so viele Spalten auf dem Taskboard)?

Weil sie zeigen wollen, was wirklich passiert. Das dreispaltige Scrum-Taskboard zeigt eben nicht, dass in der Sprint-Mitte typischerweise viel WIP entsteht, besonders bei unreifen Scrum-Teams, die noch nicht lange dabei sind. Führt man mehr Spalten ein, bildet man die Realität im Team u.U. besser ab und kann auf Effekte aufmerksam machen, die man vorher übersehen hat.

D’accord, Johannes?