Im agilen Arbeiten sind Retrospektiven ein MUSS

Aus Projektfehlern lernen – die Retrospektive als helfendes Ritual
Kommentare

Die Grundlage agilen Arbeitens ist das ständige Lernen aus dem eigenen Handeln. Mit Retrospektiven hinterfragen alle Beteiligten das eigene Vorgehen regelmäßig und optimieren es. Doch im stressigen Projektalltag verliert die Retrospektive oft an Bedeutung. Immer wieder begegnet uns ein: „Wir machen Scrum, aber für Retrospektiven haben wir keine Zeit.“ Der Verzicht auf Retrospektiven ist der Verzicht auf den Motor und Hebel für Prozessverbesserungen – ein Plädoyer für gute Retrospektiven.

Unsere Schulzeit lehrte uns durch Klassenarbeiten und Klausuren, dass sich Fehler negativ auf unsere Ergebnisse auswirken. Die Nachbetrachtung unserer Fehler hat selten stattgefunden. Nur durch eigenes Engagement und selbstständiges Auseinandersetzen mit den Fehlern konnten wir eine Lehre für uns ziehen. Dabei ist die genaue Betrachtung von Fehlern und die Auseinandersetzung mit der Frage „Was konkret hätte ich anders machen können?“ die einzig zielführende Frage. Bleibt es bei der einfachen Schuldzuweisung an sich selbst, findet keine bewusste Veränderung des Vorgehens statt. Das Ziel, beim nächsten Mal mehr zu leisten, ist nicht messbar. Wann ist es genug? Was ist mehr? Und was konkret hätte uns in der Klassenarbeit oder der Klausur weiterhelfen können?

Aus Fehlern lernen

Agiles Arbeiten bietet mit der Retrospektive den passenden Methodenbaustein für die Beantwortung dieser konkreten Fragen. Es geht nicht darum, festzuhalten, wer an welcher Stelle an einem Fehler schuld ist, sondern darum, welche Veränderungen dazu beitragen können, die gemachten Fehler in Zukunft zu vermeiden. Einer der Gründe, warum Retrospektiven schwer Einzug in den Projektalltag finden, sind die alten Schulerfahrungen. Es ist uns unangenehm, über Fehler zu sprechen.

Routinen durchbrechen

Unbewusste Handlungen, die in Routinen übergegangen sind, erleichtern die tägliche Arbeit. Es kostet weniger Energie, Handlungen unbewusst zu wiederholen, statt Energie dafür aufzuwenden, die Handlungen in den Bewusstseinsraum zu holen und den gewählten Weg zu hinterfragen. Aus diesem Grund fallen Veränderungen, insbesondere die des eigenen Verhaltens, besonders schwer. Oft haben wir uns bestimmte Verhaltensweisen über Jahre hinweg selbst antrainiert. Wenn wir morgens aufstehen, machen wir uns nur selten Gedanken darüber, welche Handlungen notwendig sind, um erfolgreich Kaffee oder Tee zu kochen. Ebenso wenig stehen wir wohl morgens im Badezimmer und müssen uns überlegen, welche Schritte notwendig sind, um unsere Zahnbürste erfolgreich und zielführend im Mund verschwinden zu lassen. Es sind Routinen und Automatismen.

Auch in Projekten entwickeln wir unsere eigenen Routinen ‑ unabhängig davon, ob wir allein oder im Team arbeiten. Wir lernen, dass gewisse Handlungen im Projektalltag notwendig und zielführend sind. Dadurch passiert es, dass ein Teil der Handlungen nicht mehr hinterfragt wird. Sei es der standardisierte Meilensteinplan, der von Projekt zu Projekt mitgeführt wird, oder die To-do-Listen, die seit Jahren im Unternehmen eingesetzt werden. Wir wählen die Methodenbausteine für unsere Projekte nur selten bewusst aus. „SWBLM“ („So wie beim letzten Mal“) ist die Methode der Wahl. Im Unternehmen oder Projektteam existieren implizite Annahmen, wie Projekte umgesetzt und abgewickelt werden sollen. Wenn sich Methodenbausteine und Rituale etabliert haben, laufen Projekte quasi von selbst – und scheitern trotzdem von Zeit zu Zeit. Ein Grund für das Scheitern kann in SWBLM liegen.

Es wird übersehen, dass sich Projekte unterscheiden und aufgrund ihrer unterschiedlichen Anforderungen auch unterschiedliche Vorgehensweisen erfordern. Das heißt nicht, dass das Rad für jedes Projekt neu erfunden werden muss. Es bedeutet aber, dass die genutzten Methodenbausteine in jedem Projekt aus dem Unterbewusstsein in unseren Bewusstseinsraum geholt werden müssen, um sie zu hinterfragen und anzupassen. Immer dann, wenn die Antwort lautet „Das haben wir schon immer so gemacht“ oder „Das machen wir halt so“, ist es an der Zeit, das Vorgehen zu hinterfragen.

Mit Ritualen lernen

Doch wie schafft man es überhaupt, Routinen und Automatismen als solche zu identifizieren? Man braucht ein Ritual. Ein Ritual, in dem man sich bewusst vornimmt, die impliziten Annahmen und Routinen aus ihrem Versteck zu holen. Nur wer sich bewusst die Zeit dafür nimmt, kann sein Vorhaben auch zum Erfolg bringen.

Im täglichen Projektgeschäft ist die Zeit knapp. In den meisten Fällen gibt es strikte Deadlines, die es einzuhalten gilt. Doch in den wenigsten Fällen wird dieses Ziel erreicht – und wenn doch, dann oft außerhalb des festgelegten Budgets. Es beginnt ein Teufelskreis: der Kreis des ständigen Drucks, in dem scheinbar keine Zeit für Dinge bleibt, die außerhalb des vorliegenden Projektplans liegen. Lessons Learned und Retrospektiven scheinen dann Zeitfresser zu sein, die keinen fassbaren Mehrwert liefern. Diese Einschätzung verleitet dazu, sie aufzuschieben, sie stark zu verkürzen oder gar ganz ausfallen zu lassen. Dabei ist das Ritual, sich bewusst über seinen Prozess zu unterhalten, der einzige Hebel, der das Aufbrechen des Teufelskreises ermöglichen kann.

Das Ziel von Retrospektiven ist es, den Projektprozess kurzfristig zielgerichtet anpassen zu können. Wer es schafft, den Projektprozess auf die individuellen Anforderungen eines Projekts auszusteuern, erhöht die Wahrscheinlichkeit eines erfolgreichen Abschlusses. Mit den Routinen brechen, lautet die Devise. So ermöglicht man es allen Teammitgliedern, aus dem bisherigen Vorgehen zu lernen und Anpassungen für das laufende Projekt vorzunehmen. Gleichzeitig schafft man es, Gelerntes mitzunehmen und es auch auf kommende Projekte anzuwenden.

Gute Retrospektiven geben uns die Möglichkeit, die Art, wie wir unsere produktive Arbeitszeit verwenden, deutlich zu verbessern.

Erfolgreiche Retrospektiven moderieren

Nicht moderierte Meetings sind böse Meetings. Dieser Grundsatz gilt insbesondere für Retrospektiven. Eine Retrospektive ist keine gemütliche Teerunde ohne Agenda. Sie folgt einem klaren Konzept und hat ein klares Ziel: am Ende gemeinsam konkrete Veränderungen festlegen.

Retrospektiven müssen nicht den großen Wurf landen und alle Probleme vorangegangener Projekte beseitigen. Stattdessen hilft es, sich auf konkrete Maßnahmen oder Teamregeln zu einigen, die kurzfristig umsetzbar sind. Retrospektiven finden in kurzfristigen, regelmäßigen Zeitintervallen statt, zum Beispiel nach jedem Sprint. Das eröffnet die Option, neue Maßnahmen und Regeln einfach einmal auszuprobieren. Sollten sie nicht zu der gewünschten Verbesserung führen, lassen sich die Maßnahmen weiter optimieren oder zurückstellen. Wenn eine vereinbarte Maßnahme noch nicht zu dem gewünschten Erfolg geführt hat, war sie entweder noch nicht ausreichend, oder hinter der benannten Schwierigkeit steckt doch noch etwas anderes. Andere Maßnahmen können dann sinnvoller sein. Die Regelmäßigkeit der Retrospektiven bietet die Chance, den eigenen kontinuierlichen Verbesserungsprozess konkret voranzutreiben.

Eine Retrospektive folgt einem festen Raster, um sicherzustellen, dass am Ende der Retrospektive konkrete Maßnahmen oder Teamregeln vereinbart werden. In der Realität hat sich der Ablauf in den im Folgenden dargestellten sechs Phasen [1] bewährt:

1. Intro: Der Moderator beziehungsweise die Moderatorin stellt den Ablauf der Retrospektive vor, um allen Teilnehmern mitzuteilen, was sie erwartet. Es ist außerdem der Zeitpunkt der Beschlusskontrolle: Sind die Maßnahmen und Regeln, die in der letzten Retrospektive vereinbart wurden, umgesetzt und eingehalten worden? Das Team wird außerdem an die in der Retrospektive geltenden Regeln erinnert: die Vegas-Regel und die oberste Direktive.

Die Vegas-Regel besagt: „Alles, was wir in dieser Retrospektive besprechen, bleibt unter uns.“ Das Ziel ist es, dem Team auch bei sensiblen Themen einen sicheren Raum zur Diskussion zu bieten. Jedes Team entscheidet selbst, welche Inhalte der Retrospektive im Anschluss veröffentlicht werden sollen. Das Veröffentlichen und Aufhängen entsprechender Ergebnis-Flipcharts hat sich im Alltag bewährt. Dennoch kann es auch Ergebnisse geben, die nicht öffentlich in den Büros zur Ausstellung kommen sollen. Grundsätzlich gilt, dass alle Diskussionsinhalte von der Vegas-Regel betroffen sind, es sei denn, das Team entscheidet sich bewusst für die Kommunikation einzelner Diskussionsinhalte und Äußerungen nach außen.

Die oberste Direktive besagt: „Wir gehen davon aus, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.“ Sie sorgt für eine lösungsorientierte Diskussion – ohne Schuldzuweisungen.

Natürlich kann man in einer Retrospektive ausgiebige Diskussionen darüber führen, wer an dem Scheitern eines Projekts oder an einem Fehler schuld ist. Doch zum einen kommt man einer Lösung anhand der Schuldfrage nicht näher, und zum anderen lässt sich diese Frage auch nicht immer eindeutig beantworten. Hat zum Beispiel ein einzelnes Teammitglied durch fehlerhaften Code für den Zusammensturz eines ganzen Systems gesorgt, kann das Team sich darüber ärgern. Die einfache Schuldzuweisung beantwortet aber noch nicht die Frage, wieso es bisher keinen teaminternen Prozess zur Qualitätssicherung gibt, damit ein solcher Fehler vor dem Release auffällt. Wenn wir wissen, wer möglicherweise Schuld hat, wissen wir noch immer nicht, was wir beim nächsten Mal anders machen können, damit der gleiche Fehler nicht wiederholt wird. Deutlich wird also: natürlich kann man über Schuld diskutieren, für den aber, der konstruktiv an sich und seinem Prozess arbeiten will, bietet die Beantwortung der Schuldfrage keinen Mehrwert.

Die Vegas-Regel

Um allen Teilnehmerinnen und Teilnehmern ein sicheres Diskussionsumfeld zu schaffen, gilt in Retrospektiven die Vegas-Regel: „Alles, was wir hier besprechen, bleibt unter uns.“ Jedes Team entscheidet im Einzelfall, ob und in welcher Art Inhalte einer Retrospektive für andere wichtig sind und entsprechend veröffentlicht werden sollten.

2. Set the Stage: Das Intro „gehört“ dem Moderator. Die nachfolgende Phase stimmt die Teilnehmer nun auf die Retrospektive ein. „Set the Stage“ sammelt erste Eindrücke und verschafft einen Überblick über die aktuelle Stimmung. Hierbei können verschiedene Vorgehensweisen zum Einsatz kommen. Beispielsweise könnte zum Einstieg mit den Fragen: „Wie geht es dir heute?“ und „Wie schätzt du die aktuelle Stimmung im Projektteam ein?“ begonnen werden. Die Ergebnisse werden auf einem Flipchart visualisiert. Geübte Teams können ihre aktuelle Stimmung auch in selbstgemalten Bildern ausdrücken oder sogar kneten.

3. Gather Data: Die dritte Phase dient der Faktensammlung: Was lief im letzten Sprint oder dem festgelegten Zeitraum gut, und was lief nicht so gut? Konkrete Daten und Fakten sind genauso gefragt wie Bauchgefühle. Manchmal eröffnet das Bauchgefühl eines Einzelnen neue Perspektiven und fördert unausgesprochene Gefühle anderer zutage.

Die Äußerungen werden von dem Moderator gesammelt. Hierbei werden verschiedene Visualisierungsmöglichkeiten eingesetzt. Die Themen können zum Beispiel in Kleingruppen oder von jedem Einzelnen auf Moderationskarten geschrieben werden, um sie anschließend auf einem Flipchart oder einer freien Wand zu sammeln.

Manche Teams neigen dazu, bereits in dieser Phase Diskussionen über mögliche Ursachen zu führen oder sogar bereits nach Lösungsvorschlägen zu suchen. Der Moderator kann die genannten Themen mitschreiben, falls sie in den kommenden Phasen wieder benötigt werden sollten. Dennoch ist es wichtig, diese Diskussionen zu bremsen, um eine Vermischung der Themen zu vermeiden und keine vorschnellen Schlüsse zu ziehen.

4. Generate Insights: Das Team wählt eine begrenzte Anzahl an Themen aus der vorherigen Phase aus, um sie weiter zu bearbeiten. Die Abstimmung dieser Themen kann je nach Teamphase und Teamstruktur durch einfache Handzeichen, geheime Wahl oder andere Abstimmungsmöglichkeiten erfolgen. Solange es fair zugeht, sind der Fantasie keine Grenzen gesetzt. Es hat sich bewährt, nicht mehr als zwei Themen intensiv in einer Retrospektive zu bearbeiten. Dies zum einen aufgrund der festgelegten Dauer einer Retrospektive, zum anderen aber auch, um die Themen in einer entsprechenden Tiefe bearbeiten zu können.

Nun ist es an der Zeit, die Ursachen der genannten Themen herauszufinden. Manche Teams neigen dazu, die Ursachen nicht weiter zu ergründen und stattdessen direkt in die Diskussion von Lösungsvorschlägen einzusteigen. Aufgabe des Moderators ist es, die Teilnehmer durch Einsatz der richtigen Fragestellungen an die Hand zu nehmen und anzuleiten. Eine weitere Schwierigkeit kann auch in der Tiefe der Ursachen auftreten. Manchmal blockieren „Elefanten im Raum“ eine ehrliche Diskussion über Ursachen. So haben manche Teilnehmer eine Ursache im Kopf, trauen sich aber nicht, diese zu äußern. Sie befürchten möglicherweise, damit Anwesenden oder auch Vorgesetzten auf die Füße treten. Besonders große Elefanten können einige Retrospektiven überleben. Hier gilt es, Geduld zu haben. Als außenstehender Moderator glauben wir manchmal, mögliche Ursachen bereits erkannt zu haben. Doch um die Nachhaltigkeit der Handlungsoptionen in der folgenden Phase „Decide what to do“ sicherzustellen, ist es von großer Bedeutung, dass das Team aus sich selbst heraus festlegt, was für ihre Themen ursächlich ist.

5. Decide what to do: In dieser Phase entwickelt das Team Handlungsoptionen für die genannten Themen und Ursachen. Diese können beispielsweise einfach per Zuruf auf einem Flipchart gesammelt werden. Manchmal bietet sich auch die Arbeit in Kleingruppen an, um leisere Stimmen zu stärken und sicherzustellen, dass alle gleichermaßen die Chance erhalten, Handlungsoptionen einzubringen. Bei den Handlungsoptionen kann es sich um ein konkretes To-do handeln, das von einer Person oder auch mehreren einmalig umgesetzt wird. Es kann aber auch eine Teamregel sein, die in Zukunft für alle Teammitglieder gilt. Entscheidend ist, dass die vereinbarten Maßnahmen umsetzbar sind. Nur dann ist im Anschluss nachvollziehbar, welche Wirkung sie hatten. Die vereinbarten Maßnahmen oder Teamregeln werden entsprechend festgehalten. Allen Beteiligten muss klar sein, was konkret zu tun ist.

Das Ziel der Retrospektive ist es, das eigene Verhalten im Anschluss zu ändern. Deshalb hat es sich bewährt, nicht mehr als zwei bis drei konkrete Maßnahmen oder Teamregeln zu verabschieden. Das stellt sicher, dass es nicht zu einer Überforderung bei der Umsetzung kommt. Wenn die in der Retrospektive vereinbarten Maßnahmen dauerhaft nicht umgesetzt werden können, kann dies ein Frustrationsfaktor sein und die Qualität der Retrospektiven massiv beeinflussen.

6. Closing the Retrospective: In der sechsten und letzten Phase lassen die Teammitglieder die vorangegangene Retrospektive Revue passieren. Eine mögliche Frage des Moderators könnte zum Beispiel lauten: „Wie schätzt du die Umsetzbarkeit der vereinbarten Maßnahmen ein?“ oder „Wie ist dein Gefühl nach der Retrospektive?“ Der Moderator sollte die Phase nutzen, um bereits jetzt mögliche Themen für kommende Retrospektiven zu hören, und eventuell vorhandene Elefanten zu erkennen.

Unsere Retrospektiven haben keinen Mehrwert: „Wir jammern nur“

Hinterfragen Sie die Maßnahmen und Regeln, die Sie in der Retrospektive vereinbaren. Achten Sie darauf, dass sie möglichst konkret sind und von allen Beteiligten verstanden wurden. Dabei ist wichtig, dass die Veränderung von den Teammitgliedern abhängt – und nicht von Außenstehenden.

Auch zu viele Vereinbarungen in nur einer Retrospektive können für Frustration sorgen, weil sie nicht alle gleichzeitig umgesetzt werden können. Viele Maßnahmen sind nicht gleichzeitig zu schaffen.

„Good is enough“ ist nicht „done“

Der agile Grundsatz „Good is enough“, der auch bei der Vereinbarung von Retrospektivenergebnissen genutzt werden sollte, wird häufig missverstanden. Bei der agilen Entwicklung ist: „Geht‘s auch einfacher?“ eine immer wiederkehrende Frage, um gemeinsam herauszufinden, welche Anforderungen ein konkretes „Must Have“ und welche möglicherweise nur „nice to have“ sind. Viele Teams tun sich mit diesem Grundsatz und der Fragestellung schwer, weil sie „Good is enough“ mit einem Qualitätsanspruch verwechseln. Bei der Fragestellung „Geht‘s auch einfacher?“ geht es nicht darum, am Ende qualitativ minderwertigen Code abzuliefern oder gar mit Bugs live zu gehen. Es geht stattdessen darum, genau herauszufinden, was hinter den Anforderungen steckt, und stets zu hinterfragen, ob diese wirklich gewollt oder insbesondere in großen Projekten auch wirklich noch erforderlich sind.

Ist das Minimal Viable Product (MVP) erst einmal erschaffen und live, kann dies das Ende des Projekts bedeuten. Wenn das Budget aufgebraucht ist, die Umsetzung bereits den gewünschten Mehrwert liefert oder Features einfach nicht mehr gebraucht werden, wird die Entwicklung des Projekts nicht fortgesetzt. Für das Projektteam ist das nicht gleichbedeutend mit „Fertig“. Ein agiles Team ist erst dann fertig, wenn nach Projektabschluss eine entsprechende Retrospektive stattgefunden hat, die Learnings für kommende Projekte entwickelt. Wird die Abschlussretrospektive beziehungsweise Projektsupervision übergangen und mit dem Livegang auch für das Team ein „Fertig“ an das Projekt geschrieben, werden mit aller Wahrscheinlichkeit Möglichkeiten übersehen, den Prozess weiter zu verbessern. Während man in den Sprintretrospektiven immer einen kurzen Zeitraum überblickt und Veränderungen im Prozess oder Teamregeln möglicherweise nur für das laufende Projekt gelten, bietet die Abschlussretrospektive die Chance, das gesamte Projekt zu überblicken. Sie bietet die Möglichkeit, den Verlauf des Projekts in der Gesamtheit zu betrachten und sich die Frage zu stellen: „Wenn ich zu Beginn des Projekts den heutigen Wissenstand gehabt hätte – was hätte ich anders gemacht?“. Die Antwort auf diese Frage kann euch dabei helfen, Hindernisse zu identifizieren, die sich stets durch eure Projekte ziehen, im Einzelnen aber gar nicht so auffallen.

Die Projektsupervision zum Abschluss

Während die Sprintretrospektive eine festgelegte Dauer von 90 Minuten hat, darf die Projektsupervision zum Abschluss eines Projekts auch einen größeren Zeitrahmen einnehmen. Je nach Größe und Umfang eines Projekts kann sie bis zu vier Stunden dauern. Dabei werden die einzelnen Phasen der Retrospektive entsprechend verlängert.

Gute Moderation ‑ der Schlüssel zum Erfolg

Viele Projektteams schluffen bei der Durchführung von Retrospektiven. Alle jammern über die Umstände, was in einer Auflistung von Maßnahmen mündet, die Projektbeteiligte, aber nicht das agile Team selbst, umsetzen sollten. Dort passiert nichts. Entsprechend genervt sind alle in der nächsten Retrospektive.

Sucht umgekehrt das agile Team jeweils Lösungen, die im Team liegen („Was können wir leisten, damit sich die Ursache XYZ nicht mehr negativ zeigt?“), gibt es eine große Chance auf Verbesserung. Durch die Fokussierung auf wenige Maßnahmen als Ergebnisse fällt es den Beteiligten leicht, diese Beschlüsse auch umzusetzen. Ich muss als Teammitglied nicht viele, sondern nur zwei Maßnahmen im Kopf haben – und die hängen auch im Projektraum an der Wand.

Mit diesen einfachen Regeln werden Retrospektiven zum Erfolg. Nur eine Gefahr lauert noch: die immer gleiche Routine. Auch wenn die sechs Phasen der Retrospektive jedes Mal durchlaufen werden sollten, ist es Aufgabe des Moderators, die Frage immer wieder neu zu stellen. Eine veränderte Art der Fragestellung oder das Nutzen einer anderen Ausdrucksform wird neue Kenntnisse schaffen. Und die Teammitglieder freuen sich auf eine Retrospektive, in der sie erstens lernen und zweitens Spaß haben werden.

Links & Literatur

[1] Andresen, Judith: „Retrospektiven in agilen Projekten“, Hanser Fachbuchverlag

Aufmacherbild: Feedback von Shutterstock / Urheberrecht: Dooder

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -