April 2026 11 min Lesezeit Meinung
Es gibt eine spezifische Art organisationaler erlernter Hilflosigkeit, die sich rund um Retrospektiven entwickelt. Das Team weiß, wie man sie durchführt. Sie erzeugen echte Erkenntnisse. Die identifizierten Probleme sind real. Die vorgeschlagenen Verbesserungen sind vernünftig. Und bei der nächsten Retrospektive, drei Monate später, stehen dieselben Probleme auf dem Board. Nichts hat sich verändert. Das Team hat aufgehört zu erwarten, dass sich irgendetwas ändert. Die Retrospektive ist zu einer Zeremonie für die Äußerung von Frustration statt zu einem Verbesserungsmechanismus geworden.
Der Hook: Die hochkonforme, ergebnislose Retrospektive
Die Retrospektive hat eine der höchsten Compliance-Raten aller Scrum-Events. Die meisten Teams, die Scrum betreiben, führen Retrospektiven durch. Die Daten sehen ausgezeichnet aus. Die Ergebnisse nicht.
Eine Retrospektive, die konsequent Aktionspunkte produziert und konsequent keine Veränderung erzeugt, ist keine fehlgeschlagene Retrospektive. Sie ist eine erfolgreiche Retrospektive, die in einem Umfeld eingebettet ist, in dem die Outputs nicht umgesetzt werden können. Die Unterscheidung ist wichtig, weil die Diagnose zu unterschiedlichen Interventionen führt. Einem Team zu sagen, bessere Retrospektiven zu führen, wenn das Problem Organisationsstruktur oder Managementkompetenz ist, ist nicht hilfreich. Es ist beleidigend.
Die Realität: Warum Aktionspunkte sterben
Retrospektiven-Aktionspunkte scheitern aus vorhersehbaren Gründen. Die Gründe sind fast nie “das Team war nicht engagiert genug.”
Die Impediment-Decke
Die häufigste Ursache für Retrospektiven-Versagen ist die Impediment-Decke: die Lücke zwischen der Ebene, auf der Probleme existieren, und der Ebene, auf der das Team die Autorität hat, sie zu lösen.
Teams identifizieren reale Probleme in Retrospektiven. Sie können diese Probleme häufig nicht lösen, weil die Probleme struktureller, nicht verhaltensmäßiger Natur sind. Das Team kontrolliert nicht seine eigene Kapazität, seine technische Umgebung, seine Produktprioritäten oder seine Stakeholder-Beziehungen. Die Retrospektiven-Aktionspunkte, die Probleme innerhalb der Teamkontrolle ansprechen, werden umgesetzt. Die Aktionspunkte, die organisatorische Veränderungen erfordern, werden es nicht – nicht weil das Team versäumt, nachzuhaken, sondern weil das Team nicht die Autorität hat, sie einzufordern.
Im Laufe der Zeit lernen Teams die Decke kennen. Sie hören auf, Aktionspunkte zu generieren, die sie nicht umsetzen können. Die Retrospektive verengt sich auf das Gebiet, das das Team kontrolliert, was häufig unzureichend ist, um die bedeutendsten Hindernisse für effektive Arbeit zu adressieren.
Der Aktionspunkte-Friedhof
Die zweite Ursache ist einfacher: Aktionspunkte werden generiert und nicht verfolgt. Bei der nächsten Retrospektive überprüft niemand, was bei der vorherigen vereinbart wurde. Die Punkte des letzten Sprints sind nicht auf dem Board. Das Team weiß nicht, ob sie abgeschlossen wurden. Der Scrum Master weiß es nicht. Niemand hat die Eigentümerschaft.
Ohne Accountability verdampfen Aktionspunkte. Nicht aus schlechtem Glauben, sondern durch die Anhäufung anderer Prioritäten. Die Sprint-Arbeit verdrängt die Meta-Arbeit der Verbesserung des Team-Prozesses.
Der falsche Trost des Klebezettels
Es gibt einen psychologischen Mechanismus in Retrospektiven, der gegen Veränderung wirkt. Der Akt, ein Problem zu identifizieren, es auf einen Klebezettel zu schreiben und auf ein Board zu platzieren, erzeugt ein kleines, aber echtes Gefühl der Erleichterung. Das Problem wurde benannt. Es wurde anerkannt. Es existiert im organisatorischen Protokoll. Das ist nicht nichts – unbenannte Probleme sind schwerer zu lösen als benannte. Aber die Erleichterung kann als Ersatz für Handeln statt als Vorstufe dazu funktionieren.
Die Checksum: Was eine veränderungsproduzierende Retrospektive erfordert
Eine Retrospektive, die Veränderung erzeugt, erfordert drei Dinge, die die meisten Retrospektiven nicht haben: Autorität, Accountability und Follow-Through.
Autorität
Das Team muss die Autorität haben, auf das zu reagieren, was die Retrospektive produziert. Das bedeutet eines von zwei Dingen: Entweder produziert die Retrospektive Aktionspunkte, die im Einflussbereich des Teams liegen, oder sie produziert Eskalationspunkte mit einem klaren Eigentümer auf der Ebene, wo die Autorität liegt.
Accountability
Jeder Aktionspunkt muss genau einen Eigentümer und eine spezifische Verpflichtung haben. Nicht “wir sollten bei der Sprint-Planung besser werden”, sondern “Markus wird das Zwei-Punkte-Limit für Sprint-Planungsthemen vor der nächsten Retrospektive vorschlagen und umsetzen.” Der Unterschied ist nicht kosmetisch. Kollektive Eigentümerschaft ist niemandes Eigentümerschaft.
“Eine Retrospektive ohne Follow-up-Check ist ein Beschwerdebriefkasten ohne Leerungsservice. Die Beschwerden sind real. Niemand liest sie.” Markus – agile-checksum.com
Follow-Through auf Organisationsebene
Die schwierigste und wichtigste Bedingung. Retrospektiven können nur die Veränderung erzeugen, die die Organisation bereit ist zu machen. Wenn die Organisation – durch konsequente Nicht-Reaktion auf eskalierte Impediments – signalisiert, dass Team-Verbesserung keine echte Priorität ist, werden Teams aufhören, in den Prozess der Identifizierung von Verbesserungsmöglichkeiten zu investieren.
Fallstudien aus der Praxis
Die Impediment-Wand
Ein Produktteam in einem Finanzdienstleistungsunternehmen hatte zwei Jahre lang zweiwöchentliche Retrospektiven durchgeführt. Sie hatten ein sorgfältiges Protokoll der Retrospektiven-Outputs. Als ich das Aktionspunkte-Protokoll mit dem Scrum Master überprüfte, fand ich, dass Punkte innerhalb der Teamkontrolle eine Abschlussrate von 85% hatten. Punkte, die Management-Beteiligung erforderten, hatten eine Abschlussrate von 3%.
Das Team hatte das implizit gelernt. Bei einer Retrospektive, die ich begleitete, bemerkte ich, dass das Team fast keine Aktionspunkte generierte, die Management-Handlungen erforderten. Die bedeutenden strukturellen Impediments – Kapazitätsbeschränkungen, unklare Produktausrichtung, technische Schulden, die Investitionsentscheidungen erforderten – wurden nicht angesprochen.
Die Wiederherstellung
Ein anderes Team hatte das gegenteilige Problem: Es identifizierte konsequent wichtige strukturelle Impediments. Der Scrum Master eskalierte sie konsequent und erhielt Anerkennung ohne Handlung. Nach vier Sprints änderte die Scrum Masterin die Strategie: Sie begann, Impediments in einem Format zu dokumentieren, das ihre Geschäftskosten explizit machte, präsentierte sie bei Sprint Reviews statt nur informell zu eskalieren und bat um ein monatliches Impediment-Review-Meeting mit der Abteilungsleiterin.
Die Abteilungsleiterin nahm an zwei dieser Meetings teil und erkannte an, dass drei der dauerhaften Impediments legitime organisatorische Versäumnisse waren, die sie die Autorität hatte zu adressieren. Zwei wurden innerhalb von sechs Wochen gelöst.
Das Takeaway: Das Problem ist nie “bessere Retrospektiven”
Wenn Retrospektiven eines Teams konsequent Erkenntnisse und keine Veränderungen produzieren, ist die Lösung fast nie, bessere Retrospektiven durchzuführen. Es geht darum, die Bedingungen zu ändern, die verhindern, dass Retrospektiven-Outputs umgesetzt werden.
Führe die Checksum für deine Retrospektiven durch:
- Überprüfe die letzten sechs Retrospektiven-Aktionspunkte. Welcher Prozentsatz wurde abgeschlossen? Welcher Prozentsatz ist seit drei oder mehr Sprints noch offen?
- Was ist das bedeutendste Problem, dem dein Team gerade gegenübersteht? Erschien es in einer Retrospektive in den letzten sechs Monaten? Wenn ja, was geschah mit den Aktionspunkten, die es adressierten?
- Wann hat das Management zuletzt auf einen eskalierten Impediment aus einer Team-Retrospektive reagiert?
Die Antworten zeigen dir, wo das Problem tatsächlich liegt.
Im Artikel verwendete Glossarbegriffe
- Retrospektive – Eine Scrum-Zeremonie zur Überprüfung des Sprints und Identifizierung von Verbesserungen.
- Scrum Master – Die Scrum-Verantwortlichkeit für die Etablierung von Scrum und den Dienst am Team und der Organisation.
- Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im gesamten Unternehmen einzuführen.
- Psychologische Sicherheit – Die gemeinsame Überzeugung, dass es sicher ist, interpersonelle Risiken innerhalb eines Teams einzugehen.
- Sprint – Ein Scrum-Event mit festem Zeitraum, in dem ein nutzbarer Produktzuwachs erstellt wird.
Kein Buzzword-Bingo. Nur echtes Agile.
Direkt in dein Postfach. Kein Spam.
Verwandte Artikel
"Agile Waterfall: Die Sprache von Agile ohne die Autorität, agil zu sein"
Viele Organisationen haben das Agile-Vokabular vollständig adoptiert und die Agile-Entscheidungskompetenz überhaupt nicht. Das Ergebnis ist kein Hybrid. Es ist Waterfall mit besser benannten Phasen und höherer Meeting-Frequenz.
Artikel lesen →"Scrum Theatre: Warum das Daily zum Statusmeeting wird"
Das Daily Scrum ist die meistbeobachtete Zeremonie im Agile. Und eine der am konsequentesten missbrauchten. Warum es zum Statusbericht degradiert – und was die Struktur eigentlich erfordert.
Artikel lesen →"Wie gutes Backlog Refinement wirklich aussieht"
Keine Zeremonie. Keine Pflegesession. Eine Disziplin, die bestimmt, ob das Sprint Planning neunzig Minuten oder vier Stunden dauert. Die meisten Teams machen Refinement falsch – nicht weil ihnen die Technik fehlt, sondern weil sie den Zweck missverstehen.
Artikel lesen →