How to rock your Sprint Retrospective

Teams arbeiten langsamer als beabsichtigt, Prognosen treffen nicht zu, Fristen werden verpasst. Viele Scrum Master haben das schon erlebt. Zur Ermittlung der Ursachen eigenen sich Retrospektiven sehr gut. Der PMBOK-Guide empiehlt, sie als Lessions-Learned-Sessions während der Abschlussphase von Projekten durchzuführen. In agilen Projekten finden Retrospektiven idealerweise am Ende jeder Iteration statt. Aber selbst bei der regelmäßigen Durchführung ist es schwierig, dem eigentlichen Spirit der Retrospektive zu folgen. In der Konsequenz werden oftmals Retrospektiven durchgeführt, ohne spezifische Auswirkungen auf das konrkete Projekt. In diesem Artikel möchte ich eine Retrospektive anhand eines realen Anwendungsfalls beschreiben, die dazu beigetragen hat, die Moral des Teams zu verbessern und die Produktivität zu steigern.

Was ist eine Retrospektive?

„In regelmäßigen Abständen reflektiert das Team, wie man effektiver wird, stimmt sein Verhalten entsprechend ab und passt es an.“ – Agile Manifesto Ich habe Ende 2017 ein Scrum Team mit 7 Mitglieder geleitet. Wir hatten 2 Sprints durchgeführt, jedoch in beiden die Sprint-Ziele deutlich verpasst. Das Burndown Chart sah wie folgt aus:

Wie zu sehen ist, hat sich die Geschwindigkeit vollständig verschlechtert. Sprints sind kläglich gescheitert. Natürlich wurden die Fähigkeiten und das Engagements des Teams im Review-Meeting in Frage gestellt. Was lief falsch? Warum lagen die Prognosen so weit weg von der Realität? In zwei Treffen versuchten wir die bekannten drei Fragen miteinander zu diskutieren:

1. Was sollten wir demnächst ausprobieren?
2. Was sollten wir nicht mehr tun?
3. Was sollen wir weiter machen?

Konkrete Maßnahmen konnten wir jedoch nicht in die Wege leiten. Warum war das wohl so? Das agile Manifest schlägt vor, dass ein „Team darüber nachdenkt, wie es effektiver wird“ und nennt zwei Zeremonien im Rahmen des „Inspect and Adapt“ Prozesses:

1. Das Sprint Review.
2. Die Sprint Retrospektive.

Grundsätzlich sind Sprint Retrospektiven eine großartige Möglichkeit für Scrum Teams, sich weiterzuentwickeln und zu verbessern.

Im Zuge des Demingkreises bzw. PDCA-Zyklus, der einen iterativen vierphasigen Prozess beschreibt, versuchen Scrum Teams, ihre Arbeitsweise zu analysieren und zu verbessern. Zusätzlich überprüfen die Teams auch die in der vorherigen Retrospektive besprochenen Maßnahmen. Sie überprüfen den Status ihrer Aktivitäten und definieren, welche Anpassungen an ihrer Arbeitsweise nötig sind.

Neben dem Scrum Team sollte ein Facilitator – also eine Art Moderator – an der Retrospektive teilnehmen. In den allermeisten Fällen wird das der Scrum Master sein. Gemeinsam können sie den Product Owner und auch jeden anderen Stakeholder auffordern, an dem Meeting teilzunehmen. Unabhängig davon wer an der Retrospektive teilnimmt, per Definition liegt die Verantwortung beim Team. In der Regel wird sie nach dem Sprint Review durchgeführt, da zu diesem Zeitpunkt häufig bereits Ideen für Verbesserungen vorhanden sind. Sie könnte aber bei Bedarf auch während eines Sprints stattfinden. Generell lassen sich Retrospektiven innerhalb der gesamten Organisation nutzen, also auch bspw. bei Scaled-Agile-Varianten nach der Erstellung eines Inkrements im Zuge von „Inspect and Adapt“.

Retrospektiven sind wichtig, denn sie halten den Teams einen Spiegel vor. Es geht dabei aber nicht um die Durchführung der Aktivität, sondern die Auseinandersetzung mit der konkreten Arbeitsweise im Team. Diese Auseinandersetzung ermöglicht dem Team, Veränderungen zu prüfen und in den meisten Fällen umzusetzen. Selbst wenn das Team für die Umsetzung eine organisatorische Unterstützung erfordert, das Team hat die Fähigkeit, seine Arbeitsweise nach Bedarf zu modifizieren. Dazu überprüft es die zuvor festgelegten Aktionen, überprüft deren Wirksamkeit, bespricht Verbesserungen und verpflichtet sich gemeinsam auf diese. So erhält ein Team Kontrolle und die agile Reise wird einfacher. Der Scrum Guide beschreibt die Retrospektive als eine „Gelegenheit für das Scrum Team, sich selbst zu inspizieren und einen Plan für Verbesserungen zu erstellen, der im nächsten Sprint umgesetzt werden soll.“ In anderen Worten: eine Retrospektive ist die Grundlage für kontinuierliche Verbesserung.

Der Prozess und sein Ergebnis

„Es gibt einen Weg, es besser zu machen. Finde ihn.“ – Thomas Edison Um die Ziele einer Retrospektive zu verstehen, ist es wichtig, den Unterschied zwischen einer Review und einer Retrospektive zu kennen. Das Sprint Review ist eine Aktivität, die am Ende des Sprints ausgeführt wird, um die vom Team realisierten User Storys abzunehmen. Es ist eine Zeremonie, bei der das Entwicklungsteam umgesetzte Features demonstriert, um von den anwesenden Stakeholdern unmittelbares Feedback zu erhalten. Das Scrum Team stellt sein Ergebnisse – umgesetzte Items und gegebenenfalls auch Aspekte, die im Sprint nicht wie gewünscht funktioniert haben – dar. Dafür erhält es Feedback – also Anerkennung oder auch negative Rückmeldungen – der Stakeholder.

Die Retrospektive wird nach dem Review durchgeführt. Sie erlaubt die Analyse der von dem Team durchgeführten Arbeiten, die während des Reviews demonstriert wurden. Das während des Reviews erhaltene Feedback wird in der Retrospektive diskutiert. Sie bietet einen Raum, um Probleme im Zusammenhang mit der Leistung des Teams frei und fair und ohne Bosheit zu thematisieren. Idealerweise nehmen alle Beteiligten – also auch Stakeholder – an diesem Treffen teil, denn es gilt zwei Aspekte zu diskutieren:

1. Das Inkrement. Genügt es der Spezifikation der Definition of Done, die vom Product Owner festgelegt wurde? Wurden alle Arbeitsvereinbarungen eingehalten? Scheiterte der Sprint und wenn ja, welche User Storys konnten noch demonstriert werden? Liefert das Inkrement die erwarteten Geschäftswerte und falls nicht, was hätte besser gemacht werden können?
2. Der Prozess. Welche Verbesserungen kann es beim Prozess geben? Was wurde richtig gemacht? Was war falsch? Welche Änderungen wurden benötigt?

In meinem Projekt Ende 2017 wurden Retrospektiven typischerweise am Ende des Sprint Reviews am letzten Freitagabend des Sprints durchgeführt. Es war wenig überraschend, dass das Team versuchte, die Treffen möglichst kurz zu halten. Der Großteil des Teams versuchte nicht aktiv am Austausch teilzunehmen und die Session schweigend zu erdulden. Die drei typischen Fragen –  was sollte das Team zukünftig ausprobieren, was weiterhin tun und was unterlassen – führten schnell zu einem Spiel der gegenseitigen Schuldzuweisungen. Eine typische Konversation lief wie folgt ab:

J: Wir sollten anfangen, regelmäßige Testberichte über unsere Builds zu erstellen.

S: Das würde mehr Arbeit für mich bedeuten, dass ich diese Berichte unterschreiben müsste. Das kann ich nicht tun.

J: Wir sollten es trotzdem als Teil von“ Was sollten wir demnächst ausprobieren?“ erwähnen.

M: Worin liegt der Sinn, es hinzuzufügen, wenn es keine Ergebnisse geben wird? Das Management hat uns nie geholfen. Ich erinnere mich an letzten Sprint, wir hatten gefragt … …

Wie im Burndown Chart gezeigt, waren die Ergebnisse in den ersten beiden Sprints sehr unbefriedigend und die Prognose für den 3. Sprint sogar noch schlechter. Auch die Retrospektiven hatten keine umsetzbaren Erkenntnisse geliefert, die Durchführung war alles andere als optimal und die Teilnahme der Anwesenden weitestgehend minimal. Die Zeit war reif für einige Verbesserungen innerhalb der Retrospektive.

Kontinuierliche Verbesserungen

„Kontinuierliche Verbesserung ist besser als verzögerte Perfektion“ – Mark Twain

Die Verbesserungen, die ich im Folgenden beschreibe, basieren auf dem Buch „Agile Retrospectives“ von Esther Derby & Diana Larsen. Als Facilitator habe ich angefangen, folgendes sicherzustellen:

1. Ich machte das Team auf die von Norman Kerth formulierte Prime Directive¹ aufmerksam: „Unabhängig von dem, was wir im Zuge der Retrospektive entdecken, wissen wir, dass jeder in der konkreten Situation mit seinen Fähigkeiten und Fertigkeiten, und dem Wissen zu dem Zeitpunkt sein Bestes gegeben hat. Daran glauben wir fest.“ Die Verständigung auf dieses Mindset gibt einem Team ein Gefühl der Sicherheit, so das alles im Team ohne Angst diskutiert werden kann.
2. Basierend auf den Richtlinien des Scrum Guides habe ich die Besprechung für einen 3-wöchigen Sprint auf 2 Stunden beschränkt. Das half den Teammitglieder sich zu konzentrieren und reduzierte langatmige Diskussionen, die das Team nicht weiterbrachten.
3. Ich stellte sicher, dass alle Aktionen mit physischen Aktivitäten verknüpft wurden. Gleichzeitig reduzierten wir die parallele Verwendung elektronischer Geräte, denn Mitarbeiter, die mit Stift und Papier arbeiten, neigen dazu, sich stärker auf die anstehende Aufgabe konzentrieren zu können. Nach meiner Erfahrung steigt dadurch auch die Qualität der Gedanken.
4. Die Mitglieder wurden über Folgemaßnahmen informiert, die basierend auf den Erkenntnissen der Retrospektive entstanden. So hatte ich explizit geplant, am kommenden Montag ein Treffen mit dem Produktmanagement zu veranstalten, basierend auf Problemen, die während der Besprechung und in den Folgesitzungen wöchentlich gemeldet wurden.
5. Innerhalb der Retrospektive nutzte ich Timeboxing und verschiedene Spiele. Zusätzlich vereinbarten wir einfache, gemeinsame Regeln:
   – Wir greifen niemanden persönlich an.
   – Wir diskutieren lediglich Punkte, von denen wir glauben, dass sie sich auch wirklich lösen lassen.
   – Konflikte sind gut und jeder Konflikt muss innerhalb des Treffens behandelt werden. Eine Ausweitung des Konflikts sollte die individuelle Zusammenarbeit außerhalb des Meetings nicht beeinträchtigen.

Die fünf Stufen

Setting the Stage – Die Bühne bereiten

Das Entwicklungsteam saß sich in einem Halbkreis gegenüber. Hindernisse wie Tische wurden entfernt. Der Product Owner wurde eingeladen, denn Erkenntnisse aus dem Produktmanagement sind für die Entwicklung sehr wertvoll. Als Variante der Retrospektive hatte ich ESVP ausgewählt, denn ich wollte herausfinden, ob ein Teilnehmer zögerte teilzunehmen und wenn ja, warum? Als Zeitfenster für diese Aktivität hatte ich 15 Minuten eingeplant. Das Ziel von ESVP liegt in der Identifikation von Personen, die zu einer bestimmten Identität gehören: E = Explorer, S=Shopper, V=Vacationer und P= Prisoner. Keiner der Teilnehmer identifizierte sich jedoch als Prisoner bzw. Gefangener. 2 Teilnehmer sahen sich als Urlauber. Es bestand also grundsätzlich Interesse an der Retrospektive, auch wenn sie in der Vergangenheit nicht aktiv gelebt wurde. Ich beschloss zum Abschluss des Treffens um Handzeichen zu bitten, um zu erkennen, ob und wie sich die Haltung der Teilnehmer durch den Austausch verändert.

Gather Data – Sammeln Sie Daten

Das Sammeln von Daten bietet für das Team reichlich Gelegenheit zu erkennen, welche Leistungen es vollbracht hat und wie gut diese waren. Für diese Aktivität plante ich eine Timebox von 30 Minuten ein. Ich bat das Team, Ereignisse zu identifizieren, die während des Sprints mit einer bestimmten Emotion in Verbindung standen:

• „Mad“ waren jene Ereignisse, die während des Sprints keinen Platz gefunden hatten.
• „Sad“ waren jene Ereignisse, die eine negative Emotion hervorriefen.
• Und „Glad“ waren jene Ereignisse, die mit positiven Emotionen gekennzeichnet wurden.

Die Einschätzung der Ereignisse kann aus einem professionellen oder einem persönlichen Blickwinkel erfolgen; beide Varianten waren erlaubt und sogar erwünscht. Die Ereignisse wurden auf Post-Its geschrieben und auf einem Flipchart angebracht. Nach dem Ablauf der Timebox besprachen alle Mitglieder jedes einzelne Elemente mit dem Ziel, es gemeinsam etwas besser zu verstehen. Wir gruppierten einzelne Post-Its, um sie in der nächsten Phase detaillierter zu besprechen, doch zuvor galt es einige Herausforderungen zu meistern:

1. Ein Mitglied teilte mit, dass er keine spezifischen Kommentare zu diesem Sprint habe. Ich ermutigte ihn, allgemein über das Projekt zu sprechen.
2. Einige andere Mitglieder waren besorgt, dass Einzelpersonen als Problemmacher identifiziert werden könnten. Ich teilte ihnen mit, dass wir einen vertrauensvollen Raum vereinbart hatten. Zusätzlich waren alle Post-Its einfarbig und somit anonym.
3. Wann immer ein Item am Flipchart auftauchte, dass eine Person in irgendeiner Weise beschuldigte, haben es wieder entfernt.

Die zögerlichen Mitarbeiter waren am Ende dieser Aktivität vom Vorgehen überzeugt. Ich konnte deutlich sehen, dass diejenigen, die zu Beginn noch etwas skeptisch waren, sich aktiv am Austausch beteiligten. Zusätzlich habe ich darauf geachtet, dass auch jedes Mitglied mindestens ein Item beigetragen hatte und so seine Meinung kundtat. Darüber hinaus war es eine gute Basis für die nächste Aktivität im Rahmen der Retrospektive.

Die „glücklichen“ und „traurigen“ Ergebnisse der Retrospektive

Gather Insigths – Erkenntnisse sammeln

Der Vorteil dieser Aktivität liegt in der Möglichkeit, ein Problem in einer relativ kurzen Zeit zu erörtern. Da wir diese Aktivität zum ersten Mal gemeinsam durchführten, wurde die Timebox auf 40 Minuten gesetzt. Mit mir waren wir acht Teilnehmer, so dass wir zwei 4er Gruppen bildeten und die gesammelten Daten der vorherigen Aktivität auf beide Gruppen aufteilten. Nach einem Round-Robin-Verfahren stellte jedes Mitglied der Gruppe dem nächsten Mitglied bis zu fünf „Warum“-Fragen in Bezug auf das vorliegende Thema. So gab es bspw. folgenden Dialog:

S: Warum glaubst Du, konnte wir uns im Sprint nicht auf alle Mitglieder verlassen?

R: Weil Teammitglieder sich nicht auf das Sprint-Ziel und die einzelnen User Storys committed hatten!

S: Warum waren sie nicht committed?

R: Weil die Teammotivation niedrig war!

S: Warum war denn die Motivation nach dem vorherigen Sprint-Review so niedrig?

R: Weil die Leistung während der Demo nicht gewürdigt wurde und es auch keinerlei Lob gab!

S: Warum gab es keine Belobigung?

R: Weil das anwesende Management nur nach Fehlern und nicht nach Erfolgen geschaut hat!

Häufig führt das 4. oder 5. „Warum“ zum Kernproblem eines Items, im Beispiel also fehlende Anerkennung und das stete Suchen nach Fehlern. Solche Erkenntnisse wurden in den Gruppen notiert. Nach 30 Minuten beendeten wir die Aktivität, um in den verbleibenden 10 Minuten gemeinsam über die Erkenntnisse zu debattieren. Die Ergebnisse wurden wieder gruppiert. Es war gut zu sehen, dass sich alle Mitglieder an der Diskussion beteiligten und mit Leib und Seele dabei waren, Kernprobleme zu identifizieren. Zum ersten Mal entstand das Gefühl, dass sie gemeinsam durch den Austausch etwas zum Positiven verändern könnten.

Decide what to do – Entscheiden, was zu tun ist

In der nächsten Aktivität der Retrospektive ging es darum, gemeinsam im Team relevante, spezifische, erreichbare und messbare Ziele aus den Ergebnissen der vorherigen Phase abzuleiten. Als Timebox vereinbarten wir 20 Minuten. Ich bat das Team, smarte Ziele zu den Themen zu formulieren und kleine, spezifische Aufgaben abzuleiten, um diese zu erreichen. Zusätzlich sollten sie gemeinsam messbare Kriterien für die Aufgaben vereinbaren, sowie einen Zeitrahmen und verantwortliche Mitarbeiter vereinbaren. Diese Aufgaben waren jedoch nicht nur für Teammitglieder gedacht, sondern auch für andere Stakeholder. Ich hatte im Vorfeld bereits für die kommenden Woche Treffen mit anderen Interessengruppen organisiert, um diese Maßnahmen zu diskutieren und sie bei der Überwachung zu unterstützen. Am Ende dieser Phase war das Team äußerst begeistert und fast alle Mitglieder ergriffen Initiativen für einzelne Aufgaben. Einige Aufgaben wurden sofort dem Product Backlog hinzugefügt, da der Product Owner an dem Austausch teilnahm. Zusätzlich wurde beschlossen, dass andere Aufgaben zeitnah adressiert würden. Sämtliche Erkenntnisse wurden dokumentiert, so dass sie für die nächste Retrospektive wieder zur Verfügung standen und der Fortschritt entsprechend visualisiert werden konnte.

Close the Retrospektive – Abschluss der Retrospektive

Diese Aktivität habe ich gewählt, da ich die Retrospektive positiv beenden wollte. Ich bat jedes Teammitglied, anderen Teammitgliedern oder Stakeholdern, auch wenn sie vielleicht gar nicht anwesend waren, eine wertschätzende, positive Rückmeldung zu geben. 10 Minuten waren für diese Aktivität eingeplant und diese 10 Minuten halfen jedem Mitglied, die positive Energie im Team zu spüren und weiterzutragen. Schon am nächsten Tag wurden erste Veränderungen innerhalb des Teams sichtbar. Die Mitglieder begannen sich gegenseitig zu unterstützen. Die Gruppe fing an, sich als Team zu sehen. Auch über die Grenzen des Teams hinaus begannen Mitglieder, ihr Wissen mit anderen Teams zu teilen und das führte sogar zu einer schrittweisen Veränderung der gesamten Organisationskultur.

Fazit

Die Sprint Retrospektive ist eine der wichtigsten Zeremonien, die es in agilen Prozessen gibt. Wird sie richtig angewandt, bietet sie einem Team nicht nur den Raum für Verbesserungen, sondern ermöglicht auch eine Kultur der Zusammenarbeit und des Erfolgs. Es gibt verschiedene Möglichkeiten, Retrospektiven erfolgreich zu gestalten. Eine Möglichkeit habe ich Ihnen skizziert. Natürlich können auch andere Vorgehensweisen zum Erfolg führen. Der Erfolg hängt von den Erwartungen und den erzielen Erleichterungen für das Team und seine Mitglieder ab. Achten Sie vor allem auf ein Setup, in dem jeder ohne Angst seine Meinung äußern kann. So wird aus einer Retrospektive eine kontinuierliche Verbesserungsmaßnahme, die nach und nach dazu beitragen wird, eine neue Kultur im Team einzuführen und gleichzeitig dessen Produktivität zu steigern. Stellen Sie jedoch sicher, dass bei der Durchführung der Aktivitäten stets das Ethos der Organisation berücksichtigt wird. Der kulturelle Wandel findet schrittweise statt und kann nicht verordnet werden. Die Takeaways sind die Informationen, die ich aus meiner Erfahrung abgeleitet habe, und die anderen helfen können, die sich in ähnlichen Situationen befinden.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Mit Zustimmung von Saugata Das übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche.

[1] https://www.benlinders.com/2015/retrospective-prime-directive-translations/

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.