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 fünf Schritte oder Kern-Eigenschaften der Methode:
- Visualisiere den Workflow
- Limitiere angefangene Arbeit (work in progress)
- Messe und manage den Fluss
- Mache Prozessrichtlinien explizit
- Benutze Modelle (wie z.B. ToC), um Möglichkeiten zur Verbesserung zu erkennen
Der erste Schritt “Visualisiere den Workflow” 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.
| backlog | in progress | done |
|---|---|---|
| … | … | … |
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.
| backlog | in progress | acceptance test | done |
|---|---|---|---|
| … | … | … | … |
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.
| backlog | in progress | GUI design | acceptance test | done |
|---|---|---|---|---|
| … | … | … | … | … |
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:
- 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!
- 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?
Diese Beiträge könnten Sie noch interessieren:
- Transparente Arbeit
- WIP – Aufgaben in Arbeit
- Kanban
- Kanban-Missverständnisse, Teil 2
- Qualitätsanforderungen agil managen
Berater, Coach und Trainer für effektive Produktentwicklung
Hi Matthias,
diesen Satz verstehe ich nicht: “Die Entwickler würden jedesmal, wenn sie etwas fertig haben, eine Karte in die Spalte “acceptance test” schieben.”
Das hört sich nicht nach pull an?!
Gruß,
Arne
Hi Arne,
da hast Du recht. Der P.O. ist größtenteils in anderen Projekten unterwegs und kann deshalb nicht ziehen. Deshalb schieben stattdessen die Entwickler. Ist nicht wirklich Kanban-konform, doch wirksam.
Um konform zu sein, hätte man stattdessen auch eine Spalte “development done” machen können, die den Entwicklern gehört. Dort hätte man gesehen, dass sich die Karten stapeln und dass die Spalte “acceptance test”, die dem Product Owner gehört, leer bleibt.
Das wäre äquivalent, doch hätte man ständig eine leere Spalte gehabt.
Gruß,
Matthias
“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.”
Vielleicht, nämlich dann wenn mehrere User Stories in Arbeit sind, was für sich schon ein Smell ist. Das zeigen als eigene Spalte kann aber auch das Signal geben: Das SOLLTE ein eigener Arbeitsschritt sein. Und wollen wir nicht am Ende alle Spalten bis auf zwei (backlog, in work) loswerden? Nur dann haben wir nämlich die Menge des WiP minimiert – auf 1. Und dann sind wir wieder bei einem einfachen Scrum-Board.
Ob “mehrere Stories in Arbeit” ein Smell sind oder nicht, hängt m.E. davon ab, wie viele Leute das Team hat, wann es an etwas arbeitet, was das eben genannte Wort “etwas” eigentlich bedeutet und ob bzw. wie viele Rollen (1 oder mehr) es im Team gibt. Ich mache mal ein Beispiel:
Das Team habe z.B. 7 Leute (3 cross functional Pairs plus ein Tester). Ein Pair könnte eine Story analysieren (bedeutet: Daten- und UI-Bedarf feststellen, mit dem P.O. Akzeptanztests schreiben, Story in Tasks zerlegen). Zwei andere Pairs könnten währenddessen bereits analysierte Stories entwickeln und sobald sie spielen, in eine Queue für den Akzeptanztest stellen. Der Tester könnte mit dem P.O. gemeinsam (sobald dieser anwesend ist) bereits entwickelte Stories akzeptanztesten.
Dann hätten wir möglicherweise folgende Spalten und WIP-Limits:
Analyse (1)
Entwicklung (2)
Klar zum Akzeptanztest (Queue, Länge 3, weil P.O. nur sporadisch da ist)
Akzeptanztest (1)
Done (unlimitiert)
Insgesamt hätte dieses System WIP = 1+2+3+1 = 7
Bei kleinen Stories mit einer Cycle-Time von 2 bis 3 Tagen käme man mit WIP=7 auf eine Lead Time von möglicherweise 7*(2 bis 3)=14 bis 21 Tagen.
Das wäre dann schon ein recht “scharf” eingestelltes Kanban-System für reife Teams. Etwas unreifere Teams brauchen größere WIP-Limits, mit dem Ziel, sie dann sukzessive zu verringern.
Zu Deiner Frage “Und wollen wir nicht am Ende alle Spalten bis auf zwei (backlog, in work) loswerden?”: Bei einer solch kleinen Lead Time sehe ich keinen Bedarf, die Spalten weiter zu verringern.
Bei der Konfiguration, die Du vorschlägst (2 Spalten, die erste durch Wetter von gestern limitiert, die zweite mit WIP-Limit=1) müssten sich die Team-Mitglieder offenbar so toll ergänzen, dass sie alle an einer Story arbeiten können. Und die Story müsste so klar sein, dass sie kaum Analyse braucht, denn sonst würde man in Deiner Konfiguration mit 2 Leuten an einer Story herumanalysieren während die anderen 5 Leute nichts tun.
Achso, nein, ich vergaß, Ihr macht ja Scrum und analysiert im Sprintplanungsmeeting alle 10 Stories für den Sprint gemeinsam, also vorübergehend WIP=10 oder so? Und dann in den Sprint gehen und mit WIP=1 weitermachen? Dann dem P.O. am Sprint-Ende alles zum Testen geben, der hat dann wieder WIP=10, während das Team den nächsten Sprint mit WIP=1 weitermacht.
(Sei nicht böse, ich necke Dich bewusst mit einem sehr spitz formulierten Beispiel).
Du siehst, es geht mir um den gleichmäßigen Flow, nicht plötzlich 10 und dann wieder 1 und wieder 10, sondern im Durchschnitt 7, ein erträgliches Maß, das aber schon anspruchsvoll ist.
“Mehrere Stories in Arbeit” sind für mich immer ein Smell; manchmal stinkt er so sehr, dass ich ihn loswerden möchte, manchmal nicht.
Zum Rest: Flow und Lead Time sind aber auch keine Werte an sich. Sobald du parallel an Aufgaben arbeitest und sobald du mehrere Arbeitsschritte mit irgendeiner Art der Übergabe hast, opferst du Integrität (im Sinne von Lean’s “Build integrity in”). Das mag der richtige Trade-Off in manchen Fällen sein, in vielen Fällen ist aber genau Integrität das größte Problem, meistens versteckt hinter dem Satz: “Wir haben Qualitätsprobleme/zu viele Bugs”.
Ob man vorher Zeit und Geld in Analyse und Schätzung investiert, hat damit zu tun, ob eine Schätzung – und die damit verbundene Möglichkeit Zusagen zu machen – einen Geschäftswert liefert. Im Standard-Scrum ist das die Default-Annahme, man muss das aber nicht tun.
Bei uns arbeiten momentan 13 Leute auf Basis eines Kanban-Boards. Wäre es da nicht hochgradig unvernünftig “one-piece-flow” einzufordern?
Eigentlich ist es mein langfristiges Ziel (oder Traum?), dass all unsere 60 Leute plus POs usw. auf einem Kanbanboard arbeiten. Gute Nacht One Piece Flow.
Ich sage das vor allem um deutlich zu machen, dass hier eine vollkommen andere Perspektive liegt als bei Scrum oder XP. Und auch, dass man vieles von der Eleganz und der Mächtigkeit von Kanban nicht versteht, wenn man immer die klassische agile Brille aufhat und alles haben will wie vorher, aber eben mit Kanban.
Kanban erlaubt Dir eben, Deine (Vor?-)urteile über Board zu werfen und zu untersuchen, welches WiP-Limit das richtige für Deine Organisation ist. Es lässt dich auch untersuchen, welche Teamgröße richtig ist. Welcher Work-Flow besser funktioniert, usw. Und das in einer riesigen Klasse potentieller Organisationen. Es gibt ja recht gut beschriebene Beispiele von Videospielproduktion, bei denen Du es einfach vergessen kanst, die Disziplinen aufzulösen und die Team-”Magie” hochgradig qualifizierter Entwickler zaubern zu lassen.
Der Witz bzgl.der Übergaben bei Kanban ist ja u.a., dass der Übergang von einer Kolumne zur anderen nicht unbedingt eine Übergabe sein muss. Anstatt allerdings die (oft unberechtigte) Standardannahme zu treffen “in work” reicht aus, untersucht Kanban eben den Workflow (den es ja nunmal auf irgendeinem Level implizit gibt) und schaut genau nach, welche Schritte zu viel sind, ob zusätzliche sich lohnen usw.
meine provokative These ist ja, dass Kanban eine Verallgemeinerung von Scrum ist: Anstatt durch Sprint gekoppeltem Input und Output ist dies hier eben entkoppelt (und damit der Sprint also der Sonderfall). Die weitere Einschränkung ist, dass Scrum der Sonderfall ist, indem mein Workflow Erzwungenermassen nur 2-3 Spalten zulässt.
Meine These ist, wenn ich Kanban auf ein funktionierndes Scrum-Team aufstülpen würde, würde das Scrumteam im Laufe der zeit einen wesentlich flexibleren Prozess mit Kanban erzuegen, der irgendwann nicht mehr viel mit Scrum zu tun hat aber mehr liefert, schlichtweg weil Grundannahmen von scrum hinterfragt und in der Praxis überprüft würden. (Und natürlich weggeworfen falls als unnütz erwiesen und andere hinzugefügt, die sich als nützlich erweisen.)
Ach, es gibt so viel dazu zu sagen. Mir hat die Lektüre von “Don Reinertsen – Principles of Product Development Flow” ganz stark geholfen das alles mit neuen Augen zu sehen.
Hmmm, Johannes, ich weiß, was Du mit dem Smell meinst … Wenn sich jemand nicht so richtig verpflichtet fühlt, guten Code abzuliefern und die Einstellung “bei mir läuft’s doch!” hat, dann ist es eher schädlich, ihn parallel an einer eigenen Aufgabe arbeiten zu lassen. In diesem Fall wird die Software möglicherweise “integrer”, wenn er in engem Kontakt mit den Kollegen an derselben Story arbeitet wie alle anderen im Team.
Ansonsten ist Flow schon ein Wert. Es verbessert die Voraussagbarkeit, und das ist es doch, was der Kunde schätzt. Ich habe schon oft Kunden gesehen, die hatten kein Problem damit, wenn Entwickler lange brauchen, um etwas zu realisieren. Doch wenn sie einen Termin versprachen und ihn nicht hielten, dann hatte der Kunde plötzlich eben doch eins!
Wenn Flow herrscht, nimmt die Standardabweichung der Lead Time der verschiedenen erledigten Features ab – der Prozess wird risikoärmer. Dann kann man (manchmal sogar ohne Schätzungen) dem Kunden ein solches SLA anbieten: “Wenn das von Dir gewünschte Feature die Spitze des Backlogs erreicht hat und in den Prozess wandert, bekommst Du die Umsetzung von da an erfahrungsgemäß in 25 Tagen.”
Gutes Gefühl für beide Seiten, oder?
Wow, Markus, Du gehst ja richtig in die Vollen!
Wenn wir gerade beim Provozieren sind, da hab ich noch einen von David P. Joyce, der Kanban bei der BBC eingeführt hat:
Der Verweis auf Reinertsen ist gut – ich muss es noch einmal lesen.
Oh, ich wollte nicht provozieren. (Auch nicht letztens bzgl. System usw. Sorry, falls es so ankam.)
Den Reinertsen kann und konnte ich leider immer nur in Häppchen konsumieren weil er so abstrakt und doch angewandt ist. Aber ich liebe ihn. Man sieht auch direkt, wie elegant Kanban viele seiner Thesen direkt unterstützt.
Das David Anderson Buch wird wohl auch einiges klären für die, die es wollen.
Das Joyce-Zitat trifft es in der Tat.
Ich finde z.Bsp. dass man mit einer tollen Lead Time und Featurereleases in Verbindung mit der evtl. unternehmensweiten Transparent so viel Erfolg erzeugt und Vertrauen geschaffen hat, dass man evtl. lähmende Konstrukte wie Sprints gar nicht mehr baucht und auf einer ganz anderen Ebene zusammenarbeiten kann.
Wobei ich nicht sage dass das einfach zu erreichen ist und die Kommunikation und das Werben dafür bis dorthin komplex sind.