Bei Scrum machen Sie eine Retrospektive am Ende jedes Sprints, unmittelbar nach dem Sprint Review. Die Retrospektive schließt den Sprint ab und dient dem kontinuierlichen Lernen — um von Sprint zu Sprint besser zu werden. Wie Sie eine Retrospektive erfolgreich durchführen und was die einzelnen Schritte dazu sind lernen Sie in diesem Artikel. Dieses Wissen kann natürlich auch sehr gut in traditionellen Projekten angewendet werden. Wie? Lesen Sie weiter und erfahren Sie mehr!
Kontinuierliche Verbesserung und stetiges Lernen
In Scrum führen Sie als letzte Aktivität eines Sprints die Sprint-Retrospektive durch. Das Ziel der Sprint-Retrospektive ist die kontinuierliche Verbesserung und das stetige Lernen. Bei traditionellen Projekten finden Retrospektiven, Lessons Learned oder Debriefings meistens erst am Projektende statt (wenn überhaupt). Dann aber nützen die Erkenntnisse daraus dem abgeschlossenen Projekt leider nichts mehr.
Agile Projekte machen dies besser. Bei Scrum machen Sie eine Retrospektive am Ende jedes Sprints, unmittelbar nach dem Sprint Review und schließen damit den Sprint ab. So können Sie das gelernte in den nächsten Sprints sofort anwenden.
Das Scrum Team analysiert in der Retrospektive seinen Arbeitsprozess und die Zusammenarbeit, mit dem Ziel der kontinuierlichen Verbesserung und dem stetigen lernen, gemäß dem Grundsatz „Inspect and Adapt“.
Dies soll nicht nur einen positiven Einfluss auf die Produktivität, Leistungsfähigkeit und die Softwarequalität haben, sondern soll auch die Freude an der Arbeit vergrößern.
Die Resultate der Retrospektive sind dann zum Beispiel verbesserte Entwicklungsprozesse, neue Teamnormen und Verhaltensregeln oder eine bessere Organisation der Arbeit. Die Verbesserungen können dann direkt beim nächsten Sprint angewendet werden und unterstützen so den kontinuierlichen Verbesserungsprozess im laufenden Projekt.
Es besteht immer Verbesserungspotential, auch wenn das Projekt erfolgreich läuft und das Team gut zusammenarbeitet. Dies ist der beste Weg zu wachsen – von Sprint zu Sprint – zu reiferen Prozessen und zu einem erfolgreicheren Team.
Retrospektiven unterscheiden sich von den anderen Scrum Meetings, da die Beteiligten für eine kurze aus der Projektarbeit heraustreten und offen und ehrlich über die Zusammenarbeit im Projekt reflektieren.
Die folgenden vier Kernfragen fokussieren bei der Retrospektive auf die Zusammenarbeit, Prozesse und Werkzeuge:
- Was lief gut? Was hat sich bewährt?
- Was haben wir gelernt?
- Was lief nicht gut? Was sollten wir nächstes Mal anders machen?
- Was gibt uns immer noch Rätsel auf?
Dies soll nicht nur einen positiven Einfluss auf die Produktivität, Leistungsfähigkeit und die Softwarequalität haben, sondern soll auch die Freude an der Arbeit vergrößern.
Vorbereiten der Retrospektive
Teilnehmer und Dauer
An der Sprint-Retrospektive nimmt das ganze Scrum-Team teil. Es ist die Aufgabe des Scrum Masters dieses vorzubereiten und zu moderieren. Falls sinnvoll können auf den Wunsch des Teams weitere Stakeholder eingeladen werden, zum Beispiel Manager. Dies kann sinnvoll sein, um die Beseitigung von Hindernissen zu besprechen oder projektübergreifende Versbesserungen zu diskutieren.
Für einen 4-Wochen-Sprint sollten Sie eine Time-Box von zwei bis drei Stunden für die Retrospektive einplanen.
Die Retrospektive wird vom Scrum Master vorbereitet, damit diese einen möglichst großen Nutzen generiert. Außer einem genug großen Raum sollten auch Flipcharts und evtl. Pinnwände vorhanden sein. Natürlich sollte sich der Scrum Master Gedanken machen über den Ablauf und die Themen, über die diskutiert werden soll. Auch sollte er die Maßnahmenliste von der letzten Retrospektive bereit haben.
Der Scrum Master als Moderator
Gemäß Scrum Guide ist der Scrum Master der Moderator der Retrospektive, beteiligt sich aber als Peer-Teammitglied gleichzeitig daran, als Verantwortlicher für den Scrum-Prozess.
Eine Retrospektive fordert die Moderationsfähigkeiten des Scrum Masters, besonders wenn ein Sprint mal nicht so gut gelaufen ist wie geplant oder Konflikte und zwischenmenschliche Probleme aufgetreten sind.
Wenn man weiß, dass die Retrospektive schwierig wird und der Scrum Master noch wenig Moderationserfahrung hat, dann kann es sinnvoll sein einen speziellen Moderator beizuziehen, der den Scrum Master unterstützt.
Eine schlecht geplante Retrospektive-Session schadet mehr als sie nützt. Die falschen Teilnehmer, unpassende Tagesordnungspunkte oder einfach unvorbereitet sein sind der Tod jeder Retrospektive-Sitzung, besonders wenn die Emotionen eh schon heißlaufen.
Der Ablauf der Retrospektive
Bei der Retrospektive sollten Sie einen gewissen Ablauf einhalten, auch wenn diese nur eine relative kurze Zeit dauert. Der Scrum Guide gibt nicht viele Anweisungen, wie eine Retrospektive durchzuführen ist. Die folgenden Fünf Schritte der Retrospektive haben sich in der Praxis bewährt und basieren auf der Arbeit von Norman Kerth, Boris Gloger und meinen Erfahrungen.
Die Retrospektive durchführen
Sicherheit schaffen
In der Retrospektive will das Team, aus den Ereignissen des beendeten Sprints vorbehaltlos und ohne Schuldzuweisung lernen. Eine Retrospektive braucht deshalb einen geschützten Raum, indem sich alle Beteiligten sicher fühlen. Sie brauchen die Gewissheit, dass ihnen durch ihre offenen und ehrlichen Äußerungen später nichts passieren kann.
Keine Schuldzuweisungen
Teilnehmer einer Retrospektive haben nicht selten Angst, dass diese zu einer Mecker-Session wird, mit Klagen und Schuldzuweisungen. Das wäre natürlich keine gute Voraussetzung viel zu lernen. Der Schlüssel zu einer erfolgreichen Session ist folgende Richtlinie vom Normant Kerth:
„Ohne Rücksicht was wir aufdecken, wir verstehen und glauben aufrichtig, dass jeder seinen besten Job gemacht hat, unter Berücksichtigung, was man zurzeit wusste, und den Fähigkeiten und Möglichkeiten sowie den verfügbaren Ressourcen.“
Am Ende jedes Sprints oder Projektes weiß jeder viel mehr. Deshalb ist es nur natürlich, dass man Entscheidungen und Aktionen entdeckt, die man am liebsten rückgängig machen will. Sich dafür rechtfertigen oder schämen zu müssen wäre absolut falsch. Dieses Wissen ist eine Chance daraus zu lernen und erfolgreicher zu werden.
Etablieren Sie deshalb in der Retrospektive ein Klima der Sicherheit und des Dialogs. Die Teilnehmer sollen sich sicher fühlen, damit Sie ihre wahren Beobachtungen und Empfindungen mitteilen.
Was waren die wichtigsten Ereignisse
Was ist dem Team vom letzten Sprint speziell im Gedächtnis geblieben? Eine Timeline-Analyse hilft den Teilnehmern die Vergangenheit des Projektes zu rekonstruieren und chronologisch zu ordnen. Dazu wird eine Zeitachse des Sprints, z.B. mit farbigem Klebebank an eine Wand geklebt. Auf dieser werden dann wichtige Geschehnisse in Form von Minigeschichten mittels Post-it Zetteln, Flipchartkarten, Fotos oder Gegenständen aufgeklebt.
Sie können dazu folgendermaßen vorgehen: Der Moderator teilt jedem Teilnehmer Karten aus. Die Gruppe erhält dann 5 Minuten Zeit, um wesentliche Ereignisse aufzuschreiben. Jeder arbeitet für sich und schreibt auf jede Karte ein Ereignis.
Dann geht jeder Teilnehmer nacheinander zur Timeline, befestigt seine Ereignisse an die passenden Stellen und erklärt in ein oder zwei Sätzen, wieso dieses Ereignisse für ihn während des Sprints wichtig waren. Das muss nicht zwingend einen Bezug zur Arbeit haben, es kann auch ein privates, persönliches Ereignis sein. Auf diese Weise erzählt er eine kurze Geschichte über das Ereignis. Wichtig ist, es werden nur subjektive Fakten gesammelt.
So erhält das Team einen guten Überblick über den Sprintverlauf. Was ist alles vorgefallen, wann ist passiert, was hat das Team bewegt? Mit einem Blick auf die Timeline voll Karten können Sie dann wahrscheinlich schon erkennen, ob es eher ein motivierendes Meeting gibt, oder eines, in dem die Teilnehmer Dampf ablassen müssen.
Oft sind die Scrum Teammitglieder selbst erstaunt, wie viele interessante Ereignisse es in der kurzen Sprintdauer gegeben hat. Sie erfahren auch voneinander, wie es jedem Einzelnen ergangen ist.
Erkenntnisse sammeln
In diesem Schritt geht es darum zu identifizieren und zu visualisieren, was im verlaufenen Sprint gut und was schlecht lief.
Was lief gut?
Hängen Sie an die Wand ein Flipchart mit dem Titel „Was lief gut?“ Jedes Teammitglied erhält einige Karten und hat fünf Minuten Zeit diese Frage zu beantworten. Dann geht jeder einzeln zum Flipchart, befestigt seine Karten und erzählt zur jeder Karte in ein oder zwei Sätzen eine kleine Geschichte. Am Schluss, wenn alle Karten auf dem Flipchart sind fragt der Moderator, ob noch etwas fehlt oder noch jemand etwas dazu sagen will.
Beispiele für „Was lief gut?“ sind:
- Wir konnten uns während der Ferienzeit gut vertreten
- Die Schätzungen in diesem Sprint waren besser als in den letzten zwei Sprints.
- In diesem Sprint hatte der Server W22 keine Ausfälle mehr
Was lief nicht gut?
Hängen Sie an die Wand ein Flipchart mit dem Titel „Was lief nicht gut, was können wir verbessern?“ Die nächsten Schritte sind gleich, wie bei „Was lief gut?“
Maßnahmen definieren
In diesem Schritt geht es darum Maßnahmen zu definieren, damit „Was gut lief“ noch besser wird, aber natürlich noch wichtiger „Was nicht gut lief“ besser wird. Was ist zu tun, wer kann, oder muss etwas tun, bis wann, um eine Veränderung zu bewirken?
Für jeden „schlechten Punkt“ muss eine Verbesserungsidee definiert werden.
Finden Sie die Grundursachen
Um das ganze Potential aus dem Schritt „Maßnahmen definieren“ herauszuholen und wenn Sie aus den Antworten lernen und evtl. Prozesse verbessern wollen, dann ist es wichtig zu wissen, warum es denn gut oder schlecht lief. Darum sollte der Moderator schauen, dass auch eine Ursache für jede Aussage „Was lief gut“ und besonders „Was lief nicht gut“ gesucht wird.
Mit W-Fragen (Warum, Wann, Wer usw.) gehen Sie dazu der Ursache auf den Grund. Hier ein Beispiel:
In diesem Sprint hatte der Server keine Ausfälle. Warum?
Antwort: Peter hatte mit der IT-Abteilung das Problem untersucht und….
Eventuell sind mehrere W-Fragen notwendig, um die wirkliche Grundursache herauszufinden, denn nur wenn Sie die Grundursache kennen, können Sie wirklich daraus etwas lernen, oder verhindern, dass Probleme und Fehler wieder auftreten.
Überprüfen der Maßnahmen der letzten Retrospektive
Sind einige Maßnahmen der letzten Retrospektive noch nicht umgesetzt? Nehmen Sie das Flipchart der letzten Retrospektive hervor und überprüfen Sie. Warum wurden einige Maßnahmen nicht umgesetzt? Sind sie nicht mehr relevant oder nicht praktikabel? Müssen Sie angepasst werden? Ist es notwendig diese weiter zu behandeln? Übernehmen Sie die noch offenen Maßnahmen, die am meisten Nutzen generieren und auch erreichbar sind und passen Sie diese bei Bedarf an.
Überprüfen der „Definition of Done“
Der Scrum Guide gibt nicht viele Anweisungen wie eine Retrospektive durchzuführen ist, was er aber empfiehlt, ist die „Definition of Done“ zu überprüfen. Das ist etwas, was viele Teams nicht machen. Gibt es Verbesserungspotential, was das Team unter „Done“ versteht?
Maßnahmen priorisieren
In diesem Schritt geht es darum zu definieren, wer kann welche Maßnahmen, bis wann umsetzen. Dabei müssen Sie folgendes beachten: Sie haben nicht über Alles die Kontrolle. Deshalb sollten Sie die Hindernisse, Probleme und die dazugehörigen Maßnahmen gruppieren in:
- Solche, die Ihr Team selbst verändern und verbessern kann
- Solche, die von der Organisation, vom Management oder dem Kunden verändert werden müssen
Dazu nimmt der Moderator ein Flipchart und teilt es in zwei Spalten ein: Team | Organisation. Dann verteilt das Team alle Probleme und die dazugehörigen Maßnahmen in die entsprechenden Spalten.
Die Liste der Probleme ist oft lang und es gibt Aufwand diese abzuarbeiten. Deshalb müssen Sie jetzt entschieden, wann, an welchen Verbesserungen gearbeitet werden soll.
Jetzt priorisiert das Development-Team und der Product Owner gemeinsam, welche Hindernisse und Probleme sofort gelöst werden sollten und welche Veränderungen dem Team die höchste Produktivitätssteigerung bringen – und dies für beide Seiten auf dem Flipchart für „Team“ und „Organisation“. Damit wird klar, was das Team umsetzen will und was es vom Scrum Master erwartet, was er mit er mit der Organisation verbessern will.
Am Ende der Retrospektive haben Sie zwei Listen als Ergebnis:
- Die Liste der Hindernisse und Probleme, die das Team lösen kann
- Die Liste der Hindernisse und Probleme, die der Scrum Master lösen muss
Um die linke Seite des Flipcharts „Team“ kümmert sich das Development-Team im nächsten Sprint Planning.
Die „Organisations“-Liste wird vom Scrum Master verwaltet und fließt in sein Impediment Backlog ein. Es ist seine Aufgabe, sich um diese so schnell wie möglich, in der entsprechenden Reihenfolge zu kümmern.
Die Maßnahmen sollten sofort angepackt werden. Das nächste Sprint Planning Meeting 1 ist der richtige Zeitpunkt dazu, darüber zu sprechen, welche Maßnahmen von der Liste im nächsten Sprint angegangen werden sollen und was diese eventuell für einen Aufwand bedeuten. Einige Maßnahmen geben vielleicht keinen Aufwand, weil es Verhaltensänderungen sind.
Um eine kontinuierliche Verbesserung zu gewährleisten empfiehlt der Scrum Guide 2017 mindestens eine Prozessverbesserung mit hoher Priorität, die in der letzten Retrospektive identifiziert wurde, in das Sprint Backlog aufzunehmen.
Am Ende der nächsten Retrospektive überprüfen Sie dann, ob die Maßnahmen umgesetzt wurden, und ob diese auch wirken. Es kann auch sinnvoll sein, für gewisse Maßnahmen einen oder zwei Termine im kommenden Sprint zu definieren, bei denen diese überprüft werden, dies können zum Beispiel geänderte Verhaltensregeln betreffen.
Was haben Sie für Erfahrungen mit Retrospektiven bei agilen Projekten gemacht? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung mit einem Kommentar den Lesern mit, damit wir alle eine weitere Sicht kennenlernen. Danke!
Hier gibt es noch mehr Wissen
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn in Ihrem Netzwerk. Vielen Dank!
