Aus der agilen Methodenkiste: Sinn und Zweck des Reviews und der Retrospektive

Scrum_Framework
Quelle: wikimedia.org, Creative Commons CC0 1.0 Universal Public Domain Dedication.

In der Praxis beobachte ich öfter, dass der Unterschied zwischen Retrospektive und Review am Ende des Sprints nicht immer klar und eindeutig ist. Auch erschließt sich der Sinn der beiden Formate nicht immer. Gerade agile „Neulinge“ tun sich offenbar schwer, nachzuvollziehen warum der Blick auf die Teamzusammenarbeit (Blick nach innen) und der Blick auf das Ergebnis (Blick von außen) in zwei getrennten Besprechungsformaten stattfindet. Dazu kommt die Versuchung, Zeit zu sparen, indem auf eines der beiden Formate verzichtet wird.

Ein wesentliches Merkmal agiler Ansätze ist das iterativ-inkrementelle Vorgehen. In der klassischen Projektdenkweise wird am Ende des Projekts erst überprüft, ob das Ergebnis die Erwartungen an das Projekt erfüllt. Die agile Denkweise schlägt jedoch einen anderen Weg ein. Hier wird in kurzen Zeitperioden bewusst eine Unterbrechung erzeugt. Zwischenergebnisse werden dahin überprüft, ob die Erwartungshaltung – die zugrundegelegten Annahmen – korrekt sind und die Teilergebnisse tatsächlich zielführend sind. So kann bereits in einem frühen Stadium festgestellt werden, ob Anpassungsbedarf besteht. Dieses frühe Reagieren und Agieren auf neu Erkenntnisse, die Fähigkeit, bereits in einem frühen Stadium Anpassung vornehmen zu können, ist der wesentliche Mehrwert in Entwicklungsprojekten, den agilen Ansätze bieten. Grundlage hierfür ist insbesondere der Review.

Der Review

Der Review am Ende jeder Iteration ist der Moment, an dem wir Feedback der Anwender, der Auftraggeber und Kunden zur geleisteten Arbeit generieren. Agilität ist kein Selbstzweck. Die 12 Prinzipien des agilen Manifests sind eindeutig und klar. Bereits das erste Prinzip besagt:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.

Es geht klar und eindeutig darum, einen Mehrwert zu schaffen. Wir wollen nicht nur irgendetwas als Ergebnis ausliefern, sondern genau das, was unseren Auftraggeber zufriedenstellt. Etwas, das ein Problem löst und seine Bedürfnisse befriedigt. Es geht, darum etwas zu entwickeln, das voranbringt. Um zu erfahren, ob das, was wir in der Iteration entwickelt haben, auch tatsächlich den Bedürfnissen unseres Auftraggebers und der späteren Anwender entspricht, brauchen wir die Rückkopplung. Diese Rückkopplung generieren wir im Review.

Daher heißt es im Scrum Leitfaden:

Während des Sprint Reviews beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten. Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.

Ein Review ist daher kein bloßer Statusbericht in der Lenkungsgruppe, sondern ganz konkret die Präsentation und ausgiebige praxisnahe Überprüfung des Ergebnisses einer Iteration. Er liefert mit die Grundlage für die nächste Iteration. Dort erfährt das Entwickler- oder Umsetzungsteam, ob die von ihnen getroffenen Annahmen korrekt waren oder ob nachgesteuert werden muss. Anwender und andere Anspruchsberechtigte können ganz konkret ausprobieren und testen. Sie liefern Hinweise, wo am Ergebnis gearbeitet werden kann und muss. Ist das Projekt auf dem richtigen Weg? Wird tatsächlich ein Mehrwert erzeugt, der das Projekt rechtfertigt? Wo muss angesetzt werden, um das Arbeitsergebnis in der nächsten Iteration aus Sicht des Anwenders, der Anspruchsberechtigten weiter zu verbessern? Was braucht es, damit wir die Bedürfnisse unserer Zielgruppe erfüllen können? Erstellen wir tatsächlich das, was gebraucht wird? Erfüllen wir unseren Anspruch, einen echten Mehrwert zu erzeugen? Das sind die zentralen Fragen, die der Review beantwortet und die ein agiles Team beantworten muss.

Der Fokus des Reviews liegt also auf dem Arbeitsergebnis, und die wesentliche Zielgruppe hierbei sind die Anspruchsberechtigten des Projekts. Daher ist der Review grundsätzlich eine öffentliche Veranstaltung.

Die Retrospektive

Die agile Grundidee geht davon aus, dass ein Team bessere Ergebnisse erstellt, wenn es seine Zusammenarbeit regelmäßig reflektiert und seine eigene Zusammenarbeit verbessert. Es geht darum, das Werkzeug, mit dem das Team arbeitet, in Schuss zu halten. In diesem Sinne postulieren die 12 Prinzipien des agilen Manifests ganz klar:

„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“

Oder mit den Worten des Scrum-Leitfadens ausgedrückt:

Die Sprint Retrospektive wird durchgeführt, um zu überprüfen , wie der vergangene Sprint in Bezug auf die beteiligten Menschen, Beziehungen, Prozesse und Werkzeuge verlief; die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams zu erstellen.

Hier ist die Referenz nicht „Spaßfaktor“ des Teams. Auch hier geht es darum, die Zusammenarbeit in erster Linie zu verbessern, um besser Ergebnisse zu erzielen. Allerdings richtet sich die Retrospektive in erster Linie auf den Prozess der Zusammenarbeit und damit an das Team – nicht an die Anspruchsberechtigten. Die zentrale Frage ist hier, wie können wir unserer Zusammenarbeit verbessern, um künftig (noch) bessere Ergebnisse in effizienter Form zu liefern. Auch hier gilt, durch die regelmäßige rhythmische Fokussierung durch iterative Zyklen, wird das Werk- und Rüstzeug an die neuen Erkenntnisse aus der laufenden Arbeit angepasst, so dass die Werkzeugkiste im tadellosen Zustand ist und bleibt. Sie wird situativ „ausgestattet“, um mit den passenden Hilfsmitteln zu arbeiten. Angepasst an die Situation – immer mit dem Ziel, das beste mögliche Ergebnis zu erzielen.

Resümee

Retrospektive und Review sind nicht ohne guten Grund elementare Bestandteile einer iterativen Arbeitsweise. Ganz im Gegenteil. Sie sind notwendig, um sicherzustellen, dass ein Team im Laufe eines iterativen Entwicklungsprozesses effektiv und effizient das beste mögliche Ergebnis erzielt. Agilität ist kein Selbstzweck, sondern dient ausschließlich der Erstellung von echtem Mehrwert und Nutzen im Sinne der Anspruchsberechtigten. Der Review gibt im Hinblick auf das WAS wichtige Hinweise, bei der Standortbestimmung und der Ergebnisbeurteilung. Die Retrospektive gibt Antwort darauf, ob das WIE angemessen und zielführend ist. Beide Besprechungsformate sind damit essenziell für das Funktionieren agiler Herangehensweisen. Die Trennung von Review und Retrospektive ist vor den unterschiedlichen Schwerpunkten zielführend und erleichtert die thematische Fokussierung. Sie sind beide in ihrer Bedeutung nicht zu unterschätzen.

 

Autor: Thomas Michl

Dipl.-Verw.Wiss. | MBA | Europäer | Irland-Fan | Arbeitet für borisgloger consulting | Gründungsmitglied des Forums Agile Verwaltung

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.