Der Bericht existiert. Der Raum existiert nicht.

Vor kurzem hat ein KI-Agent sechs Einträge auf unserem eigenen Retro-Board hinterlegt.

Der erste lautete: „Überprüfen Sie erst, bevor Sie handeln – Fehler bei der Agentenausführung machen 38 % der Reibungsverluste aus (das Doppelte der nächsthäufigsten Ursache); die wiederkehrenden Kosten entstehen dadurch, dass eine Ursache behauptet, ein Push durchgeführt oder eine Neuausrichtung vorgenommen wird, bevor der Live-Code, die Daten oder der Zweigstatus überprüft wurden.“ Dahinter verbargen sich die Musterbelege: Fehler im Zusammenhang mit dem Git-Zweigstatus bei der Arbeit mit mehreren Agenten über acht Sitzungen und zwei Repositories hinweg; unvollständige Pre-Push-Prüfungen, die die CI in vier Sitzungen zum Absturz brachten, davon zweimal in einem Repository am selben Tag; eine Lücke bei den Test-Mocks, auf die in einer Sitzung am Vortag hingewiesen worden war, mit dem Vermerk, dass die Dokumentation zur Behebung nie verfasst wurde.

Zwei Aspekte dieser Übersicht sind besonders bemerkenswert. Erstens: Keine einzelne Arbeitssitzung hätte irgendetwas davon als ihr größtes Problem eingestuft – in jedem Einzelfall handelte es sich um ein Achselzucken, ein paar verlorene Minuten, ein Ärgernis, das jemand umgangen hat. Die Rangfolge ergibt sich erst in der Gesamtheit, über alle Sitzungen und Personen hinweg. Zweitens, und das ist noch unangenehmer: Die schwerwiegendsten Punkte betrafen überhaupt nicht den Agenten oder den Code. Sie betrafen uns – Korrekturen, denen wir zugestimmt, die wir aber nicht umgesetzt hatten, sowie die immer wiederkehrende Blockade, bei der „zwischen den Sitzungen keine dauerhafte Korrektur bereitgestellt wurde“.

Ein automatisierter Bericht kann Ihnen all dies aufzeigen. Was er jedoch nicht leisten kann, ist, die Verantwortlichen für den Prozess, die Dokumentation, das Budget für die Werkzeuge und die Prioritäten an einen Tisch zu bringen, um zu entscheiden, wie damit umgegangen werden soll. Der Bericht ist vorhanden. Der Raum jedoch nicht. In diesem Beitrag geht es um diesen Raum.

Alle haben die Schleife gebaut

Bis Mitte 2026 ist es gängige Praxis, „Fehler bei der KI-gestützten Arbeit zu erfassen und als Feedback weiterzugeben“. Dieses Konzept existiert unter mindestens sechs Bezeichnungen, die alle zutreffend sind. Rahul Gargs Feedback Flywheel nutzt Reibungspunkte aus Arbeitssitzungen, um Einführungsdokumente und Leitlinien zu erstellen. Das Compound Engineering von Every sorgt dafür, dass jede Arbeitseinheit der nächsten als Vorbild dient. Thoughtworks stattet Agenten mit Sensoren aus; Addy Osmani bezeichnet diese Disziplin als Loop Engineering. Die Plattformanbieter schließen den Kreislauf auf Flottenebene: OpenAI’s „Dreaming“, Anthropics Kontextkuratierung sowie Factory Signals mit der automatischen Erstellung von Tickets. GitHubs Open-Source-Projekt gh-aw, ein Framework für agentenbasierte Workflows, das in Markdown in natürlicher Sprache verfasst ist, kommt unserem Thema am nächsten: Seine Workflows zur Sitzungsauswertung generieren bereits automatisierte Berichte zur Sitzungsanalyse. Ein öffentliches Beispiel, die automatisierte Analyse von 50 Sitzungen an einem einzigen Tag, kennzeichnet eine Überspringrate von 24 % und eine Erfolgsquote der Ausführenden von 33 % als „Fehler-Signale“.

Falls Sie eine dieser Methoden verwenden: Behalten Sie sie bei. In diesem Beitrag wird nicht vorgeschlagen, eine davon zu ersetzen. Sortieren Sie jedoch die Schleifen nach der Ebene, auf der sie ausgeführt werden, und erkennen Sie das Muster:

Ein Leitfaden für Praktiker. Eine Sitzungskonfiguration. Ein Plattformspeicher. Ein Observability-Stack. Eine Anbieterflotte.

Nahezu jeder Zyklus in diesem Bereich ist ein Solozyklus: eine Person und ihr Betreuer oder ein Anbieter und dessen Flotte. Gargs „Flywheel“ ist das einzige Konzept, das auf gemeinsame Team-Artefakte abzielt, und seine Kadenzliste enthält einen Punkt, den fast niemand in die Praxis umgesetzt hat: „Bei der Retrospektive: Ein Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ Er nennt den Ort und fährt fort. Das „Dogfooding“ von GitHub hingegen liefert genau den Reibungsbericht, den eine Teamzeremonie als Input wünschen würde, und positioniert ihn als technische Beobachtbarkeit, Punkt.

Eine Art Ausnahme findet sich bei Scrum.org, dessen Reihe zu Hybridteams den Beitrag Wie man die Sprint-Retrospektive durchführt, wenn die Hälfte Ihres Teams aus KI-Agenten besteht enthält. Der Beitrag ist lesenswert, da er die Frage nach dem Rahmen ernst nimmt und anders beantwortet als wir: Ihre Retrospektive wird zu einer datengestützten Debugging-Sitzung, bei der die Metriken der Agenten (Häufigkeit der Prompt-Neuschreibung, Abweichungsraten, Token-Verbrauch) im Mittelpunkt stehen. Das ist eine nützliche Perspektive, und ein Team könnte beides durchführen. Allerdings werden dabei die Agenten überprüft; der Ansatz, um den es in diesem Artikel geht, befasst sich hingegen mit der Zusammenarbeit: Ursachen statt Symptomen, Korrekturen, die auf die jeweilige Ebene geleitet werden, auf die sie gehören (das Briefing, die Dokumentation, der Prozess, das Material), wobei die Agenten ihre eigene Darstellung der Arbeit beisteuern, anstatt lediglich als Dashboard zu erscheinen.

Die Lücke liegt nicht in der Technologie. Alle Komponenten (Erfassung, Zusammenführung, Berichterstellung) sind bereits heute verfügbar. Die Lücke liegt in der Praxis: Fast niemand hat bisher dargelegt, was das Team gemeinsam unternimmt, wenn der Bericht vorliegt.

Was benötigt eigentlich einen Raum?

Der erste Impuls besteht hier darin, die Automatisierung weiter voranzutreiben: besseres Clustering, automatisch zugeordnete Korrekturen, ein Dashboard. Für einen Großteil der Feststellungen ist dies richtig, und die oben genannten Pipelines erfüllen diese Aufgabe gut. Führen Sie jedoch die Entscheidungen auf, die der Bericht tatsächlich aufwirft, und beachten Sie deren Struktur:

• Behalten oder streichen. Welche wiederkehrenden Reibungspunkte stellen Verschwendung dar, und welche dienen der bewussten Steuerung? Das Überprüfungs-Gate, das den Agenten verlangsamt, könnte die Leine sein, für die sich jemand entschieden hat (eine Zusammenfassung des Vortrags von Armin Ronacher auf der AIE Europe: „Reibung ist das, was notwendig ist … um zu steuern“); Thoughtworks’ Radar warnt nun vor der kognitiven Schuld, die durch das Entfernen von zu vielen Elementen entsteht. Das Löschen eines Kontrollpunkts verändert das Risiko für alle Beteiligten. Das ist per Definition eine Teamentscheidung.
• Wo die Lösung ansetzt. Ein wiederkehrendes Problem lässt sich auf einer bestimmten Ebene: einer persönlichen Anmerkung, einer Anleitung oder Fertigkeit, einer Umgebungskonfiguration, der Dokumentation, dem Arbeitsmaterial selbst, dem Prozess oder auf der übergeordneten Ebene bei einem Anbieter beheben. Diese Elemente haben Verantwortliche, und diese Verantwortlichen sind unterschiedliche Personen.
• Priorität bei der Aggregation. Fünf vernachlässigte Minuten pro Person und Sitzung bleiben für den Einzelnen unbemerkt, summieren sich jedoch zu erheblichen Kosten für das Team. Um hier Abhilfe zu schaffen (die gemeinsame Vorlage überarbeiten, den Aufnahmevorgang ändern, die Angelegenheit an den Anbieter eskalieren), ist eine Entscheidungsbefugnis erforderlich, über die kein Einzelner verfügt.
• Die Übernahmeprobe. Wurde die Korrektur aus dem letzten Zyklus tatsächlich übernommen, und hat sich die Reibung damit beendet? Der wertvollste Satz unseres eigenen Boards lautete genau so: gestern markiert, nie geschrieben. Eine Schleife ohne diese Überprüfung ist wie ein Schwungrad, das sich in der Luft dreht.

Keine dieser Maßnahmen ist eine Berechnung. Es handelt sich bei allen um Abstimmungen zwischen Personen, die für verschiedene Aspekte der Teamarbeit verantwortlich sind. Einzelkämpfer integrieren diese Entscheidungen zu Recht intuitiv; agile Pipelines erstellen zu Recht die maschinenlesbare Teilmenge in maschineller Geschwindigkeit. Die teamweiten Varianten erfordern Menschen in einem Raum, die über ein gemeinsames Vokabular verfügen und die Befugnis haben, die Aufmerksamkeit neu zu verteilen. Das ist keine Pipeline. Das ist eine Zeremonie.

Warum die Retro-Zeremonie – oder eine Zeremonie ähnlicher Art?

Eine vollständige Offenlegung vor der Argumentation: Wir verkaufen Retrospektive-Software. Genau aus diesem Grund stützt sich dieser Abschnitt auf Eigenschaften und nicht auf die Marke: Bitte werten Sie unsere Schlussfolgerung entsprechend ab und überprüfen Sie die Eigenschaften selbst.

Die Eigenschaften, die die Entscheidungsgruppe erfüllen muss: ein Ort, der regelmäßig genutzt wird (chronische kleinere Reibungspunkte lösen niemals ein einmaliges Treffen aus), nach den geltenden Normen frei von Schuldzuweisungen, bereichsübergreifend (die Verantwortlichen für Prozesse, Dokumentation, Werkzeuge und Prioritäten sind anwesend) und auf Fakten gestützt sein. Für die meisten Teams ist die Sprint-Retrospektive bereits der Ort, an dem diese vier Eigenschaften gegeben sind: kein neues Meeting, das in einem Kalenderkrieg verteidigt werden muss, und eine Konvention der Schuldfreiheit, die wichtiger ist, als es den Anschein hat, denn die verlockende Fehlerquelle ist hier die Postmortem-Analyse, bei der Einzelpersonen die Schuld zugewiesen wird, und die „Harness-Engineering“-Schule lehnt diesen Standard ausdrücklich ab: Der Ingenieur macht das Modell verantwortlich und legt den Fall unter „Warten auf die nächste Version“ ab; Stattdessen sollte der Harness korrigiert werden (Osmani, Agent Harness Engineering).

Die ehrliche Formulierung dieser Behauptung bewertet jedoch eher die Konkurrenten, anstatt einen Sieger zu benennen:

• Die Sprintplanung hat im Raum das größte Gewicht, doch ihre Tagesordnung ist zukunftsorientiert und stets überfüllt; die Retrospektive kommt in einem Planungsfenster zuverlässig zu kurz. In der Planung werden beschlossene Maßnahmen terminiert, nicht Muster analysiert.
• Die „schuldlose Nachbesprechung“ verfügt über genau die richtigen Vorgaben, aber den falschen Auslöser: Sie wird bei großen, punktuellen Fehlschlägen einberufen, niemals jedoch bei dem Muster „fünf Minuten pro acht Personen pro Sprint“ – und genau dieses Muster lässt sich nur durch eine Gesamtbetrachtung erkennen.
• Asynchron – ein Bericht plus ein Tracker ist die kostengünstigste Lösung und für die meisten Routineaufgaben ausreichend. Was damit jedoch nicht möglich ist, ist die Entscheidungsfindung: Die Entscheidung „behalten oder streichen“ ist eine Verhandlung, Streitigkeiten über den Prioritätsgrad gehen über Zuständigkeitsgrenzen hinaus, und eine Neugewichtung der Prioritäten erfordert, dass die Verantwortlichen an derselben Besprechung teilnehmen.
• Die Nullalternative – einfach nur über KI im Retro zu sprechen, ohne Aufzeichnungen und ohne Bezeichnungen – ist kostenlos, passt zur aktuellen Situation und kann für ein kleines Team mit geringem Agenteneinsatz tatsächlich ausreichen. Beginnen Sie damit. Was diese Vorgehensweise jedoch nicht leisten kann, ist die Vergleichbarkeit über Sitzungen hinweg, die Erkennung von Trends oder die Überprüfung der Akzeptanz: Ein Gespräch, das jedes Mal bei Null beginnt. Die im Folgenden beschriebene Vorgehensweise wenden Sie an, wenn sich dieses Gespräch immer wieder wiederholt.

Die Behauptung, ehrlich gesagt: das Retro – oder Ihre bestehende Zeremonie in gleichwertiger Form. Die monatliche Kampagnenüberprüfung eines Medienteams und die Triage-Überprüfung eines Supportteams sind ein und dieselbe Vorgehensweise unter unterschiedlichen Bezeichnungen, und nichts an dieser Vorgehensweise setzt Programmierkenntnisse voraus: Das Fehlerprotokoll eines verworrenen Anzeigenkontos oder einer inkonsistenten Vorlagenbibliothek liest sich genau wie das Fehlerprotokoll eines veralteten Repositorys.

Die Person im Raum – Teilnehmer, niemals Moderator

Wenn die Beweise von Agenten stammen, sollte der Agent den Fall dann bearbeiten? Nein, und zwar nicht in erster Linie aus dem Grund, den Sie vermuten würden.

Der Grund dafür ist folgender: Die heutigen Modelle sind gerade bei dieser Art von Beurteilung unzuverlässig: Die Entscheidungen von LLMs schwanken bei identischen Eingaben in ~13,6 % der Fälle, und in einer achtwöchigen Produktionsstudie wurden ~70 % der stillen Agent-Ausfälle zunächst von einer Person entdeckt, nicht durch Tests oder Überwachung. Das trifft heute zu; Modelle verbessern sich jedoch.

Der Grund, warum dies nicht nachlässt: Moderation und Entscheidungsfindung verteilen die Aufmerksamkeit eines Teams und verändern die Artefakte, für die das Team verantwortlich ist und die es zu verantworten hat. Diese Befugnis geht nicht auf die kompetenteste Person im Raum über, genauso wenig wie sie auf den kompetentesten Ingenieur im Raum übergeht. Es handelt sich um eine organisatorische Tatsache, nicht um eine Kompetenzlücke.

Der Mitarbeiter beteiligt sich also so, wie es der bestinformierte Mitwirkende tut. Er legt Belege vor: seine Sitzungsprotokolle, mit Kennzeichnungen und Kostenangaben versehen. Er beantwortet Fragen: Auf die Frage „Was haben Sie vor der Umgehungslösung tatsächlich versucht?“ gibt es eine durch das Protokoll belegte Antwort. Er entwirft, entscheidet jedoch nie: Vorgeschlagene Lösungen werden mit empfohlenen Prioritätsstufen eingereicht; die Gruppe überarbeitet, priorisiert neu oder verwirft sie. Und er nimmt akzeptierte Maßnahmen zurück (die Dokumentbearbeitung, die Konfigurationsänderung) und führt sie nach der Besprechung im Rahmen der üblichen Überprüfung durch. In der Forschungspraxis gibt es einen Begriff für diese Aufteilung: Im ACE-Framework fungiert der Agent als Reflektor, während ein Kurator das zusammenfasst, was in das Playbook aufgenommen wird. Wir nehmen eine bewusste Anpassung vor: In ACE ist der Kurator eine deterministische Komponente; hier sind die Kuratoren das Team.

Eine Asymmetrie betrifft die Datenübertragung. Alles, was der Agent in den Raum einbringt, sollte uneingeschränkt zugänglich sein – ein Agent, der eine Berechtigung benötigt, um Reibungsprobleme zu melden, meldet diese nur unvollständig. Alles, was den Raum verlässt und in das einfließt, worauf sich Agenten später stützen (Speicher, Kontextdateien, Konfiguration), durchläuft eine reguläre Überprüfung, da dieser Schreibpfad eine anerkannte Angriffsfläche für Manipulation und Abweichungen darstellt (OWASP Agentic Top 10, ASI06). Das Verfahren befindet sich genau an dieser Grenze: unkontrollierte Eingaben, kontrollierte Schreibvorgänge.

Die fünfzehn Minuten

Was wir einem Team tatsächlich vorschlagen, ist, dies in diesem Sprint auszuprobieren, wobei jede Schleife bereits einwandfrei läuft:

1. Pro Sitzung verfasst der Mitarbeiter eine kurze Retrospektive auf seine eigene Arbeit: Was gut gelaufen ist, alle Probleme mit Angabe der Grundursache und der damit verbundenen Kosten, einen Vorschlag für eine Lösung im Umfang eines Tickets sowie die angestrebte Zielebene. Wird zusammen mit der Arbeit committet, ohne Zugangsbeschränkung.
2. Vor dem Rückblick werden die seit dem letzten Mal eingegangenen Beiträge in einem einseitigen Überblick zusammengefasst: häufig auftretende Themen, welche Gruppe von Ursachen überwiegt, ob frühere Lösungsvorschläge umgesetzt wurden sowie die drei wichtigsten empfohlenen Maßnahmen. Der Überblick dient als Grundlage für die Diskussion; er ersetzt diese jedoch nicht.
3. Im Rückblick (ein Tagesordnungspunkt, keine neue Sitzung): 15 Minuten zum Thema „Was hat in diesem Zyklus im Bereich KI gut funktioniert und was hat immer wieder Probleme verursacht?“ Die Verantwortlichen treffen eine Vorauswahl: Beibehalten oder streichen, die Prioritäten bestätigen oder neu ausrichten, den drei wichtigsten Punkten Verantwortliche zuweisen.
4. Im nächsten Zyklus wird im Annahmecheck des Briefings überprüft, ob die Reibung tatsächlich zurückgegangen ist. Durch diese Überprüfung entsteht eine Schleife im Bericht – und genau an dieser Stelle hat uns unser eigener Vorstand auf den Fehler hingewiesen.

Fehlermodi, die so benannt sind, dass Sie sich gegen sie wappnen können: Retro-Theater (die Zeremonie, die Sie für das Publikum abhalten: kurze Lesung, Kopfnicken, keine Entscheidungen; dafür gibt es die „Top-3-mit-Verantwortlichen“-Regel); Agent-Schuld (die Aussage „der Agent hat einen Fehler gemacht“ als Erklärung statt als Restfehler zu betrachten; die meisten Fehler lassen sich auf den Testrahmen und die Eingaben zurückführen, nicht auf die Modelllogik); Wunschliste-Ausuferung (zwanzig Maßnahmen, keine Verantwortlichen); und die Schleife schließt sich nie (die Lücke bei der Umsetzung: Korrekturen werden umgesetzt, niemand überprüft den Trend). Wir haben einen ganzen Leitfaden darüber verfasst, wie Zeremonien scheitern; jeder darin beschriebene Modus trifft auch hier zu.

Was wir nicht behaupten

Kein Ersatz für irgendeinen Anbieter-Kreislauf: Deren Ergebnisse sind die Eingaben für diese Zeremonie. Kein neues Meeting. Keine von KI gesteuerte Zeremonie; bei einem Unternehmen, dessen Produkt Retrospektiven sind, ist diese Leitplanke bewusst gewählt. Nicht notwendig für Einzelpraktiker, deren Kreisläufe sich intuitiv gut schließen lassen. Und das Ziel ist nicht „Reibungsfreiheit“: Ein gewisses Maß an Reibung dient als Steuerungsinstrument, und der Tagesordnungspunkt dient dazu, eine Auswahl zu treffen, nicht dazu, etwas auf Anhieb zu eliminieren.

Was könnte uns umstimmen?

Da es sich hierbei um ein Diskussionspapier handelt, folgt nun der falsifizierbare Teil: Sollten die Anbieter-Schleifen zu einer echten, werkzeug- und personenübergreifenden Beurteilung führen – und nicht lediglich zu flottenweiten Speicherschreibvorgängen –, schrumpft der Spielraum auf eine reine Prüfungsfunktion. Sollten Teams, die die rein asynchrone Version mit Kurzbriefing durchführen, denselben Trend zur Reibungsreduzierung aufweisen wie Teams, die den Tagesordnungspunkt bearbeiten, sind die fünfzehn Minuten reine Show – und das werden wir auch so sagen. Unsere Behauptung bezüglich des gekennzeichneten Vokabulars stützt sich zudem auf ein Experiment zur Interrater-Reliabilität, das wir derzeit anhand realer Einträge durchführen, anstatt dies im Voraus zu behaupten. Wir möchten lieber die Zahlen veröffentlichen als unsere Zuversicht.

Falls Ihr Team eine beliebige Variante davon durchführt (den Tagesordnungspunkt, den asynchronen Brief oder eine Zeremonie, an die wir noch nicht gedacht haben), würden wir gerne erfahren, wie es gelaufen ist: ai-discussion@teamretro.com.

---

Nächstes Kapitel: Durchführung der AI-Kooperations-Retrospektive – Leitfaden für Moderatoren zu den fünfzehn Minuten: die Vorlage, das Eingabeformat und die Prompt-Karten. Teil des Leitfadens für AI-Agenten-Retrospektiven.