Auftakt: Dies ist ein Blog-Beitrag zum Modul “Agile Methoden” des Bootcamp Product Owner der Digitale Leute School. Am Dienstag, 07. November 2023, beschäftigte sich David Pereira mit den Ritualen und Regelterminen (bei Scrum), Teil 2, dieses Mal mit dem Refinement, Review und mit der Retrospective.
Und ich finde, das mit den Events und Nicht-Events zeigt erneut sehr gut, dass man den SCRUM-Guide nicht zu sklavisch befolgen sollte. Das ist im Prinzip auch die durchgehende These von David bei dieser neuen Session zu “Ritualen und Regelterminen II” beim Digitale-Leute-Bootcamp.
Refinement: Wichtig für die Sinnhaftigkeit
Und um jetzt nicht zu lange auf die Folter zu spannen: Das Refinement gibt es nicht als Event bei SCRUM, sondern das wird nach Guide fortlaufend gemacht. Einfach auch, um noch mal einen Querverweis zu geben: Sandra Hinz, eine andere Trainerin des Bootcamps, macht es zum Beispiel häufiger vor dem Sprint Planning. Und David empfiehlt, es nach Bedarf zu machen.
Um das einfach hier auch noch mal zu betonen: Eine sehr große Stärke des Bootcamps ist es gerade, dass unterschiedliche Trainerinnen und Trainer auch ihre unterschiedlichen Erfahrungen in das Bootcamp einbringen. Es gibt eben nicht den einen richtigen und den einen falschen Weg. Stelle Dir Deine perfekte Refinement daraus selbst zusammen 😉
Als Negativ-Beispiel erzählt David von einem Refinement, welches jeden Tag für etwa eine Stunde gehalten wurde – und zwar deshalb, weil ein Product Owner sagte, das entspricht dem SCRUM-Guide, 10 Prozent der Arbeitszeit darauf zu verwenden. Unabhängig davon, dass das so nicht stimmt, ist es natürlich für alle Beteiligte einfach verschwendete Zeit. Aber noch viel wichtiger ist eine viel zitierte Formel auch in der agilen Welt:
Garbage in = Garbage out
Sprich: Man kann noch solange refinen, wenn die Ziele und Ideen und damit letztendlich auch die User Stories nicht stimmen, bringt das alles nichts. In der Tat ist das eines der zentralen Probleme mit vielen Frameworks: Viele verwenden die Prozesse und Methoden beinahe sklavisch und denken dann: Jetzt haben wir Erfolg. Die Prozesse und Methoden bieten ein Gefühl der Sicherheit. Aber das stimmt eben nicht: Die Gefahr, dass man sich zu sehr darauf verlässt, ist groß. Und es schützt mitnichten davor, ohne Ende den falschen Ideen hinterherzurennen. Ich finde, das kann man sehr gut in der Start-Up-Szene beobachten.
- Wann? Laut Guide während des Sprints
- Wie oft? Laut Guide nach Bedarf
- Wie lang? Laut Guide keine Empfehlung
David hat dafür eine eigene Empfehlung: “Nicht zu oft und nicht zu lange.” Und: Je kürzer, desto besser. Als Best Practise empfiehlt er, am Anfang vielleicht darauf eine Stunde pro Woche zu verwenden und später 1,5 Stunden für 2 Wochen. Und noch eine andere Empfehlung hat er: Items können mehrfach refined werden. Und dafür gibt es auch einen einfachen Grund: Sie müssen für den Sprint frisch in den Gedanken sein. Und: Wenn die Items schon etwas älter sind hat sich auch der Kontext geändert. Als Rahmen empfiehlt hier David erneut die INVEST-Kriterien.
Tooltipp: T-Shirt-Size: Die Story Points sind eine beliebte Methode, den Aufwand teamspezifisch zu diskutieren. Eine Alternnative dazu ist die Methode T-Shirt-Size. David macht es immer vom Team abhängig, was er einsetzt. In der Tendenz führt seiner Erfahrung nach die T-Shirt-Methode schneller zu Konsens im Team, ist aber auch eher für erfahrene Teams geeignet.
Und noch ein Tipp von David: Er schmeißt Items – also User Stories -, die keinen Wert haben, sollten aus dem Backlog entfernt werden. Bei User Stories entscheidet er das in einer Kette aus Why – Problem – Ziel – und Wert.
Als Ablauf für ein Refinement empfiehlt David Product Ownern:
- Vorbereitung einen Tag vorher, sprich: Kritische Blick auf die User Stories
- Problemverständnis fokussieren, also wieder das Warum und nicht das Was oder Wie.
- Abschätzung des Aufwands, wieder über einen Planning Poker
David hat auch wieder sehr viele Erfahrungswerte geteilt:
- Problemorientierung muss im Vordergrund stehen,, also das Warum
- Es müssen die “richtigen” Stories überarbeitet werden. David empfiehlt hier für die Einschätzung den Confidence Meter von Itamar Gilad.
- NICHTS ist unmöglich, das zählt nicht als Argument.
- Stories sollten nicht “technisch” gesplittet werden (zum Beispiel nach Frontend und Backend)
- User Stories sind keine Tasks: “Das Warum darf nicht zum Was werden”, rät David.
- Definition of Ready sollte nicht genutzt werden. Der Grund: Das ist zu sehr prozessorientiert.
- Es sollten Geschichten erzählt und nicht Anforderungen aufgezählt werden.
Wie das Sprint Review funktioniert
Laut SCRUM-Guide sollte im Review das Outcome (nicht der Output) überprüft werden. “Inspect the outcome”. Rein gestalterisch sollte hier nicht einfach etwas präsentiert werden, sondern es kommt auf die Interaktion an. Davids Empfehlung: Darstellen, was gelernt worden ist (Outcome; vielleicht auch 1 bis 2 Sprints vorher Revue passieren lassen) und danach darstellen, was dabei herausgekommen ist (Output). So entsteht Kontext.
- Wann? Vor der Retrospektive
- Wie oft? 1 x Sprint
- Wie lange? 2 Stunden pro Sprintwoche
Nach Davids Einschätzung ist es allerdings schwierig, wichtige Stakeholder für 2 Stunden und länger zu bekommen. Deshalb sollte es auch so kurz wie möglich gehalten werden. Ein großer Fehler ist es, einfach den Statusreport etwa aus Jira vorzulesen oder daraus eine Präsentationsshow des Product Owners zu machen. Deshalb empfiehlt David auch einen Ablauf:
- Product Owner eröffnet das Review.
- Developer präsentieren die Resultate.
- Developer klären über die Mission auf.
- Es folgt Interaktion und Learnings zusammen mit den Stakeholdern.
- Product Owner gibt einen kurzen Ausblick auf den kommenden Sprint.
Die Sprint Retrospective: Reflexion der Arbeit
Teambuilding ist ja nicht erst eine Erfindung von SCRUM oder anderen agilen Frameworks oder von NewWork. Teambuilding hat eine ganz alte sozialpsychologische und organisationssoziologische Wissenschaftstradition. Und natürlich ist es seit jeher gut, mal darüber offen zu sprechen, was jenseits der Inhalte in der Zusammenarbeit verbessert werden kann. Das ist überhaupt keine neue Erkenntnis und eigentlich sollte das in Unternehmen auch jenseits agiler Frameworks eine Selbstverständlichkeit sein. Ist es aber nicht, das ist das frustrierende daran. Sogesehen ist es sehr gut, dass SCRUM zumindest auf der operativen Ebene diesen Meta-Austausch so massiv betont – und in Form der Retrospective auch institutionalisiert.
Wie immer ist SCRUM aber in dieser Institutionalisierung sehr dogmatisch (was ich, wie immer, nicht so überzeugend finde). Konkret wird hier gefordert:
- Wann? Am Ende des Sprints
- Wie oft? 1 Mal pro Sprint
- Wie lange? 1,5 Stunden/Sprint-Woche
- Wer? Entwicklungsteam
Mit dogmatisch meine ich: 1,5 Stunden/Sprintwoche ist Vorschrift; im Test zum SCRUM-Master wird genau das abgefragt… In anderen Dingen bleibt der SCRUM-Guide dann leider wieder vage; gut das David hier seine Erfahrungen und Empfehlungen gibt:
- Leitung der Retrospective: Das kann wechseln/rotieren
- Wichtig ist, dass es Konsequenzen aus der Retrospective gibt, “Actions” nennt David das
- vorgetäuschte Harmonie hilft niemandem weiter
Konkret empfiehlt er für die Struktur und den Ablauf:
- ICE-Breaker: Hier geht es darum, das Team nach einem anstrengenden Sprint wieder einen neuen Anfang zu ermöglichen. Tatsächlich gibt es 1 Milliarde Ice-Breaker-Methoden (einfach mal googeln…). In unserem Team haben wir damit geliebäugelt, das Wort mal wörtlich zu nehmen, uns als Team in ein Eiscafé zu setzen, jeder bestellt ein Eis und beschreibt, was der Geschmack des Eises mit dem letzten Sprint zu tun hat. Andere Ideen: Welchen Song verbindest Du mit dem letzten Sprint? Welches Bild? Mit welchen drei Wörtern würdest Du den letzten Sprint beschreiben?
- Review der vorherigen Konsequenzen: Schon nach dem letzten Sprint hat es eine Retrospective gegeben und hier wurden 3 neue Konsequenzen diskutiert – und hoffentlich auch im Sprint umgesetzt. Entsprechend ist es interessant, zu erörtern, was sich geändert hat und wie das zu bewerten ist.
- Diskussion – Retro Dynamics: Ziel ist es, nun die Stimmung im Team einzufangen, zu sammeln und auch zu besprechen – und am Ende auch Konsequenzen daraus zu ziehen. David empfiehlt hierfür in der Session 4 Methoden: Sailboat, Mad/Sad/Glad, 4L (Liked, Learned, Longed for, Lacked) und eine Methode, bei der die Teammitglieder auf einer Zeitleiste (Anfang bis Ende) jeweils Punkte mit ihrer Stimmung (bad to glad) einschätzen sollen. Wichtig hierbei: Es sollte hier immer mit einem individuellen Brainstorming begonnen werden und erst im Anschluss sollten die Dinge zusammengetragen und diskutiert werden. In unserer Gruppe haben wir diesen Punkt sehr intensiv diskutiert und zum Beispiel auch bemerkt, dass es vom Gefühl der Sicherheit, aber auch von dem Erfahrungsgrad der Gruppe abhängen mag, wie offen und ehrlich hier die Antworten sind. Vielleicht sind es bei unerfahreneren/neueren Teams anfangs mehr die funktionalen Kritikpunkte und später sind es auch mehr emotionale? In jedem Fall: Google schmeißt bei der Eingabe von Retrospektive Methoden eine Vielzahl weiterer Ideen aus.
- Konsequenzen: Es sollten drei Konsequenzen/”Actions” bestimmt werden, die im nächsten Sprint verbessert werden.
- Time Out: David empfiehlt auch noch eine Art Ausklang. Beispielsweise eine Emoji-Bewertung des Sprints etc. Ich finde, da es sich hierbei um ein Teambuilding-Event handelt, ist es noch netter, irgendwas gemeinsam zu machen. Ist ja schließlich auch bei dann 3 Stunden Beisammensitzen eine willkommene Abwechselung. Da passt dann eigentlich alles, was Spaß macht.
Tatsächlich bekommt die Retrospektive durch diese Struktur einen Workshop-Charakter mit Visualisierungs- und Kreativelementen. Das finde ich sehr reizvoll (und verhindert, dass alle gelangweilt drei Stunden zusammensitzen). David empfiehlt auch – und das sehe ich genauso -, dass man ruhig für den ICE-Breaker und die Retro Dynamics aus dem großen Pool an unterschiedlichen Methoden und Tools immer eine andere auswählen sollte. Denn der einzige Sinn dieser Methoden ist es, Impulse zu setzen: Es gibt hier deshalb kein richtig oder falsch.
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!