123 Review

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,


Janina & Henry


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


Janinas Ultimativer OKR Guide


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:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post 123 Review appeared first on Znipcast - für gute
Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.