Wie man eine Projekt-Retrospektive durchführt

Das Mindset des Facilitators: Der Systemdiagnostiker

In einer agilen Retrospektive muss die Moderation die Rolle des „Systemdiagnostikers“ einnehmen. Dein übergeordnetes Ziel besteht darin, die oft emotionale und anspruchsvolle Dynamik des Teams zu steuern und das Gespräch gezielt von persönlichen Schuldzuweisungen weg und hin zu systemischen Prozessursachen zu lenken. Du musst sicherstellen, dass unvermeidliche Frustrationen im Team konstruktiv in produktive, strukturelle Verbesserungen kanalisiert werden, anstatt in persönliche Vorwürfe oder endloses Klagen abzugleiten.

Wann das Framework wirklich funktioniert (und wann es scheitert)

Eine Retrospektive sollte am Ende eines Sprints, nach einem wichtigen Projektmeilenstein oder unmittelbar nach einem schwerwiegenden Zwischenfall stattfinden – in der Branche oft als fehlerfreie Post-Mortem-Analyse bezeichnet. Sie ist unverzichtbar, wann immer ein Team das Tempo der Umsetzung kurz drosseln muss, um zu hinterfragen, wie gearbeitet wird. Wenn sich das Team wie im Hamsterrad fühlt – hart arbeitet, ohne dass sich Durchsatz, Qualität oder Teamstimmung verbessern –, ist es Zeit für eine Retrospektive.

Retrospektiven scheitern jedoch krachend, wenn sie als reine Pflichtübung verstanden werden, bei der brav „Start, Stop, Continue“-Punkte gesammelt werden, im nächsten Sprint jedoch nie Zeit für die Umsetzung der Maßnahmen eingeplant wird.

Den Raum vorbereiten und den Rahmen setzen

An der Sitzung sollte ausschließlich das Kernteam teilnehmen: jede Person, die aktiv am Sprint oder Projekt mitgewirkt hat. Externe Stakeholder, Projektsponsoren oder Führungskräfte, die nicht direkt am Tagesgeschäft beteiligt waren, musst du konsequent ausschließen. Ihre Anwesenheit zerstört – wie gut auch immer gemeint – sofort die für offenes Feedback nötige psychologische Sicherheit. Idealerweise übernimmt eine neutrale Person die Moderation, etwa ein agiler Coach oder Scrum Master, der sich voll auf den Prozess und die Stimmung im Raum konzentriert, statt die eigene Arbeit verteidigen zu müssen.

Eine Retrospektive steht und fällt mit psychologischer Sicherheit: Hat das Team das Gefühl, dass ehrliches Feedback bei der nächsten Leistungsbeurteilung gegen sie verwendet wird, ist das Treffen schlechter als gar keines. Bereite die Sitzung vor, indem du objektive Daten zusammenträgst (wie Burndown-Charts, Bug-Statistiken oder unentdeckte Fehler), damit das Team die Fakten vorab einsehen kann. Eröffne die Session stets mit der agilen Grundannahme (Prime Directive): „Unabhängig davon, was wir herausfinden, verstehen und glauben wir aufrichtig daran, dass jeder nach bestem Wissen und Gewissen gehandelt hat – gemessen am damaligen Kenntnisstand, den Fähigkeiten, den verfügbaren Ressourcen und der damaligen Situation.“ Das schafft die notwendige Vertrauensbasis.

Die Dynamik steuern: Die Umsetzungsphase

Eine Standard-Retrospektive folgt einem klaren 60- bis 90-minütigen Ablauf. Nach dem Einstieg mit der Grundannahme und einem kurzen Stimmungsbild (z. B. „Wie fühlte sich dieser Sprint in einem Wort an?“) folgt die Datensammlung. Nutze ein strukturiertes Format wie „Start, Stop, Continue“ oder „Mad, Sad, Glad“. Gib dem Team ausreichend Zeit, um Gedanken schweigend auf Notizen festzuhalten. Diese Phase des stillen Schreibens ist unverzichtbar: Sie verhindert Gruppendenken und sorgt dafür, dass die lautesten Stimmen die Diskussion nicht vorab prägen.

Sobald die Punkte sichtbar sind, clustert ihr ähnliche Notizen, um die vorherrschenden Themen des Sprints herauszuarbeiten. Nutze die „5-Why“-Methode, um hinter vordergründigen Beschwerden die wahren systemischen Ursachen aufzudecken. Wenn eine Frist gerissen wurde: Warum? Weil das Testing zu lange dauerte. Warum? Weil die Testumgebungen instabil waren. Bohre nach, bis der Prozessfehler offenliegt. Vor dem Ende musst du das Team dazu verpflichten, eine wirkungsvolle Prozessänderung für den nächsten Sprint festzulegen und mit einer klaren Zuständigkeit zu versehen.

Den Durchbruch herbeiführen

Um fundierte Erkenntnisse zu fördern, musst du dem Team gezielte, unbequeme Fragen stellen. Frage: „Wenn wir im nächsten Sprint genau denselben Fehler wiederholen würden – welcher konkrete Prozess wäre schuld daran?“ Lass die Gruppe definieren, was in diesem Sprint passiert ist, das absolut nie wieder vorkommen darf. Decke verborgene Engpässe auf, indem du fragst, wo die meiste Zeit mit Warten auf andere verloren ging. Oder fordere das Team heraus: „Welche Regel würdet ihr als Erstes ändern, wenn ihr das Team leiten würdet?“

Sei wachsam gegenüber typischen Fallstricken. Der häufigste ist das Abgleiten in reines Dampfablassen. Meckern erleichtert zwar kurzfristig, ändert aber nichts; lenke das Gespräch sofort um, indem du fragst, welche konkrete Prozessänderung ab morgen greifen kann. Vermeide Maßnahmenüberladung; eine Liste von zehn Vorhaben garantiert, dass keines umgesetzt wird. Unterbinde Schuldzuweisungen unverzüglich, indem du den Fokus auf den Prozess richtest, der den Fehler zugelassen hat – nicht auf die Person. Und achte auf die Routinefalle, bei der nur Dienst nach Vorschrift gemacht wird, was zu Retrospektiven-Müdigkeit führt, sodass niemand mehr offen spricht.

Den Kreis schließen

Halte das verbindliche Vorhaben dort fest, wo das Team es zu Beginn der nächsten Retrospektive direkt sieht, und eröffne das Folgemeeting mit der Überprüfung, ob die Änderung gegriffen hat. Die kostenlose Retrospektiven-Vorlage enthält einen Bereich für Beschlüsse, Verantwortliche und Fristen.

Die oberste Regel einer Retrospektive lautet: Verlasse den Raum niemals ohne ein konkretes Commitment. Das Ziel ist nicht, alles aufzuschreiben, was das Team theoretisch besser machen könnte – sondern den engsten Flaschenhals im Arbeitsablauf zu identifizieren und ein verbindliches Experiment zu seiner Behebung zu beschließen. Echte Agilität entsteht durch die disziplinierte Umsetzung dieser kleinen, stetigen Verbesserungen Woche für Woche.

Bereit für die Praxis? Probier es mit deinem Team und der kostenlosen Retrospektive-Vorlage aus.