Was ist die Sprint Retrospektive?

Retrospektiven bilden die Grundlage für den Inspect- und Adapt-Mechanismus des Scrum Frameworks in der agilen Softwareentwicklung. Die Sprint Retrospektive dient der prozessualen Betrachtung des letzten Sprints und erlaubt dem Scrum Team, den Prozess, also das tatsächliche Tun zwischen Produkt, Backlog (Konzept) und auslieferbarer Software zu analysieren und aus den Erfahrungen zu lernen. Es ist, wie auch die anderen Scrum Events (wie zum Beispiel, das Sprint Planning), ein „timeboxed“ Event und dauert in der Regel 2 Stunden bei einem 2-wöchigen Sprint. Es dient dazu, konkrete Maßnahmen zu identifizieren, die das Scrum Team im nächsten Sprint umsetzt, um sich auf Basis des Gelernten zu verbessern. Das Ergebnis einer Sprint Retrospektive sind also Prozessverbesserungen.

‍

Retrospektiven helfen somit Teams, besser zu werden und die Zusammenarbeit zu optimieren. Sie sind ein Katalysator für Veränderung. Sie erzeugen Handlungen, die zu Verbesserungen führen und treiben damit einen Changeprozess aus dem Scrum Team heraus an. Bei der Betrachtung des Prozesses werden zunächst Probleme gelöst, die das Team selbst betreffen. Mittelfristig werden aber auch teamübergreifende Veränderungsprozesse sowie Veränderungen, die die gesamte Organisation betreffen, angestoßen.

‍

‍

Das Sprint Retrospective Meeting ist daher eine der zentralen Events in Scrum und nimmt durch Transparenz, Überprüfung und Anpassung (die 3 Scrum Säulen) die laufende Verbesserung des Entwicklungsprozesses in den Fokus, wohingegen der Sprint Review auf die Verbesserung des Produktes abzielt. 

Scrum etabliert durch sein iteratives und inkrementelles Vorgehen einen kontinuierlichen Verbesserungsprozess (KVP) und zwar auf zwei Ebenen. Jene des zu entwickelnden Produktes selbst (also betreffend das WAS) und jene des Entwicklungsprozesses (das WIE).

Der Zweck der Sprint Retrospektive ist es, Wege zur Steigerung von Qualität und Effektivität im Entwicklungsprozess zu identifizieren und zu planen. Das Scrum Framework unterstützt somit das Team, den Scrum Prozess laufend zu verbessern.

‍

‍

Was beinhaltet eine Sprint Retrospektive?

Das Scrum Team überprüft am Ende des jeweiligen Sprints, wie dieser in Bezug auf die Individuen, Interaktionen, Prozesse, Werkzeuge und der Definition of Done verlaufen ist.

Es identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern und entscheidet autonom hinsichtlich deren Umsetzung, indem es diese in den Product Backlog oder für zeitnahe Realisierung in den Sprint Backlog übernimmt.

Eine kontinuierliche Verbesserung des Produktes und das Prinzip, die Anwenderinnen durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen, ist ohne die laufende Verbesserung des Entwicklungsprozesses nicht vorstellbar. 

Im Kern geht es darum, auf Team-Ebene zu lernen. Retrospektiven unterstützen diesen Lernprozess aktiv. 

Scrum Teams, die gute Retrospektiven durchführen, verbessern sich im Laufe von nur wenigen Sprints so deutlich, dass dies in vielen Bereichen sichtbar wird:

• Gesteigerte Produktivität: Teams identifizieren dysfunktionale Elemente und Engpässe in ihren Prozessen und entfernen sie mithilfe von Retrospektiven.
• Gesteigerte Qualität: Das Team diskutiert und analysiert, warum die innere und äußere Qualität der Lieferungen nicht ihren eigenen und den Erwartungen der Kunden entspricht. Die Retrospektive hilft ihnen dabei, die richtigen Handlungen zur Qualitätsverbesserung zu setzen und so zukünftigen technical debt zu vermeiden.
• Steigende Fähigkeiten: Scrum Teams sind dazu angehalten, ihre Performance und Fähigkeiten stetig zu verbessern. Retrospektiven unterstützen sie dabei, indem sie Schwachstellen aufzeigen und durch kollektive Kreativität des Teams bessere Lösungen zu finden.
• Verbesserte Zusammenarbeit: Retrospektiven helfen, die Zusammenarbeit im Scrum Team und darüber hinaus zu verbessern, effizienter zu gestalten und damit produktiver zu werden. Die Praxis zeigt, dass insbesondere in diesem Bereich große Potenziale liegen.
• Gesteigerter Durchsatz: Scrum Teams, die regelmäßige Retrospektiven durchführen, werden nicht nur effizienter, sondern auch effektiver. Dadurch erhöht sich der „Durchsatz“ – also die Kapazität des Teams, neue Anforderungen in lauffähige Software umzusetzen.

Neben diesen offensichtlichen Ergebnissen zeigt sich auch, dass Scrum Teams, die effektive Retrospektiven durchführen, mehr Spaß an der Arbeit und ein signifikant höheres Maß an Motivation haben. Dennoch sind in der Praxis wiederkehrend „Abkürzungen“ und suboptimale Umsetzungen zu beobachten.

‍

Sie wollen erfahren, wie Sie den perfekten Partner im Bereich Softwareentwicklung finden? Hier geht's zum Leitfaden „10 Dinge, die Sie bei der Auswahl Ihres Softwareentwicklungs-Partners unbedingt beachten müssen.“

‍

4 typische Fehler, die im Zuge der Sprint Retrospektive passieren

1. Die Sprint Retrospektive als optionales Event 

Das Scrum Team oder die Stakeholder haben den Wert der Retrospektive nicht ausreichend verstanden und verinnerlicht. Auf die Retrospektive wird im Einzelfall verzichtet oder sie wird verschoben, um beispielsweise mehr Zeit für die Erreichung des Sprint-Ziels verfügbar zu haben. Manchmal wird sich auch deutlich gekürzt. Derartige vermeintliche Abkürzungen sind eine risikobehaftete Gratwanderung, denn wenn diese einmal akzeptiert wurden, wird in weiterer Folge häufig die Retrospektive generell infrage gestellt. 

Dass es im Team hinsichtlich Kommunikation, Mindest- oder eingesetzter Tools nichts zu verbessern gibt, was in den Wert des zu entwickelnden Produktes einzahlt, ist eine gewagte und völlig unrealistische These. Außerdem kontaktiert dieses Verhalten die Grundprinzipien wie Empirie und kontinuierliche Verbesserung völlig.

Stellen Sie daher sicher, dass in Ihrer Organisation der Wert der Retrospektive ausreichend gut verstanden wird und schaffen Sie Raum und Zeit für deren Durchführung.

‍

‍

2. Bei jedem Sprint grüßt das Murmeltier

Die Sprint Retrospektive ist nicht nur ein Event einer faktenbasierten Analyse darüber, was gut und schlecht gelaufen ist, sondern auch ein Raum kollektiver Kreativität und gegenseitiger Inspiration. Es geht darum, Maßnahmen zur Verbesserung zu entwickeln. Dies bedingt allerdings auch, dass die Praktiken, die Struktur oder der Ort, nicht permanent gleich bleiben sollten. Es ist wichtig, durch wechselnde Formate Reize bzw. Stimuli zu schaffen. Ansonsten läuft man Gefahr, dass zunehmende Passivität der Teammitglieder, oder sogar Langeweile um sich greift. Dies führt letztlich dazu, dass die Retrospektive als Zeitverschwendung betrachtet wird.

Unsere Empfehlung: Eine umfangreiche Sammlung von Formaten und Sprint Retrospektiven Beispiele finden Sie unter Retromat.

‍

‍

3. Mangelnde psychologische Sicherheit

Die Retrospektive muss ein sicherer Ort sein, an dem jedes Teammitglied Probleme ansprechen und sein Feedback mit dem gebotenem Respekt frei von Angst sowie Einflüssen Dritter geben kann. Wenn einzelne Teammitglieder das Gespräch dominieren und somit andere dadurch einschüchtern, wird die Retrospektive keine psychologische Sicherheit bieten. Daraus folgt häufig, dass sich einzelne TeilnehmerInnen aus der Retrospektive zurückziehen, passiv werden und somit die kollektive Intelligenz des Teams nicht in vollem Umfang zur Geltung kommt. 

Besonders heikel wird es dann, wenn es Hierarchien zwischen den Mitgliedern eines Scrum-Teams gibt. Beispielsweise Junior-EntwicklerInnen, die an Senior-EntwicklerInnen im selben Scrum-Team berichten oder Vorgesetzte außerhalb des Scrum Team sich in die Retrospektive hineinreklamieren. Die Retrospektive ist kein Event einer kontinuierlichen Mitarbeiterbeurteilung. In solchen Szenarien ist der Scrum Master besonders gefordert.

Im Worst Case artet die Retrospektive in gegenseitiges Finger-Pointing und Schuldzuweisungen aus. Darüber hinaus wird die Retro, dann kein Ort von psychologischer Sicherheit sein, wenn einzelne Teammitglieder, Außenstehenden Auskunft über die Retro geben oder das Protokoll enthüllen. Hier gilt die Vegas-Regel: Was gesagt wird, bleibt unter den Teilnehmern der Retrospektive. Die Ergebnisse und geplanten Maßnahmen zur Verbesserung sind dann ohne dies durch den Product Backlog transparent.

Stellen Sie sicher, dass alle die Möglichkeit haben, ihre Gedanken frei zu äußern und diese auch gehört werden. Wichtig ist auch, dass ein respektvolles Miteinander herrscht und es zu keinem „Blame Game“ kommt sowie die Autonomie des Teams gewahrt bleibt.

4. Kein Adapt, keine Umsetzung

Das Team überprüft nicht den Status der geplanten Verbesserungen aus früheren Retrospektiven. Wenn ein Team für sich in Anspruch nimmt, autonom Entscheidungen zu treffen, um den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen, bedeutet dies auf der anderen Seite entsprechende Selbstverpflichtung und Eigenverantwortung. Wenn das Team die geplanten Aktivitäten der Verbesserung nicht verfolgt und somit kein „Inspect“ stattfindet, ist die Etablierung des KVP Prozesses gescheitert.

Ein weiteres Szenario ist, dass Verbesserungspotentiale im Entwicklungsprozess zwar identifiziert werden, aber niemand sich für dessen Weiterführung im Entwicklungsteam verantwortlich gemeldet hat. Dies führt in der Regel dazu, dass die folgende Umsetzung mangelhaft wird oder zur Gänze unter den Tisch fällt. Derartiges Arbeiten trägt zur Wahrnehmung bei, dass Scrum und „agile“ in der Praxis nicht funktionieren. 

Stellen Sie daher sicher, dass bei den Grundprinzipien der kontinuierlichen Verbesserung auch im Kontext der Retrospektive keine Abkürzungen genommen werden. In diesem Zusammenhang verweisen wir auf das Shu Ha Ri Konzept.

‍