Sprint Review. Schritt für Schritt von “Inspect to Accept” zu “Inspect to Adapt”.

Häufig geht es in Sprint Review’s lediglich um die Abnahme der Backlog Items. Anstelle eines  guten, informellen Austauschs über die weitere Ausgestaltung des Produktes werden sie damit zu seelenlosen Status-Meetings. Es geht nicht mehr darum, das Produktinkrement zu inspizieren und daraus Anpassungen abzuleiten, sondern vielmehr darum, Themen abzuhaken. “Inspect to Adapt” wird somit zu “Inspect to Accept”. In Podcast Folge #28 “Sprint Review” gehe ich auf diese Problematik ein und verdeutliche, dass diese Vorgehensweise meist aus einem zerrütteten Verhältnis zwischen Scrum Team und Stakeholdern resultiert. Darüber hinaus zeige ich Wege auf,  wie sich Teams und deren Umgebung schrittweise in Richtung “Inspect and Adapt” bewegen können und stelle meine präferierte Agenda für ein effektives Sprint Review vor. 

Das Worst Case-Szenario: Das Sprint Review als ultimative Zeitverschwendung

 

Um klar zu verdeutlichen, worin die Vorteile eines effektiven Sprint Reviews liegen, möchte ich einmal das Negativbeispiel genauer beleuchten. Die Agenda eines schlechten Sprint Reviews läuft für gewöhnlich folgendermaßen ab: Der Product Owner liest die einzelnen User Stories vor. Häufig wurde der PO vorher nicht vom Team darüber informiert, was fertig ist und was nicht. Dies hat zur Folge, dass er ein Item bzw. Ticket nach dem anderen vorliest. Basierend auf den festgelegten Akzeptanzkriterien erfolgt eine kurze Diskussionen zur Abnahme der jeweiligen Items. Es in diesem Meeting nicht mehr darum, das Produktinkrement zu inspizieren und daraus Anpassungen abzuleiten, sondern vielmehr darum, Themen abzuhaken. “Inspect to Adapt” wird somit zu “Inspect to Accept”. 

 

Dies hat entscheidende Nachteile: Zum einen ist eine solche Herangehensweise nicht wertstiftend für die Entwicklung des Produktes. Zum anderen bietet es Stakeholdern als Teilnehmer des Reviews keinen sonderlichen Mehrwert an Information, denn diese sollten mehr an einer strategischen Übersicht interessiert sein als am Abarbeiten einzelner Items. Es ist darüber hinaus fragwürdig, welchen Wert ein solches Meeting für das Verhältnis zwischen Team und PO stiftet. Häufig ist der PO bei einem derartigen Aufbau des Reviews der PO der inhaltliche Treiber des Produktes. Die gemeinsame Sicht gerät völlig in den Hintergrund. 

Mein Tipp an dieser Stelle ist es, zu prüfen, wie viel Zeit des Sprint Reviews in einen aktiven Austausch sowie in die Abnahme der einzelnen Items fließt. In der Regel sollte der Austausch ca. 80% in Anspruch nehmen. Die Abnahme einzelner Items sollte jedoch nur ca. 20%  der Zeit in Anspruch nehme. Warum das so ist, werde ich im Folgenden verdeutlichen.

Von der Checkliste zu “Inspect and Adapt”

 

Um diesen Missstand zu beseitigen und von einer Item-Checkliste hin zu wertstiftenden Gesprächen und sinnvollen Anpassungen zu kommen, müssen Scrum Teams sich ganz stark vor Augen halten, dass das Review zwar der letzte Ort zur Abnahme von Items darstellt, allerdings nicht der einzige Ort ist, an dem diese gemacht werden sollte. Es ist durchaus notwendig, außerhalb des Sprint Reviews darüber zu sprechen. Mehr noch: Es ist die Pflicht des Entwicklungsteams, den PO darüber zu informieren, sollte ein Item nicht wie im Sprint Planning festgelegt fertiggestellt werden können, damit dieser die Erwartungen der Stakeholder managen kann. (Mehr zum Verhältnis zwischen Team und PO gibt es in der Folge Sprint Planning). Kommt das Entwicklungsteam seiner Verantwortung nach, dürfte es auch im Sprint Review nicht zu einer ausufernden Abnahme im Checklisten-Format kommen. 

 

Besonders in Hinblick auf die Stakeholder ist es essentiell, Produktinkremente im Sprint Review nicht auf Item-Ebene zu betrachten sondern vielmehr auf strategischer Ebene. Es sollte nämlich hierbei für die Stakeholder darum gehen, Inkremente im Gesamtkontext zu betrachten und  die Vision im Blick zu haben. Die Items stellen lediglich die einzelnen Schritte im Sprint dar, das Ziele zu erreichen. Sind die Stakeholder fokussiert darauf, den Fortschritt auf Item-Ebene zu besprechen, ist das meist ein Zeichen dafür, dass der Product Owner nicht ausreichend strategische Ownership übernimmt, um die Stakeholder dahingehend abzuholen. 

Die Lösung ist es, die Product Ownership stärker auf die Vision und die strategische Ausrichtung zu lenken, sodass das Sprint-Ziel und die heruntergebrochenen Items zum Hilfsmittel werden, dieses Ziel zu erreichen. Es gilt im Sprint Review, die einzelnen Items dementsprechend in das große Ziel einzuordnen sodass nicht mehr über die Details gesprochen wird sondern vielmehr über den Zusammenhang mit der übergreifenden Vision.

Ein zerrüttetes Verhältnis zwischen Scrum Team und Stakeholder ist oft Realität

 

Der Product Ownership eine größere strategische Ausrichtung zu verleihen, ist leichter gesagt als getan. Die Gründe dafür liegen häufig in einem zerrütteten Verhältnis zwischen den Fachbereichen und dem Scrum Team, das gekennzeichnet ist durch mangelndes Vertrauen. Oft hat sich dieses Verhältnis über eine längere Zeit entwickelt und kann demnach nicht so einfach wieder zurechtgerückt werden. 

 

Gründe dafür können sein, dass Fachbereiche durch eine Nichtfertigstellung von Produkten oder das Fehlen von Budget zur Fertigstellung eines Produktes vom Scrum Team überrascht werden. Dieses zerrüttete Verhältnis resultiert oft auch daraus, dass Scrum Teams von Fachbereichen einen unverhältnismäßig hohen Detailgrad der Spezifikation erwarten, den diese nicht leisten können. Darüber hinaus passiert es nicht selten, dass Scrum Teams die Fachbereiche mit technischen Begriffen so sehr überladen, dass diese sich maßlos missverstanden, übergangen und nicht abgeholt fühlen. All diese Beispiele verschlechtern das Verhältnis zwischen Scrum Team und Stakeholdern und stehen der eigentlichen Intention von Scrum entgegen.

 

Ich bin davon überzeugt, dass dieses Verhältnis nicht ausschließlich einer Partei zuzuschreiben ist. Meiner Meinung nach muss jedoch das Scrum Team in Vorleistung gehen, um dieses Verhältnis wieder ins korrekte Licht zu rücken. Denn: Wenn das Scrum Team anfängt, dem Umfeld einen Schritt entgegen zu kommen, ist die Chance groß, einen Unterschied zu machen und aus dem “Nebeneinander” ein “Miteinander” zu kultivieren.

Vom Nebeneinander zum Miteinander

 

Um aus dem “Nebeneinander” ein “Miteinander” zu entwickeln, ist es ist nicht einfach damit getan, die Stakeholder ins Sprint Review einzuladen und auf ein besseres Miteinander zu hoffen. Die Wahrscheinlichkeit, dass alle negativen Muster in diesem Meeting weitergelebt werden, ist trotz bester Absichten relativ groß. Ich empfehle vielmehr ein schrittweises Abholen einzelner, ausgewählter Stakeholder. Dies können beispielsweise einige befreundete Stakeholder sein. Im ersten Schritt gilt es, das Vertrauen ihnen gegenüber aufzubauen und sie aktiv in die Ausgestaltung des neuen “Miteinander” zu integrieren. Gelingt das, können diese Multiplikatoren helfen, das Vertrauen innerhalb der jeweiligen Fachbereiche wiederherzustellen. Bis dahin können das Team und die ausgewählten Stakeholder ihr Miteinander weiter ausgestalten aus und Schritt für Schritt neue Teilnehmer einladen. 

Was letztendlich das richtige Format und die Richtige Teilnehmerzahl darstellt, kann pauschal nicht gesagt werden. Wichtig ist lediglich, dass Format und Teilnehmerzahl zum jeweiligen Kontext passen. Es gilt, durch die gemeinsame Ausgestaltung einen Weg zu finden, die wesentlichen und wertstiftenden Fragen eines Sprint Reviews zu beantworten: 

  • Was ist die wesentliche Erkenntnis, die wir aus dem Produktinkrement gewinnen können?
  • Wie ordnen wir unser Produktinkrement in den Gesamtkontext ein?
  • Wie regen wir ein Gespräch an?
  • Wie leiten wir daraus die richtigen Anpassungen ab?

Ein wichtiger Bestandteil dies zu erreichen ist, neben der schrittweisen Einbindung, das stetige Einholen von Feedback der Stakeholder am Ende des Sprint Reviews. Nur so kann das Vertrauen wiederhergestellt und ein gutes Verhältnis kultiviert werden. 

Meine Lieblingsagenda 

 

Aufbauend auf dieses Feedback gibt es einzelne Formate, die ich gern einsetze um den Rahmen zur Ausgestaltung des Sprint Reviews zu verbessern.

 

  • Eine gute Übersicht als Rahmen
    Zum einen gilt es, den Stakeholdern eine Chance geben, dem Meeting folgen zu können. Dies erreichen wir, indem wir einen klaren Rahmen für das Sprint Review festlegen. Dazu gehört,  die Einordnung des Sprints ins Große und Ganze und das Ableiten des  Sprint-Ziele ohne dabei zu sehr ins Detail zu gehen. Ebenso muss festgelegt werden, was der Kern der Betrachtungen im Review sein wird und worum es in der anschließenden Demo gehen soll. So kann sichergestellt werden, dass Stakeholder die festgelegte Agenda verfolgen und nicht etwa ihre eigene Agenda umsetzen.

 

  • Eine gute Demo als Trigger für ein gutes Gespräch
    Eine gute Demo bezeichne ich gerne als eine Mischung aus Stadtrundfahrt und Kochsendung mit Jamie Oliver.
    Zum einen sollte sich eine gute Demo für Stakeholder anfühlen, wie eine Stadtrundfahrt an einem Wochenend-Trip. Sie soll die Teilnehmer anhand eines roten Fadens (also dem Gesamt-Use Case) von A nach B führen und nur so tief ins Detail gehen, wie unbedingt notwendig. Dabei sollte man dem Publikum stets vor Augen halten, in welchem Teil der Stadt (des Produktes) sie sich gerade befinden, wo sie herkommen und wohin es geht. Vor allem aber sollen sie erkennen, warum ein kurzer Stopp an der nächsten Attraktion (Demo) einen Blick Wert ist. Ist die Demo in ähnlicher Form vorbereitet, können Stakeholder ganz einfach auf diese Reise mitgenommen werden und erkennen schnell, was in der Vergangenheit geschaffen wurde, woran gerade gearbeitet wird und wohin die Reise geht.

 

Im Sprint Review ist es häufig so, dass unterschiedliche Teams ihre Ergebnisse präsentieren. Dadurch gerät der Ablauf durch Übergaben, Aufbau oder Datenimporte ins Stocken. Dies ist schlecht für die Konzentration und den Fokus des Publikums. Es macht daher Sinn, durch entsprechende Vorbereitung lange Wartezeiten zu vermeiden. Ebenso können Pausen zu Gesprächen führen, die in eine von uns nicht gewünschte Richtung gehen. Um dies zu vermeiden, empfehle ich ein Vorgehen à la Jamie Oliver in seiner Kochsendung: Dort wird das Publikum während der Garzeiten nicht einfach sitzen gelassen. Vielmehr wird so einiges geboten, um Wartezeiten angemessener zu gestalten. Im Kontext einer Demo kann dies dadurch geschehen, dass neben einer Vorbereitung zur flüssigen Ausführung ebenfalls eine entsprechende “Punchline” gesetzt wird. Das bedeutet für das Team, das Gespräch am Ende einer Präsentation  aktiv anzuregen und die richtigen Fragen an das Publikum zu richten. Dies gibt dem Team die Chance, das Gespräch in die richtige Richtung zu lenken und Feedback mitzunehmen und im kommenden Review darauf zurückzukommen.

 

  • Integration von übergreifenden Themen
    Es gibt übergreifende Themen, die nicht unbedingt in eine Demo integriert werden können, aber dennoch wichtig sind, um das gemeinsame Verständnis zu schärfen. Das können beispielsweise Risikobewertungen, Release-Planungen oder der Blick auf nichtfunktionale Anforderungen und qualitative Dinge sein. Ich empfehle, die wichtigsten Punkte in das Review mitzunehmen und diese im Anschluss an die Demo zu präsentieren. Das Format der visuellen Darstellung ist dabei nicht festgelegt. Es spielt keine Rolle, ob die Themen über Flipcharts oder über Präsentationsfolien vorgestellt werden. Es ist jedoch wichtig, dass auch hier wieder eine Einordnung ins Große und Ganze erfolgt.  Darüber hinaus ist es ebenfalls sinnvoll, einen Ausblick über zukünftige Chancen und Möglichkeiten zu geben und mit den Stakeholdern dahingehend in den Dialog zu treten.

 

  • Feedback zum Sprint Review
    Das Sprint Review schließe ich am liebsten mit einer kurzen Feedback-Runde ab. Das bedeutet, dass alle Teilnehmer in ca. 2-5 Minuten Feedback zum Aufbau des Reviews geben und überlegen, inwiefern die Ziele des Miteinanders und “Inspect and Adapt” erfüllt sind und was noch fehlt, um dorthin zu gelangen.

Das Messe-Format als weitere Sprint Review Agenda

 

Ein alternatives Format für eine gute Sprint Review Agenda stellt meiner Meinung nach das “Messe-Format” dar.  Hier stellen zwei bis drei Mitglieder einzelner Teams parallel in einem Raum ihre Ergebnisse vor. Die Stakeholder sowie der Rest der Teams werden in einzelnen Gruppen aufgeteilt, die von Präsentation zu Präsentation rotieren und für ca. 15 Minuten dort verweilen. Der Vorteil liegt hier ganz klar in den kleinen und informellen Gesprächen, die innerhalb dieser kleinen Gruppen forciert werden. Ein weiterer Benefit ist, dass die Präsentatoren durch die Wiederholung von Mal zu Mal besser besser werden bei der Präsentation. 

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events oder Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training. Speziell für Product Ownership empfehle ich das Certified Porduct Owner Training.

 

 

Schreibe einen Kommentar