Das Highlight eines Sprints ist das Sprint Review. Ein Review verfolgt zwei wesentliche Zielsetzungen: Zum einen stellt das Team vor, was es in den letzten Wochen seit Beginn des Sprints erreicht hat und zum anderen geben die Review-Teilnehmenden wertvolles Feedback, welches wiederum in die Verbesserung des Produktes einfließen kann. Daneben erhalten die Teilnehmenden relevante Informationen über die geplanten nächsten Schritte.
In Unternehmen, in denen die Produktentwicklung durch mehrere Scrum-Teams erfolgt, tritt häufig eine gewisse Review-Müdigkeit bei den Projektinteressenten ein. Bedingt durch die große Anzahl an Reviews, die um die wertvolle Arbeitszeit der Stakeholder buhlen, besuchen diese mit der Zeit nur noch einige ausgewählte Reviews. Das bedeutet einerseits, dass sie nicht mehr alle Entwicklungen mitbekommen oder zumindest nicht mehr aktiv beeinflussen können, und andererseits, dass immer weniger Teilnehmende die Sprint-Reviews besuchen, sodass bei den Teams der Eindruck von Desinteresse entsteht. Oder ein Team hat aufgrund seiner thematischen Zuständigkeit immer weitaus mehr Teilnehmende als ein anderes Team. In der Folge fragen sich die Teams, warum sie sich eigentlich immer so viel Mühe mit dem Herausputzen machen, »wenn es eh keinen interessiert«.
Mehrere Teams in einem Review
Um dieser Entwicklung zu begegnen, schlagen wir vor, die Sprint-Reviews mehrerer Teams zu einem einzigen Review zusammenzufassen. Auch in meiner aktuellen Firma sind wir diesen Weg gegangen. Aktuell präsentieren sechs Teams regelmäßig die Ergebnisse der vergangenen zwei Wochen in einem „Company Review“, zu dem alle Mitarbeitenden aus der Firma eingeladen sind. Dieses Review dauert eine halbe Stunde. Die Teams haben also maximal fünf Minuten, um ihre Sprintergebnisse vorzustellen.
Diese Zusammenführung brachte für die Vortragenden einige Herausforderungen mit sich. Neben der größeren Teilnehmerzahl musste das Sprint Review eines Teams von einer halben Stunde auf fünf Minuten eingedampft werden. Dies geht nur, wenn Details weggelassen werden und eher auf Epic-Ebene statt auf Feature-Ebene präsentiert wird.
Die Feedback-Box
Ein wichtiges Hilfsmittel, um die Qualität der Reviews zu steigern, war die Feedback-Box. Die Anwesenden hatten die Möglichkeit, eine Ampelkarte (grün – gelb – rot) oder ein Smiley (traurig – neutral – freudig) inklusive kurzem Feedback einzuwerfen. Zu Beginn war das Feedback sehr ernüchternd:
- Unverständliche Details
- Wirkte nicht gut vorbereitet
- Sprache der Entwickler nicht für alle verständlich
- Präsentation bitte vorher testen
- Nur einen Rechner benutzen
Die Ergebnisse wurden nach jedem Review offen und ungeschönt im Unternehmens-Wiki dokumentiert. Diese Transparenz führte dazu, dass sich das Company Review sehr schnell professionalisierte und sowohl die Teilnehmeranzahl als auch der Spaß und die Motivation bei den Vortragenden stieg.
Der Status Quo
Durch das Feedback und die gesammelten Erfahrungen, arbeiten wir aktuell mit den folgenden Rahmenbedingungen:
- 1-2 Entwickler aus jedem Team präsentieren die Ergebnisse aus dem Sprint
- Wir nutzen eine einheitliche Präsentationsvorlage (HTML-Slideshow) für alle Teams, die von den Vortragenden jeweils strukturiert inhaltlich aufbereitet wird:
- Vorstellung des Sprint-Ziels und der im letzten Sprint entstandenen Funktionalität, ergänzt um Anekdoten, Herausforderungen und deren Lösungen durch das Team
- Kurzer Ausblick auf den nächsten Sprint und ggf. das anstehende Release
- Fragen und Feedback von den Teilnehmern
- Alles wird und kann somit einfach von einem Rechner präsentiert werden
- Klick-Strecken und Live-Vorschau von neuer Funktionalität sind vorab im Browser inkl. Passwörtern vorbereitet
- Die Product Owner stehen für Detailantworten zur Verfügung
- Jedes Team hat eine Timebox von max. 5 Minuten
Eine wichtige Erkenntnis war zudem, dass der Fokus bei der Vorstellung der neuen Funktionalität darauf liegen sollte, warum dieses Feature gebaut wurde und welchen Vorteil es für den Nutzer bzw. Kunden hat. Die Präsentation, da sie in einem großen Rahmen stattfindet, sollte auch nicht zu technisch und für den Großteil der Zuhörer verständlich sein (Fach-Jargon sollte vermieden werden).
Momentan denken wir darüber nach, dass Review noch weiter auszuweiten und andere, nicht an der Entwicklung beteiligte Teams, hinzuzufügen. Auch Gastbesuche aus anderen Abteilungen sind im Gespräch.
Wie auch bei meinen vorherigen Arbeitgebern, ist diese halbe bis eine Stunde sehr gut investierte Zeit, da die gesamte Firma einen aktuellen Status zur Produktentwicklung enthält und gleichzeitig das „Wir-Gefühl“ der Firma durch den regelmäßigen Austausch gestärkt wird. Ob nun am Scrum Flow der Entwicklung orientiert oder als fester wöchentlicher gemeinsamer Termin etabliert, ein Event für das gesamte Unternehmen lohnt sich in jedem Fall.
