Review
Heute mal wieder Handfestes aus der Agilen Welt: Das Review. Ein Ritual oder eine Routine? Die unter anderem auch im Scrum Guide steht.
Diese Folge auf YouTube: https://youtu.be/-k7w4pofPpU
Perspektivwechsel
Starten tun wir heute aber mal in einem Perspektivwechsel. Henry Schneider und Janina Kappelhoff sitzen heute komplett andersherum im Studio. Was echt viel auf den Kopf stellt und gleichzeitig sind Perspektivwechsel und kleinere Interventionen sehr gut für uns. Vor allem um Neues zu lernen.
Etwas, was wir auch gern in unsere Seminare an der Znip Academy einbauen und eine Wirkung die leider oft nur im physischen Raum funktioniert.
Eine kleine Übung mit der Du Deine Flexibilität steigern kannst.
Das Review
Doch endlich rein ins Thema! Heute geht es nicht um das Performance Review der Personalabteilungen, sondern um das aus der Agilen Welt. Um genau zu sein das aus der Scrum Welt.
Beides dreht sich um eine Rückschau, also auf das, was passiert ist. Es ist also schon ganz richtig, dass beides das gleiche Wort verwendet und nur unterschiedliche Dinge meint.
Wann das Review stattfindet, da sind wir uns uneins und scheint Geschmackssache zu sein. Theoretisch ist es der vorletzte Termin in einem Sprint. Eben vor der Retrospektive. Es könnte aber auch der erste Termin eines neuen Zykluses sein. Genauso muss es kein festes Ritual sein und könnte auch eine Routine nach jeder erledigten Story sein. Um es Dir leicht zu machen, richte am Anfang lieber erst einmal einen festen Termin am Ende des Sprints ein.
Im Review schauen wir uns an, was wir im Sprint, also der letzten Iteration, alles erreicht haben.
Die fertige Umsetzung wird dabei mit allen Gästen am fertigen Produkt erlebt. Wichtig, denn das unterscheidet das Agile Review von vielen Präsentationen. Wir schauen wirklich auf das fertige Produkt. Wenn die zu erledigende Story ein Dokument als Ergebnis hat, dann kann dies natürlich auch betrachtet werden. Es wird aber nicht für die Vorstellung im Review extra eine Power Point Präsentation erzeugt. 😉
Das gilt übrigens auch für ein OKR Review.
Wer ist dabei?
Vom Prinzip her jeder. Also das komplette Team, inklusive Product Ownerin, und alle Stakeholder und Kundinnen. Tendenziell also jeder und so dürfen die Einladungen auch formuliert sein. Wichtig wäre dann auch, dass nicht die Product Ownerin die Ergebnisse vorstellt, sondern die Entwicklerinnen selbst und auch die Anerkennung dafür bekommen. Der Product Owner ist an der Stelle wichtig um eventuelle Kundenbedürfnisse mitzuhören und das Backlog gemeinsam anzupassen. Eventuell ergeben sich auch neue Anforderungen während des Reviews.
Theoretisch spart dies zusätzliche Termine und schafft den Entwicklern mehr Zeit zum Entwickeln. In der Praxis kann es sich anbieten mit dem Produkt spezifische Roadshows zu machen, wie in der Marketing Folge beschrieben, da Stakeholder eventuell nicht kommen.
Rein formal wurde in älteren Scrum Guide Varianten hier auch das Ergebnis abgenommen. Deshalb ist der Product Owner hier so wichtig. Wir empfehlen die Abnahme lieber vorher im Sprint zu machen, auch um keine bösen Überraschungen vor Kunde im Review zu haben und um auch Zeit für Nacharbeiten zu haben.
Achte hier bitte auch darauf, dass die Entwickler auch genug Anerkennung für ihre gute Leistung bekommen!
Wem gehört dieser Termin?
Henrys Meinung: Der Product Ownerin. Diese lädt auch ein. Die Struktur kommt eher von den Entwicklern und gleichzeitig schafft die Product Ownerin Themenschwerpunkte in der Agenda, so dass Interessierte auch zu speziellen Themen kommen können oder fernbleiben.
Janinas Meinung: Bei Janina darf der Product Owner auch im Review fehlen. Die Wertschätzung dem Team gegenüber sollte aber erbracht werden.
Arbeitstermin
Das Review ist ein Arbeitstermin, denn wir kriegen hier häufig auch Feedback von unseren Kunden und Stakeholdern, können mit ihnen den Projektplan und das Backlog besprechen. All dies bringt Anpassungen an unsere Planung für die nächsten Sprints. Dazu gehören auch neue oder angepasste Anforderungen im Backlog.
Dies führt auch häufig zu Änderungen in der Priorität.
Zeitlicher Rahmen
Im Scrum Guide steht ziemlich deutlich 4 Stunden für einen 4 Wochen Sprint. Davon abgeleitet also etwa eine Stunde je Sprintwoche, was so die Faustregel ist. Henry kennt kaum Reviews wo die Aufmerksamkeitsspanne lang genug ist und empfiehlt daher möglichst unter 3h zu bleiben. Eher 1 bis 2 Stunden. Selbst im skalierten Umfeld sollten Reviews parallelisiert und lieber in zwei Iterationen abgehalten werden.
Janina hält es da eher entspannt: Ein Review dauert so lange, wie es eben dauert.
Ein Zeichen für lange Reviews ist auch, dass scheinbar während des Sprints wenig Austausch passierte. Daher könnte man auch eher daran arbeiten.
Besondere Umstände
Henry führt das Review gern als erstes Ritual in einem neuen Team ein. Es fällt vielen leichter sich erst mit den Arbeitsergebnissen zu identifizieren und diese vorzuführen, wenn sie aus einer klassischen Welt kommen. Das theoretische Planen eines Zyklus in einem Planning ist da viel ferner. Daher das erste Ritual oft , das Review. Viele Teams wissen zu Beginn häufig noch nicht, was alles in diesem Team gemacht wird und sind verblüfft. Wie sollen sie da planen, wenn sie das nicht kennen? Also lieber das Review zu Beginn einführen.
Wie beschrieben, kann es sich auch lohnen eine interne Demo im Team durchzuführen. Dann ist der Reviewtermin eher für Menschen außerhalb des Teams und es müssen nicht mehr alle dabei sein. Die Interne Demo dient dann dazu das komplette Team auf einen Stand zu bringen. Das ist vor allem dann spannend, wenn nicht alle Entwicklerinnen an einer schwierigen Story beteiligt waren.
Teilt im Review auch größere Impediments, die während des Sprints aufgetreten sind. Auch dies können wertvolle Informationen für Stakeholder sein. Manchmal kommt es dann auch vor, dass Nachbarabteilungen sich melden, dies nicht wussten und in Zukunft anders an das Team herantreten werden. Zack Problem gelöst und Prozess verbessert.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Agilität
- Ritual
- Routine
- Scrum Guide
- Flexibilität
- Scrum
- Sprint
- Retrospektive
- Story
- OKR
- Team
- Product Ownerin
- Stakeholder
- Backlog
- Marketing
- Planning
Connecte dich gerne hier mit uns:
