Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:
- Demos, keine Präsentationen! Im Review wollen wir vorführen, wie unsere Produkte funktionieren. Und dafür brauchen wir weder Powerpoint noch sonstige Realitäts-Substitute.
- Teilnehmer, keine Anwesenden. Das, was das Team im Sprint fertiggestellt hat, lädt fast immer irgendwie zum Mitmachen ein. Vor allem User sind hier gefragt, das entstehende Produkt zu begutachten und – soweit möglich – selber in die Hand zu nehmen. So ensteht direktes Feedback, das deutlich realitätsnaher als jede Fokus-Gruppe ist.
- Gespräche, keine Abfragerunden! Damit echte Gespräche zustande kommen, sind kleine, interaktive Gruppen unabdingbar. Dazu bietet sich etwa das World Café-Format an: Für jedes der neuen Features einen Tisch einrichten – das Team teilt sich entsprechend auf und stellt vor. Die Teilnehmer verteilen sich von Tisch zu Tisch und rotieren alle zehn Minuten. Am Ende kommen alle kurz zusammen und stellen die wichtigsten Erkenntnisse vor.
- Stift und Papier statt Open Issue-Listen. Im Review entstehen zunächst einmal Ideen, wie es mit dem Produkt weitergehen soll. Der formale Prozess, nämlich die Festlegung der nächsten Entwicklungsschritte, geschieht anschließend durch den Product Owner mit seinem Team.
Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?
Eine Antwort zu “Das Review als Nicht-Meeting”
Hallo,
ich habe in meinem letzten Projekt als Product Owner gearbeitet. Es hat einige Zeit gedauert, bis ich die Vorstellung der Ergebnisse dem Team überlassen hatte. Nach meiner Erfahrung sind Entwickler nicht immer die größten Kommunikationstalente. Die ersten Reviews habe ich deshalb selbst präsentiert. Beim Vorstellen der Ergebnisse geht es nicht nur darum offensichtliches zu zeigen, sondern den Stakeholdern auch zu erklären, warum etwas gemacht wurde und wie es in die Vision passt. Also habe ich dies mit dem Team trainiert und sie haben nach und nach die Ergebnisse selbst vorgestellt.
In großen Unternehmen ist es üblich, dass Teams und Stakeholder nicht in der gleichen Lacation sind. Mein Team hat mich dann eines Tages mit einem Review Video überrascht, das bei Stakeholdern sehr gut ankam. In dem Video wurden die Ergebnisse und Hinweistexte (was wurde gemacht, mit welcher Motivation) und am Ende eine kurze Statistik über die Anzahl Feature und Bugsfixes. Da es sich um eine Webplattform handelte, wurde auch gezeigt, wie sich Implementierung in Google als Ergebnis darstellten (SEO/SEM).
Diese Art des Reviews kann ich sehr empfehlen, wenn Stakeholder verteilt sind.
Viele Grüße
Elena