Auftakt: Dies ist ein Blog-Beitrag zum Modul “Agile Methoden” des Bootcamp Product Owner der Digitale Leute School. Am Freitag, 27. Oktober 2023, beschäftigte sich David Yasli mit den Ritualen und Regelterminen (bei SCRUM), Teil 1.
Im Rahmen des Bootcamps haben wir schon einige Modelle kennengelernt, wie sich die Strategieebene mit der operativen Ebene verknüpfen lässt. Das Flight-Level-Model von Klaus Leopold ist ein weiteres.
Flight-Level-Model erklärt
Immer wieder wird bei solchen Modellen betont, dass sie selbst agil sein müssen, nicht erstarren sollen. Sprich: Rückkoppelungen müssen irgendwie möglich sein. Und solche oder ähnliche Drei-Stufen-Modelle, wie das Flight-Level-Model, sind ja auch eingängig: Oben steht die strategische Ebene, unten die operative. Und in der Mitte gibt es eine Koordinationsebene. Das Bild von Flugebenen ist dabei eingängig. Es beschreibt bildlich die Flughöhe eines Flugzeugs. Konkret ist das beim Flight-Level-Model:
- Level 3 – Strategie: Das ist die höchste Flugebene. Hier ist großer Weitblick gefragt. Die Details “am Boden” verschwimmen aber immer mehr, geraten aus dem Blick.
- Level 2 – Koordination: Das ist sozusagen der Kit zwischen Level 3 und Level 1. Einerseits muss ein gewisses Verständnis für die Strategie da sein, andererseits ist auch Wissen über die operative Umsetzbarkeit hilfreich. Im Prinzip muss Level 2 in die anderen Ebenen hinein vernetzt sein, dort auch teilnehmen.
- Level 1 – Auslieferung: Das ist die Ebene, die sich mit den Details am Boden auseinandersetzt. Der Blick reicht bis zur nächsten Häuserwand, aber eben nicht darüber hinaus. Hier ist vielleicht am Ehesten das SCRUM-Team angesiedelt.
David verortet den Product Owner in Level 1 und Level 2. Letztendlich ist dennoch unklar, wie genau sich Level 2 ausgestaltet, wie exakt sich die Rückkoppelungen institutionalisieren lassen. Vielleicht am Ehesten ist noch klar, wie die Auslieferungsebene funktioniert, nämlich “am Einfachsten” über SCRUM. Und tatsächlich geht es in der Session ja auch vor allem um diese agile Implementierungswelt.
Im Zuge der Diskussion gibt David noch eine interessante Einschätzung ab:
“Parallelisierung von Arbeit führt zwar zu hohen Auslastungen, aber verzögert durch steigenden Abstimmungsbedarf das Outcome und verringert es.”
(David Yasli)
Er sagt damit im Prinzip, dass man ein Team lieber pausieren lässt, als es im Rahmen eines Projekts schon mit zukünftigen Aufgaben voranschreiten zu lassen. Parallelisierung bedeutet also etwas überspitzt formuliert: Während Team A und Team B noch in der ersten Phase eines Projekts sind, ist Team C schon in der zweiten, weil es sonst einfach “nicht arbeiten” müsste. Dadurch, so David, baut sich aber ein immer höherer Abstimmungsberg auf, der am Ende die ganze Arbeit behindert. Es ist ja auch nicht so, dass ein Team, welches für einen 2-Wochen-Sprint mal nicht eingesetzt wird, nichts zu tun hat. Im Gegenteil: Die Zeit kann genutzt werden, Generelles zu verbessern.
Aber ich kenne das Gefühl der Chefs und Angestellten: Ich hatte in meiner Jugend mal einen Malocherjob in einer Fabrik die Rohrflansche mit Rohren verbunden hat. Dort musste ich Prägestempel setzen. Wenn ich mit einer Fuhre fertig war, hatte ich nichts zu tun (denn der Vorarbeiter hat mich nicht beliefert, weil ich sonst den Akkord kaputt gemacht hätte). Aber nichts tun geht natürlich nicht… Also habe ich mir einen Besen geschnappt, und vermutlich hatte ich nach einer Woche den saubersten Arbeitsplatz der ganzen Welt. Das wäre quasi ein Gegenargument gegen die Argumentation von David: Am Ende muss man was Arbeiten, auch wenn es sinnlos ist…
Aber ich finde das einen sehr interessanten Gedanken, den ich mir so bisher noch nicht gestellt habe.
Sprint Planning: So funktioniert es
Einen Großteil der Session haben wir uns dann mit dem Sprint Planning und den dazugehörigen Elementen/Methoden beschäftigt. Und da es sich hier anbietet, fasse ich ein paar Sachen mal als Bullet Points zusammen:
- Tool: Product Backlog
- Ziel: Konsens herstellen
- Ergebnis: Sprintziel (mit User Stories); hierzu haben wir uns dann später mit Storypoints beschäftigt. Das Sprintziel sorgt auch für eine Priorisierung und für eine “Definition of Done”.
- Länge: 2 Stunden/Sprintwoche, also bei einem zweiwöchigen Sprint zum Beispiel 4 Stunden
- Voraussetzung: “Definition of Ready” (es besteht ein gemeinsames Verständnis der User Stories), Velocity
- Umfang der Aufgaben: Muss in einem Sprint umsetzbar sein.
- Planungsteilnehmer: Product Owner, Developer Team, SCRUM-Master, Stakeholder
Zentral ist dabei immer die Frage: Was ist der Wert (für den Nutzer)? Oder ich formuliere es mal um: Marktunfähige Items sind ungeeignet für einen Sprint. Ich glaube, dass dieser Satz sehr schnell dahergesagt ist und in der Praxis doch einiges an Brisanz und Umsetzungsproblematik bietet.
Rolle des Product Owners: Er kümmert sich um die Epics, User Stories und die Priorisierung, aber NICHT darum, wie lange die Umsetzung dauert oder wie sie umgesetzt werden. Gleiches gilt natürlich auch für eventuell anwesende Stackholder. Das Sprint Planning ist ein zentraler Termin für den Austausch mit dem Entwicklerteam.
Interessant finde ich auch den Vorschlag von David, das Planning in zwei Teile zu unterteilen:
- Planning 1: Was ist zu tun? Hier wird in der großen Gruppe diskutiert.
- Planning 2: Wie ist es umzusetzen? Hier trifft sich dann nur noch das Developer-Team.
Um noch einmal näher auf die konkreten User Stories einzugehen: Sie müssen messbar sein und sollten nicht zu abstrakt sein, sprich: Die “Definition of Done” muss eindeutig sein. Das erinnert auch sehr an OKR.
Als Beispiel: “Die Ladezeit der Anwendung ist im Monatsmittel um 20 Prozent geringer als der aktuelle Durchschnitt von 5 Sekunden.” Das ist recht spezifisch und recht gut messbar. Ob dieses Ziel überhaupt sinnvoll ist, steht auf einem anderen Blatt (und sollte immer auch kritisch hinterfragt werden).
Was ist die Velocity?
Es gibt ja immer wieder Begriffe, um die ich mir zuvor wenig Gedanken gemacht habe. Und ich finde gut, wenn solche Themen aufgegriffen werden. Eine davon ist die Velocity. Und die sind eng verknüpft mit den Storypoints.
Aber von Anfang an: Storypoints geben die Entwickler selbst als Einschätzung ab, wie aufwändig die Umsetzung einer User Story in SCRUM sein mag. Sie sollten dabei folgende Dinge berücksichtigen:
- Risiko: Wie hoch ist das Risiko der Umsetzung, etwa, weil dafür Tools verwendet werden, die noch nicht etabliert werden?
- Wiederholung: Wie häufig wurden ähnliche Aufgaben (mit den gleichen Tools) schon erledigt?
- Komplexität: Wie komplex ist die Aufgabenstelle? Vielleicht ist sie auch zu komplex, dann sollte die User Story aufgeteilt werden. Es gilt die Regel, Aufgaben klein zu halten.
David betont, dass die Story Points nicht ein irgendwie normierter Wert sind, sondern aufgrund von sehr subjektiven Entscheidungen vergeben werden. Sie passen damit nur auf jeweils ein Team und lassen sich auch nicht über Teamgrenzen hinweg vergleichen. Ich glaube, das ist ein wichtiger Hinweis, denn der eine oder andere Chef versteht das sicherlich falsch…
Aber dennoch stellt sich natürlich die Frage, wie konkret die Story Points vergeben werden sollten. Und David schlägt dafür eine Anlehnung an die Fibonacci-Folge vor:
| Angelehnt an Fibonacci | Lineare Folge |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 5 | 4 |
| 8 | 5 |
| 13 | 6 |
| 20 | 7 |
| 40 | 8 |
Der Grund dafür ist recht einfach: Es wird durch den größeren Abstand zwischen den Zahlen deutlich die höhere Komplexität visualisiert. Es wirkt einfach anders, wenn man 40 Storypoints vergibt, als 8.
Dann geht es um Teambuilding/gruppendynamische Prozesse. Ich habe ja Sozialwissenschaften studiert und hier – insbesondere in der Organisationssoziologie und Sozialpsychologie – haben wir uns auch schon vor 25 Jahren intensiv mit solchen Dingen auseinandergesetzt. Generell an der agilen Welt mag ich nicht, dass hier immer wieder die gleichen Ideen dazu wie eine Kuh durchs Dorf getrieben werden. Als Beispiel: Die Pizza-Regel von Jeff Bezos oder auch die 7+/-2-Regel von SCRUM ist absolut keine neuzeitliche Erfindung dieser Personen, sondern wurde schon vor Jahrzehnten wissenschaftlich untersucht. Allerdings ist die Forschung dabei NICHT stehengeblieben: So gibt es zum Beispiel auch zahlreich Forschung zu inner- und outergroup-Verhaltensweisen oder auch zu struktur-funktionalistischen oder eher individualistisch geprägten System – der ewige Konflikt zwischen der Mikro- und Makro-Soziologie: Bestimmt das Individuum das System oder das System das Individuum? Und um es einfach auch hier mal zu sagen: Die perfekte Antwort gibt es hier nicht!
Sogesehen finde ich das Phasenmodell von Tuckman/Klotz interessant, aber es kann meines Erachtens nicht der Gipfel der Erkenntnis sein! Es ist von 1965!!! Zumal – wie immer bei Modellen – sich auch die Frage der konkreten Anwendbarkeit stellt. Aber hier einfach noch mal kurz zusammengefasst, wie das Modell Teamentwicklung beschreibt:
- Forming: Hier findet sich ein neues Team zusammen. Es läuft in völlig unterschiedliche Richtungen.
- Storming: Es tauchen erste Konflikte im Team auf, etwa, weil Aufgaben nicht identisch verstanden werden und Profilierung der eigenen Person im Teamkontext vielleicht auch eine Rolle spielt.
- Norming: Man hat sich auf eine Art Arbeitsmodus geeinigt. Natürlich ist man sich nicht in allen Punkten grün, aber eine bessere Definition der eigenen Rolle im Team ist eingetreten.
- Performing: Auf dieser Grundlage kann das Team nun sehr produktiv zusammenarbeiten.
- Adjourning: Und nach einem Projekt geht es nun vielleicht auch wieder auseinander, aber vielleicht nicht für immer.
Schematisch wird dieses Phasenmodell oft als ein lineares Modell dargestellt. Und ich finde das auch durchaus berechtigt, denn es sollen ja schließlich visuell die Muster herausgearbeitet werden. Aber in der Realität ist das – natürlich – Quatsch. Phasen werden sich vermischen und man wird auch mal wieder von der Performing- in die Storming-Phase zurückspringen etc. Und hier ergibt sich im Prinzip die Problematik der praktischen Umsetzung: Wie erkenne ich, in welcher Phase sich ein Team befindet? Was kann ich daran ändern? Und wie kann ich das ändern? – ein aktiver Impuls geht von diesem Modell alleine jedenfalls nicht aus.
Interessant ist vielleicht der Einfluss auf die Vergabe von Story Points: Je nachdem, in welcher Phase sich ein Team oder auch ein Teammitglied befindet, wird sich die Einschätzung der Storypoints verändern.
Und die Formel, die sich dann aus allem ergibt, ist dann die Folgende:
Velocity = Story Points + Teamphase + Anzahl der Sprintwiederholungen
So schlägt es David vor: Wobei sich dann der letzte Punkt einfach auch wiederholt, denn in den Story Points sollten ja eigentlich die Wiederholungen schon berücksichtigt sein.
So funktioniert der Planning Poker
Er ist in SCRUM nicht vorgeschrieben, hat sich aber als Tool stark etabliert: der Planning Poker. Um diesen überhaupt zu starten, sollte das Team aber zunächst eine Estimation Matrix entwickeln.
| Schwierigkeit | |||||
| leicht | mittel | schwer | sehr schwer | ||
| Anzahl an Aktionen | gering | 0-1 | 2-3 | 5 | 8 |
| mittel | 2-3 | 5 | 8 | 13 | |
| hoch | 5 | 8 | 13 | 20 | |
| Sehr hoch | 8 | 13 | 20 | 40 | |
Ich habe hier die Matrix erweitert um Story Point 40. Letztendlich ist das ja auch nur ein Orientierungsschema. In diesem Fall sind – so der Vorschlag – grüne und gelbe Felder für einen Sprint geeignet. Die Stories hinter den roten Felder hingegen müssen vielleicht aufgeteilt werden.
David betont, dass die Stories und der gesamte Planning-Prozess dafür da sind, ein gemeinsames Verständnis zu entwickeln. Sie sind also nicht ein quantifizierbares Erfolgselement.
Beim Planning-Poker gibt nun jeder Entwickler seine jeweilige Einschätzung zur User Story ab. Das geschieht individuell und verdeckt. Wenn alle Entwickler ihre Einschätzung aufgeschrieben haben, werden die Karten offen auf den Tisch gelegt. Und hier stellt sich schnell heraus, wo es große Unterschiede gibt – es findet nun eine präzisierende Diskussion statt. Davids Erfahrungswert ist, dass es meistens zwei bis drei Runden im Poker gibt. Wenn es darüber hinaus geht, ist die Story vielleicht generell nicht klar genug definiert und muss vielleicht noch einmal neu geschrieben werden.
In jedem Fall war das wieder eine sehr inspirierende und gute Session im Bootcamp.
Abschließender Hinweis: Immer ist es eine sehr subjektive Zusammenfassung, die ich hier verfasse. Siehst Du Dinge anders, möchtest darüber diskutieren – melde Dich gerne bei mir!