Warum 2/3 der Retrospektiven-Aktionen scheitern (und wie man das behebt)

Die Friedhofsschicht

Stellen Sie sich vor: Es ist Zeit für die Sprint-Retrospektive. Das Team versammelt sich, entweder persönlich oder verteilt über Videokacheln. Haftnotizen fliegen. Jemand spricht den Deployment-Engpass an, der die Velocity killt. Eine andere Person erwähnt die instabile Testsuite. Ein Dritter schlägt Pair-Programming-Rotationen vor, um Wissen zu verteilen.

Am Ende der Sitzung haben Sie eine ordentliche Liste von Aktionspunkten:

• „CI-Parallelisierung untersuchen" — zugewiesen an Sarah
• „Authentifizierungsablauf dokumentieren" — zugewiesen an Mike
• „Rotationsplan für Code-Reviews einrichten" — zugewiesen an den Team-Lead

Alle nicken. Die Retro endet. Die Leute fühlen sich gut. Fortschritt wurde gemacht.

Zwei Wochen später, gleicher Raum, gleiche Gesichter. Neue Retro. Und niemand erwähnt, was aus diesen Aktionspunkten geworden ist. Weil nichts aus diesen Aktionspunkten geworden ist. Sie sind leise gestorben, irgendwo zwischen dem Jira-Backlog und den guten Absichten aller.

Kommt Ihnen das bekannt vor?

Die unbequeme Mathematik

Hier ist eine Statistik, die jeden Scrum Master verfolgen sollte: Eine PMI-Community-Umfrage ergab, dass fast zwei Drittel der Teams weniger als 25 % der Verbesserungsideen aus ihrer letzten Retrospektive umgesetzt haben. Kein einziger Befragter gab an, mehr als 75 % umgesetzt zu haben.

Lesen Sie das noch einmal. Zwei Drittel der Teams können nicht einmal ein Viertel dessen umsetzen, wozu sie sich verpflichtet haben.

Das ist keine geringfügige Prozessineffizienz. Es ist eine massive Glaubwürdigkeitskrise. Jeder aufgegebene Aktionspunkt ist ein kleines gebrochenes Versprechen. Stapeln Sie genug davon auf und Sie bekommen „Retrospektiven-Müdigkeit" — diese zynische, abgeschaltete Stimmung, bei der Leute aufhören, Probleme anzusprechen, weil sie gelernt haben, dass sich sowieso nie etwas ändert.

Die Zeremonie geht weiter. Die Verbesserung nicht.

Warum sterben Retrospektiven-Aktionspunkte?

Retrospektiven-Aktionspunkte sterben, weil das System auf Scheitern ausgelegt ist, nicht weil Menschen faul sind oder sich nicht kümmern. Nichts zwingt das Team, sich mit alten Verpflichtungen auseinanderzusetzen, „in Bearbeitung"-Zustände verbergen Aufgabe, vergessene Punkte verschwinden ohne Entscheidung, und das Eingeständnis eines gebrochenen Versprechens ist unangenehm genug, dass niemand es anspricht. Vier Probleme, ein Friedhof.

Problem 1: Keine zwingende Funktion

Traditionelle Aktionspunkte leben in Jira oder einem gemeinsamen Dokument oder in jemandes Notizen. Sie konkurrieren mit tatsächlicher Sprint-Arbeit um Aufmerksamkeit. Und raten Sie mal, was gewinnt, wenn der Product Owner nach diesem Feature-Termin fragt? Nicht „CI-Parallelisierung untersuchen".

Es gibt keinen Moment, in dem das Team gezwungen ist, sich mit dem Schicksal früherer Verpflichtungen auseinanderzusetzen. Die Retro konzentriert sich darauf, was in diesem Sprint passiert ist, nicht darauf, was wir im letzten Sprint versprochen haben.

Problem 2: Fortschrittstheater

Viele Tools lassen Sie Aktionspunkte als „in Bearbeitung" oder „50 % abgeschlossen" oder welchen Prozentsatz auch immer markieren, der Sie produktiv fühlen lässt. Das ist eine Falle. Ein Aktionspunkt, der seit drei Sprints „in Bearbeitung" ist, ist nicht in Bearbeitung. Er ist aufgegeben mit zusätzlichen Schritten.

Fortschrittstheater lässt Teams die unbequeme Binärfrage vermeiden: Haben wir das getan oder nicht?

Problem 3: Stilles Vergessen

Das häufigste Schicksal eines Aktionspunkts ist nicht Abschluss oder explizite Schließung. Es wird einfach vergessen. Er rutscht vom unteren Ende der Liste, ersetzt durch neuere, glänzendere Verpflichtungen. Niemand sagt „wir werden das nicht tun". Es hört einfach auf zu existieren.

Das ist Tod durch Vernachlässigung, und es ist weitaus häufiger als explizites Scheitern.

Problem 4: Schamvermeidung

Seien wir ehrlich: Zuzugeben, dass man etwas nicht getan hat, wozu man sich verpflichtet hat, ist unangenehm. Die menschliche Natur ist es, dieses Gespräch zu vermeiden. Also bringen wir die alten Aktionspunkte nicht zur Sprache. Wir konzentrieren uns auf die neuen Probleme. Der Zyklus geht weiter.

Die nervig effektive Lösung

Als wir das Aktionspunkt-System in Simyl Flow gebaut haben, haben wir es absichtlich unbequem gestaltet. Nicht grausam — nur ehrlich. So sieht das aus:

Die Verantwortlichkeitsprüfung

Die Verantwortlichkeitsprüfung ist eine zwingende Funktion: Sie können keine neue Retrospektive starten, ohne sich zuerst mit Ihren alten Verpflichtungen auseinanderzusetzen.

Wenn Sie eine neue Retro öffnen, bevor Sie das Board sehen, bevor jemand eine einzige Karte hinzufügt, erscheint ein Dialog. Er zeigt jeden offenen Aktionspunkt aus früheren Retrospektiven. Für jeden haben Sie genau drei Optionen:

1. Als erledigt markieren — Sie haben es getan. Feiern Sie. Weiter geht's.
2. Übertragen — Sie haben es nicht getan, wollen es aber noch. Es wird mit einem Zähler in diese Retro übertragen.
3. Nicht tun — Sie entscheiden bewusst, dies nicht zu tun. Sie müssen begründen, warum.

Keine vierte Option. Kein „in Bearbeitung". Kein „lass uns später darüber reden". Sie müssen entscheiden.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

Das war's. Drei Zustände. Binäre Ergebnisse mit einer Notausstiegsluke, die eine Erklärung erfordert.

Der Zähler der Schande

Hier wird es interessant. Wenn Sie einen Aktionspunkt übertragen, erhöhen wir einen Zähler.

Dieser Zähler ist sichtbar. Wenn ein Aktionspunkt „2x übertragen" in diesem bernsteinfarbenen Badge zeigt, kann es jeder sehen. Es sind keine versteckten Metadaten. Es ist ein öffentliches Signal, das sagt „wir haben diese Verpflichtung jetzt zweimal verschoben".

Ist das ein bisschen unangenehm? Ja. Das ist der Punkt. Das Unbehagen erzeugt Druck, entweder die Sache zu tun oder bewusst zu entscheiden, sie nicht zu tun. Beides sind legitime Ergebnisse. Stille Vernachlässigung ist es nicht.

Wir haben Teams gesehen, bei denen ein Aktionspunkt, der „3x übertragen" erreicht, automatisch eine Diskussion auslöst: „Okay, das wird immer wieder verschoben. Wollen wir das wirklich tun, oder sollten wir es einfach schließen?"

Dieses Gespräch ist Fortschritt. Dieses Gespräch findet ohne den sichtbaren Zähler fast nie statt.

Nicht tun ist ein Feature, kein Scheitern

Die meisten Tools behandeln das Schließen eines Aktionspunkts als dessen Abschluss. Wir trennen die beiden explizit.

Wenn Sie etwas als „nicht tun" schließen, müssen Sie einen Grund angeben. „Nicht mehr relevant" ist in Ordnung. „Prioritäten haben sich geändert" ist in Ordnung. „Wir haben erkannt, dass das eine dumme Idee war" ist in Ordnung. Aber Sie müssen es artikulieren.

Das ist keine bürokratische Abhak-Übung. Es zwingt das Team, eine explizite Entscheidung zu treffen. Bewusste Schließung ist unendlich besser als unbewusste Aufgabe. Eine Entscheidung, etwas nicht zu tun, ist immer noch eine Entscheidung. Eine Entscheidung schafft Lernen („wir haben versucht, uns zu X zu verpflichten, konnten aber nicht durchziehen wegen Y").

Vergessen schafft nichts.

Erledigt oder nicht erledigt

Wir haben bewusst keine prozentuale Fertigstellung oder Fortschrittszustände implementiert. Ein Aktionspunkt ist entweder offen oder erledigt. Das ist das Datenmodell:

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

Das war eine bewusste Design-Entscheidung, die manche Menschen unbequem macht. „Was ist, wenn ich zur Hälfte fertig bin?" Dann ist es offen. „Was ist, wenn ich mit der Recherche begonnen habe?" Offen. „Was ist, wenn ich einen Entwurf geschrieben habe?" Immer noch offen.

Die einzige Frage, die zählt: Haben Sie die Sache getan, zu der Sie sich verpflichtet haben?

Diese binäre Rahmung eliminiert Fortschrittstheater vollständig. Es gibt keine bequeme Mitte, in der Sie Anerkennung für Absichten beanspruchen können. Sie haben es entweder ausgeliefert oder nicht.

Deine Aktionen folgen dir

Wir haben ein persönliches Dashboard entwickelt — die Seite „Meine Aktionen" — das alle deine Aktionspunkte aus jedem Team, in dem du bist, zusammenfasst.

Das schafft eine persönliche Verantwortlichkeitsoberfläche. Deine Verpflichtungen sind nicht über verschiedene Retro-Boards und Team-Jira-Projekte verstreut. Sie sind alle an einem Ort und starren dich an.

Der psychologische Effekt ist subtil, aber real. Wenn deine offenen Aktionen bei jedem Login in deinem persönlichen Dashboard sichtbar sind, sind sie schwerer zu vergessen. Sie sind nicht in einem Team-Backlog vergraben. Sie sind direkt vor deiner Nase.

Vertrauen wird gemessen, nicht angenommen

Hier wird das System ernst. Die Abschlussrate von Aktionspunkten fließt direkt in unsere Teamdynamik-Metriken ein — konkret in den Vertrauens-Score.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

Warum bildet die Aktionsabschlussrate Vertrauen ab? Weil Durchhaltevermögen Vertrauen ist. Wenn ein Team seine Verpflichtungen konsequent einhält — selbst die internen, die nur das Team betreffen — baut das Zuversicht auf. Umgekehrt untergräbt ein Muster gebrochener Versprechen (selbst kleine wie Retro-Aktionspunkte) das Vertrauen des Teams in sich selbst.

Ein Team, das seinen eigenen Verpflichtungen nicht vertrauen kann, wird mit allem anderen kämpfen.

Die Metrik ist nicht strafend. Ein Team, das keine Aktionspunkte erstellt, erhält einen neutralen Score. Ein Team, das einige erstellt und die meisten abschließt, wird belohnt. Ein Team, das viele erstellt und wenige abschließt, wird markiert — nicht als „schlecht", sondern als Signal, dass etwas nicht stimmt. Vielleicht sind die Aktionen zu ehrgeizig. Vielleicht gibt es keine Zeit für Verbesserungsarbeit. Vielleicht ist das Problem systemisch.

Die Metrik schafft das Gespräch. Das Team entscheidet, was es dagegen tut.

Die Philosophie

Alles, was wir hier gebaut haben, entspringt einer einfachen Überzeugung: Explizite Entscheidungen schlagen implizite Vernachlässigung.

• „Wir werden das nicht tun" zu sagen ist besser als still zu vergessen.
• „Wir übertragen das" zu sagen ist besser als so zu tun, als hätten wir uns nicht verpflichtet.
• „Wir haben es getan" zu sagen (wenn du es tatsächlich getan hast) ist besser als „wir haben Fortschritte gemacht".

Wir versuchen nicht, Teams zu beschämen. Wir versuchen, ein System zu schaffen, in dem Ehrlichkeit einfacher ist als Vermeidung. Wo der Weg des geringsten Widerstands zu Klarheit statt zu Mehrdeutigkeit führt.

Traditionelle Tools machen es leicht zu vergessen und unangenehm zu konfrontieren. Wir haben es umgedreht. Unser System macht Vergessen unmöglich (die Verantwortlichkeitsprüfung) und Konfrontation handhabbar (drei klare Optionen, jede legitim).

Das Ergebnis sind keine 100%-Abschlussraten. Das wäre unrealistisch und würde wahrscheinlich darauf hindeuten, dass Teams sich nur auf sichere, einfache Aktionen festlegen. Das Ergebnis sind Teams, die das Schicksal jeder Verpflichtung kennen, die sie eingegangen sind. Das ist etwas ganz anderes und weitaus wertvoller.

Was wir gesehen haben

Teams, die das Verantwortlichkeitsprüfungs-Muster nutzen, berichten von einigen konsistenten Veränderungen:

Weniger, bessere Aktionen

Wenn du weißt, dass du mit deinen Verpflichtungen konfrontiert wirst, gehst du weniger ein. Aber die, die du eingehst, sind eher Dinge, die du tatsächlich tun wirst. Das Muster „lass uns das auf die Aktionspunkte-Liste setzen, damit sich die Leute gehört fühlen" stirbt schnell.

Schnellere „Werden wir nicht tun"-Entscheidungen

Teams werden besser darin zu erkennen, wann etwas nicht passieren wird. Anstatt es drei Sprints lang hängen zu lassen, schließen sie es in einem oder zwei. „Wir haben gesagt, wir würden das tun, haben es nicht getan, werden es nicht tun — lass es uns schließen und aufhören so zu tun."

Mehr Vertrauensgespräche

Wenn der Teamdynamik-Score die Aktionspunkt-Nachverfolgung widerspiegelt, wird er zu Daten für die Retrospektive selbst. „Unser Vertrauens-Score ist diesen Sprint gefallen. Ein Faktor: Wir haben nur 2 von 7 Aktionspunkten abgeschlossen. Was ist los?"

Dieses Meta-Gespräch über die Fähigkeit des Teams, Verpflichtungen einzuhalten, ist oft wertvoller als jeder einzelne Aktionspunkt.

Versuch, unbequem zu sein

Wenn deine Retro-Aktionspunkte weiter sterben, ist das Problem nicht die Motivation. Es ist das Systemdesign. Du brauchst:

1. Eine Zwangsfunktion — Etwas, das die Konfrontation mit alten Verpflichtungen obligatorisch macht, nicht optional.
2. Binäre Ergebnisse — Erledigt oder nicht erledigt. Kein Verstecken hinter Prozentsätzen.
3. Sichtbares Übertragungstracking — Ein Zähler, der wiederholtes Verschieben sichtbar macht.
4. Legitimer Abschluss — Eine „Werden wir nicht tun"-Option, die einen Grund erfordert, aber als gültig behandelt wird.
5. Persönliche Verantwortlichkeitsoberflächen — Deine Verpflichtungen folgen dir, nicht nur dem Team.
6. Metriken, die die Realität widerspiegeln — Durchhaltevermögen beeinflusst Team-Gesundheits-Scores.

Wir haben all das in Simyl Flow eingebaut, weil wir es leid waren zuzusehen, wie gute Verbesserungsideen im Raum zwischen Meetings sterben. Die Verantwortlichkeitsprüfung ist ein bisschen nervig. Der Übertragungszähler ist ein bisschen unbequem. Der binäre Status ist ein bisschen starr.

Das ist der Punkt. Komfort ist, wie Aktionspunkte sterben.

Quellen

1. Bondale, K. (2022). „Why hold retrospectives if ideas don't get implemented?" — PMI „Easy in theory, difficult in practice" Blog
2. Wolpers, S. (2024). „Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change"