Inhaltsverzeichnis
Retrospektiven sind ein fester Bestandteil der agilen Kultur. Doch in einer Welt mit begrenzten festen Bestandteilen wird jede Zeremonie wichtig.
In diesem Artikel werfen wir einen kritischen Blick auf die Sprint Retrospektive, enthüllen häufige Fehler und zeigen, wie sie effektiver gestaltet werden kann. Denn trotz ihrer Bedeutung scheinen viele Teams und Organisationen mit ihrer Umsetzung zu kämpfen.
Was ist eine Sprint Retrospektive?
Die Sprint Retrospektive ist eine regelmäßige Besprechung in agilen Teams, die am Ende eines Sprints stattfindet. Ihr Zweck ist es, gemeinsam auf den vergangenen Sprint zu reflektieren, Erfahrungen auszutauschen und Verbesserungsmöglichkeiten für den nächsten Sprint zu identifizieren.
Um es einfach auszudrücken, das Wesentliche einer Retro besteht in der Verbesserung der Prozesse im Team.
Retrospektiven sind zweifellos ein fester Bestandteil der agilen Kultur. Sie gehören dazu, stehen in einer Reihe von Zeremonien neben Review, Planning, Daily Standups und… und… was eigentlich noch?
Sehen wir uns das näher an, stellen wir fest, es gibt gar nicht so viele feste Bestandteile dieser agilen Kultur. Je nachdem in welcher Skalierung wir uns bewegen, kommen noch PI Plannings, SoS dazu.
Organisationen sehen sich da oft schon genötigt, eigene Regeltermine für irgendwelche Themen zu erfinden, da sie das Gefühl haben, mit so wenig nicht auszukommen.
Warum sind Sprint Retrospektiven so wichtig?
Warum sind die Sprint Retrospektiven oft nicht effektiv?
So weit so gut. Was allerdings dann schon etwas überrascht, ist die Tatsache, dass sich kaum jemand sehr daran stört, dass Sprint Retrospektiven in den allermeisten Organisationen und Teams nicht besonders effektiv sind.
In diesem Artikel rechnen wir schonungslos mit der Retrospektive ab, klären, woran dies liegt und sehen, wie es besser laufen wird. Ja „wird“, nicht könnt.
Zunächst mal zu den Schuldigen.
Es sind ausnahmsweise mal nicht die Scrum Master bzw. Agile Coaches, die vielleicht nicht wissen, wie man eine gute Retro moderiert.
Es sind auch nicht die Organisationen bzw. irgendwelche Manager oder Stakeholder die an Retros gar nicht teilnehmen, aber die sehr oft in Abwesenheit für Missstände verurteilt werden und an die dann Retro-Findings gerne adressiert werden (die armen Scrum Master haben dann die ehrenvolle Aufgabe, die Botschaft den betroffenen Managern und Stakeholdern zu überbringen, natürlich mit den besten Wünschen des Teams).
Es sind auch nicht die Teams, die entweder keine Lust auf Retros haben, den Sinn nicht sehen, weil ihre Empfehlungen an das Management sowieso nicht gehört werden, oder einfach das nächste Release noch vorbereiten müssen und schlicht keine Zeit für Laber-Runden haben (Verständnis sowieso nicht).
Es sind auch nicht die Product Owner, die oft durch Abwesenheit glänzen, oder gar nicht eingeladen werden, weil sie oft gleichzeitig eine disziplinarische Rolle in der Organisation haben (Team Lead, Projektleiter).
Und es ist auch nicht die Anonymität, in die sich viele Retro-Moderationen flüchten, weil in Organisationen, denen „agile“ verordnet wurden und die jetzt agile „spielen“ ohne es zu sein, eine transparente, offene und wechselseitig wertschätzende Kommunikation (noch) unmöglich scheint.
Nein, der Schuldige ist – und das mag zunächst überraschend klingen – die Retro selbst.
Wie kann das sein? Die Sprint Retrospektive ist doch nur eine Zeremonie. Genau, und beide sind schuld daran, sowohl die Bezeichnung „Retrospektive“ als auch die zeremoniale Aufführung dieser Veranstaltung. Wir werfen mal einen Blick auf beide Begriffe und der Nebel wird sich rasch aufklären:
Häufige Fehler bei den Sprint Retrospektiven
Retrospektive erinnert mich immer mehr als eine Aufführung des Schaffens eines Künstlers in einem sterilen Ausstellungsraum, wie eine Kunsthalle oder Galerie. Die Künstler sind meist bereits tot und ihr Werk soll vor dem Vergessen gerettet werden. Kunsthallen und Galerien sind Orte, wo Kunst ausgestellt wird, nicht Orte, wo Kunst erschaffen wird.
Gleiches gilt für Retrospektiven, sie betrachten, sie erschaffen nicht – oder in agile-Sprech transformiert, sie schauen auf zurückliegende Probleme, sie lösen sie nicht – zumindest, solange man das bloße benennen, adressieren und vielleicht sogar delegieren nicht als Lösung ansieht.
Dem Begriff Zeremonie ergeht es noch schlimmer. Viele Retros laufen nach einem bestimmten Schema ab – eine Zeremonie eben. Die Leute kleben brav ihre gelben, blauen, roten und grünen Zettelchen auf die Wand oder das digitale Board (ja, selbst dort hat man die Zettelchen digital imitiert, was den Charakter der Zeremonie nur noch unterstreicht – oder karikiert, je nach Perspektive). Dann wird ordentlich gruppiert und gevotet, manchmal auch noch diskutiert, meist ist die Timebox dann bereits so gut wie abgelaufen.
Also werden in den verbleibenden 7 Minuten noch Rasch Maßnahmen beschlossen, meist Empfehlungen, was andere tun sollten. Wochen später sitzt man wieder zusammen und das Spiel geht von vorne los, nur selten wird geschaut, was aus den Dingen der letzten Retro geworden ist, oder es wird geschaut und zur Kenntnis genommen, dass nicht viel passiert ist, was die Motivation für die dann aktuelle Retro auch nicht gerade hebt.
Jeder Retro-Veranstalter, der das hier liest wird sagen, Blödsinn, bei uns laufen die Retros viel besser, wir haben gute Diskussionen, wir tracken und sind transparent und ehrlich und offen und alle machen das total gerne und regelmäßig, alles super. Und doch habe ich wenige Teams gesehen, in denen sich auf Grund durchgeführter Retros im Verlauf von – sagen wir mal – 3 bis 6 Monaten wirklich substantiell im agilen Prozess, agilen Mindset etwas geändert hat.
Gleichzeit wäre der Bedarf an Änderung und Verbesserung in den meisten Teams signifikant da.
Wo steht die Sprint Retrospektive im agilen Prozess
Wie führt man eine Sprint Retrospektive richtig durch?
Dann sagt der Name „…Inspect & Adapt“, dass es zu 50% um Inspect – also was war – und zu 50% um Adapt – also was ändern wir – geht.
Dann stellen wir uns vor, dass die Leute im Meeting nicht unvorbereitet in das Meeting kommen. Also nicht vom Moderator hören „Denkt mal 10 Minuten über dies und das nach, schreibt es auf einen Zettel und klebt den an die Wand“, sondern hören, „Wir haben in unserem Improvement Backlog, wo jeder von Euch jederzeit Dinge einstellen kann (auch Scrum Master, Product Owner, Stakeholder), diese und jene Items, die wir jetzt nach einer (meinetwegen angepassten) WSJF-Methode priorisieren, bzw. die aktuelle Priorisierung ansehen und gegebenenfalls verändern und dann das oberste Item zum Gegenstand eines Plannings inklusive Implementierungsplan machen, also nicht nur sagen, was wir verbessern wollen, sondern präzise wann und wie.
Dann schauen wir in unsere „agile Process Inspect & Adapt- DoR“ (Definition of Ready) – lesen dort, dass die Maßnahmen so geschnitten sein müssen, dass sie – oder zumindest einige – im kommenden Sprint umsetzbar sind, lesen dort auch, wieviel Kapazität für diese Process-Improvement-Items mindestens zur Verfügung stehen muss (ist mit der Organisation ausgehandelt) und ziehen genauso viele in den Sprint hinein. Diese Items werden zum regulären Gegenstand des nächsten Sprints, werden also genauso behandelt, wie User-Storys und werden somit auch als Gegenstand in den Daily-Standups und im Sprint Review geführt.
Jetzt stellen wir uns noch vor, dies passiert in jedem Sprint, routinemäßig und ohne Ausnahme, auch unter Anwendung einer DoD (Definition of Done).
Und nun am Ende angekommen, kann jeder Organisator einer Retro dieses Vorgehen mit seiner eigenen Retro der Vergangenheit vergleichen. Ziehen Sie selbst Ihre Schlüsse.
Zusammenfassung – 8 Schritte zur erfolgreichen Retrospektive
Hier sind die wichtigsten Punkte zur richtigen Durchführung einer Sprint-Retrospektive zusammengefasst.
👉 Am Ende jedes Sprints sollten Teams eine Sprint Retrospektive (Inspect & Adapt Session) durchführen, die sich ausschließlich auf den agilen Prozess konzentriert.
👉 Die Session teilt sich zu 50% in „Inspect“ (Was ist passiert?) und zu 50% in „Adapt“ (Was ändern wir?) auf.
👉 Die Teilnehmer sind vorbereitet und nutzen ein Improvement Backlog, in dem jeder Vorschläge einstellen kann.
👉 Die Priorisierung erfolgt nach einer (angepassten) WSJF-Methode, und das oberste Item wird Gegenstand eines detaillierten Plannings.
👉 Die „agile Process Inspect & Adapt- DoR“ legt fest, dass Maßnahmen im nächsten Sprint umsetzbar sein müssen, und es wird eine minimale Kapazität verhandelt.
👉 Die ausgewählten Maßnahmen werden wie User-Storys behandelt und sind Teil der Daily Standups und Sprint Reviews.
👉 Dieser Prozess wiederholt sich in jedem Sprint ohne Ausnahme, unter Anwendung einer Definition of Done (DoD).
👉 Am Ende jeder Retro kann der Organisator dieses Vorgehen (normarlerweise der Scrum Master) mit vorherigen Retros vergleichen, um Fortschritte zu bewerten.

Was hat die Neuregelung des AÜG mit Scrum zu tun? Ich meine viel und möchte auf die neuen Herausforderungen, die sich daraus für die Planung von SCRUM Projekten in vielen Unternehmen ergeben in diesem Artikel eingehen.

Scrum vs. Wasserfall – Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht..

Der Erfolg von agilen Projekten hängt mit der Kommunikation zusammen! Leonardo DiCaprio in seiner Rolle in ‚Inception‘ ist heute Ihr Scrum Coach und verdeutlicht, wie in Scrum erfolgreich kommuniziert werden kann. Klingt abenteuerlich? Ist es auch 🙂 Lesen Sie weiter…