Scrum in der Praxis

Erfahrungen, Problemfelder und Erfolgsfaktoren

Ein Sprint Review mit mehreren Teams verbessern

| Keine Kommentare

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-Teilnehmer wertvolles Feedback, welches wiederum in die Verbesserung des Produktes einfließen kann. Daneben erhalten die Teilnehmer 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 Projektinteressierten 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 Teilnehmer die Reviews besuchen, sodass bei den Teams der Eindruck von Desinteresse entsteht. Oder ein Team hat aufgrund der Thematik immer weitaus mehr Zuhörer 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«.

Ein Review für Alle

feedback_boxUm dieser Entwicklung zu begegnen, schlagen wir vor, die 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 Mitarbeiter aus der Firma eingeladen sind. Ein 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 Entscheidung, auf welche Details der Fokus gelegt wird, liegt bei jedem einzelnen Team und wird in Abstimmung mit dem jeweiligen Product Owner erstellt.

Die Feedback-Box

Ein wichtiges Hilfsmittel, um die Qualität der Reviews zu steigern, war die Feedback-Box, die ich mit Start des Company Reviews einführte. Die Teilnehmer hatten die Möglichkeit, einfach 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 auch, 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.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.


*