report-stories

Von Scrum zu Kanban – why we did it

Ein Erfahrungsbericht eines gebeutelten Product Owners, der seine Glaskugel verloren hat.

von  Jan Segers
25.02.2020

Scrum, Kanban, Scrumban – Teams können heutzutage aus einer großen Anzahl verschiedenster agilen Frameworks das Richtige für sich wählen. Aber gibt es überhaupt das “richtige” Framework? Wann wird es Zeit, etwas Neues zu probieren? Ein Erfahrungsbericht eines gebeutelten Product Owners, der seine Glaskugel verloren hat.

Spoiler Alert

Um die Frage vorweg zu beantworten: Es gibt nicht “das” Framework, welches alle Teams gleichermaßen glücklich macht. Aber natürlich gibt es Frameworks, die je nach Team-Setting mal besser, mal schlechter geeignet sind. Und keine Sorge, dies wird keiner der x-beliebigen Scrum vs. Kanban-Artikel. Ich plaudere lieber aus dem digitalen Nähkästchen und vermittle den ein oder anderen Denkanstoß.

Es war einmal…

… ein Team, wie es im Scrum-Bilderbuch steht: Product Owner, Scrum Master und sechs Entwickler. Dieses Team war maßgeblich verantwortlich für einen sehr zentralen und somit geschäftskritischen Service innerhalb der REWE digital. Zusätzlich bestand die Herausforderung, dass dieses Team meistens mit involviert war, wann immer ein neues Feature entwickelt wurde. Die Folge: Ich als Product Owner war bei so ziemlich jeden Sprint gezwungen, diesen nachträglich anzupassen, da bestimmte Themen plötzlich kurzfristig wichtiger waren als die vorher geplanten - natürlich immer unter Absprache mit dem Team. 

Auch wenn das Team Verständnis für unsere Lage und die daraus resultierenden konstanten Scope Changes hatte, waren die Kollateralschäden immens. Sprint-Ziele wurden meist nicht erreicht und Stories mussten ad-hoc geplant werden. Der Zenit unserer Schmerzen wurde erreicht, nachdem wir in einer Retrospektive festgestellt hatten, dass innerhalb der letzten sechs Monate jeder (!) Sprint einen Scope Change erfahren hatte.

Embrace the pain

Die oben beschriebene Situation gleicht einem schlechten Film, war aber unsere Realität. Gerade für mich als Product Owner war das Setup nicht länger tragbar, da das Team aufgrund der ständigen gerissenen Sprints keine auch nur ansatzweise verlässliche Velocity produzieren konnte und ich somit unfähig war, irgendwelche Aussagen zu unserer Delivery geben zu können. Nach einigen Gesprächen mit anderen Teams sowie Agile Coaches beschlossen wir, aus unserer Not eine Tugend zu machen, Sprints abzuschaffen und auf Fluss zu optimieren.

Scrum + Kanban = Scrumban?

Rückblickend haben wir eigentlich nur das, was wir als Team in unserem Daily Business ohnehin machen mussten, explizit gemacht. Wir haben Sprints abgeschafft, da deren Scope kontinuierlich angepasst werden musste. Wir haben wöchentliche Refinements eingeführt, da wir in kürzeren Zyklen neue Arbeit schätzen mussten. Wir haben die beiden Sprint Plannings abgeschafft und durch just-in-time Plannings auf Story-Ebene nach dem Daily ersetzt. Und zu guter Letzt haben wir ein WIP Limit eingeführt, wir machen ja schließlich jetzt Kanban ;-) Scherz beiseite, aber das WIP Limit hat uns dazu gezwungen, nicht auf zu vielen Hochzeiten gleichzeitig zu tanzen, sondern nur auf den wichtigen. Und nicht auf denen, in die man einfach nur reinschlittert, weil man‘s kann. Dies gilt übrigens auch im echten Leben.

Und wie ist das jetzt mit der Velocity?

Dem aufmerksamen Lesenden mag aufgefallen sein, dass dieser Bericht von einem Product Owner geschrieben wurde. Und was muss ein PO können? Richtig, er muss irgendwie in der Lage sein, seinen Stakeholdern ein möglichst realistisches Forecasting zu geben. Kurz gesagt: „Wann ists fertig?“. Mit der Abschaffung der Sprints entfiel auch die Velocity – es gab ja keine Messgröße mehr. Stattdessen haben wir für jede Story die Durchlaufzeit gemessen, ergo die Menge an Tagen von der ersten Zeile Code bis zum Rollout auf Produktion.

Forecasting – Level 1

In der ersten Iterationsstufe hatte ich als PO pro Story, die wir geschafft hatten, die Anzahl der Tage dokumentiert. Wirklich geholfen hat mir das aber nicht – zwar konnte ich jetzt unseren Stakeholdern sagen, wie lange es dauert, bis wir eine Story auf Produktion gebracht haben, aber die Aussage war relativ vage. Manche Stories hatten wir innerhalb eines Tages angefangen und ausgerollt, andere Stories haben teilweise jedoch mehr als drei Wochen gedauert. Verständlich, dass auf die Frage „Wann ist die Story fertig?“ meine initiale Antwort mit „In ein bis zwanzig Tagen“ eher für Irritation gesorgt hat als für leuchtende Gesichter ... 

Forecasting – Level 2

Back to square one. Die einzige Segmentierungsmöglichkeit, die mir out of the Box zur Verfügung stand, war die Anzahl der Story Points, die wir nach wie vor noch in unseren Refinements für jede Story geschätzt haben. Mir ist bewusst, dass man unter allen Umständen vermeiden sollte, Komplexität und Zeit in Korrelation zu setzen, aber wenn ich mir die Daten, die ich im letzten Jahr gesammelt habe anschaue, dann ist meiner Meinung nach eine deutliche Korrelation zwischen Komplexität einer Story und ihrer Durchlaufzeit erkennbar.

Reden ist Silber, Daten sind Gold. Daher repräsentiert das untenstehende hellblaue Diagramm die Anzahl der Tage, die wir für jede Story mit fünf Story Points benötigt haben und das hellgrüne Diagramm die Anzahl der Tage, die wir für jede Story mit acht Story Points benötigt haben. Natürlich gibt es in beiden Kategorien Ausreisser nach oben wie nach unten. Es ist trotzdem gut erkennbar, dass eine Story mit fünf Story Points im Schnitt kürzer dauert als eine Story mit acht Story Points. Somit ist eine Korrelation zwischen Komplexität und Zeit gegeben, man kann jedoch keine allgemeine Aussage hieraus ableiten.

Was hat die Segmentierung auf Basis der Story Points nun im Alltag gebracht?

All-in-all hilft sie dabei, den “von-bis”-Korridor näher einzugrenzen. Nehmen wir das obige 5 Story Point-Beispiel: Es gab zwar einige Ausreißer nach ganz oben, aber der Großteil der Messwerte bewegt sich in einem Korridor von zwei bis zehn Tagen. Würde ich als PO sämtliche Messwerte nehmen und meinem Stakeholder nun kommunizieren, dass seine 5 Story mindestens einen und maximal 22 Tage dauert, bis sie auf Produktion ausgerollt ist? Natürlich nicht, da es offensichtlich ist, dass diese 22 Tage ein Ausreißer waren. On top verdeutlichen die Messwerte, dass es fatal wäre, einfach nur den Mittelwert zu bilden und diesen zu kommunizieren. Warum? Nun, in besagtem Beispiel wäre der Mittelwert vermutlich 5-6 Tage. Wenn ich diesen Wert an meinen Stakeholder kommunizieren würde, dann läge ich damit in 80 % der Fälle falsch. Schließlich liegen die Messwerte in 80 % der Fälle nämlich nicht bei 5-6 Tagen, sondern auch oft genug drüber oder eben drunter. 

Bewährt hat sich für mich als PO daher, die oberen sowie unteren 10 % der Messwerte zu ignorieren und nicht in meine Aussage mit aufzunehmen. In diesem Fall würde das bedeuten, dass man alles unterhalb von drei und oberhalb von zehn Tagen ignorieren würde. Dem Stakeholder kommuniziere ich dann genau diese Drei- bis Zehn-Tagesspanne. Das ist natürlich immer noch nicht sehr genau und stellt nicht jeden Stakeholder zufrieden. Tatsächlich ist diese Aussage aber ein Spiegel der Realität.

Wer misst, misst Mist.

Natürlich gibt es eine Vielzahl an Faktoren, die diese Messwerte beeinflussen (Teamstärke, Urlaube, Krankheitstage, …). Letztendlich habe ich als Product Owner vor allem die Erkenntnis gewonnen, dass das Team am liebsten mit kleinen Stories arbeitet. Diese werden besser verstanden – und haben somit eine deutlich konstantere Durchlaufzeit. Letztendlich ist Konstanz genau das, was mir als PO speziell beim Forecasting hilft. Ich habe daher als Reaktion auf diese Messwerte meine Stories dahingehend optimiert, dass sie möglichst klein sind – ohne den jeweiligen Business Value aus dem Auge zu verlieren. 

Rückblickend betrachtet war die Transition von Scrum auf diese Form von Kanban genau das, was dem Team in seiner täglichen Arbeit geholfen hat. Sprints konnten nicht mehr gerissen werden, da es sie schlichtweg nicht mehr gab. Auch ad-hoc Re-Priorisierungen des Backlogs waren kein Problem mehr. Ist diese Methodik als Blaupause für sämtliche Teamkonstellationen zu sehen? Sicherlich nicht, aber ein Blick über den Tellerrand lohnt sich allemal!

Nächste Story in : report-stories

Code Katas und Coding Dojos: Auch Software-Entwickler üben

Stefan Scheidt & Ansgar Himmel

Suche hier nach Stories, Jobs und Themen…

Zurück
question mark
Hoppla!
Leider konnten wir unter dem von Dir gewünschten Suchbegriff keine Ergebnisse finden.