Das Review als Nicht-Meeting

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?