Durchführung der AI-Kooperations-Retrospektive

Bei TeamRetro interessieren wir uns für jeden Zyklus der kontinuierlichen Verbesserung, den ein Team durchläuft. KI-gestützte Arbeit ist ein neues Gebiet, das wir aus der Perspektive unserer Retrospektiven beleuchtet haben; in diesem Leitfaden teilen wir Ihnen mit, zu welchen Erkenntnissen wir bislang gelangt sind. Nehmen Sie ihn an, passen Sie ihn an und setzen Sie ihn in den Tools oder Zeremonien um, die Sie bereits nutzen.

Teil 1: Der Leitfaden

Warum dies in eine Teamfeier gehört

Irgendwo in Ihrem Team hat ein KI-Assistent diesen Monat vierzig Minuten damit verbracht, eine „fehlgeschlagene“ Werbekampagne zu überprüfen, die absichtlich pausiert worden war, da dies im Auftrag nicht vorgesehen war. Die für die Sitzung verantwortliche Person hat den Fehler korrigiert, mit den Schultern gezuckt und ist zur nächsten Aufgabe übergegangen. Wenn vier Kollegen auf unterschiedliche Varianten derselben Lücke stoßen, bedeutet das stundenlange stille Verschwendung pro Monat, und niemand weiß davon, da jede Person diese Belastung allein verkraftet hat.

Das ist das typische Muster bei Reibungsverlusten in KI-Sitzungen: Sie sind chronisch und geringfügig, sodass sie niemals eine Nachanalyse auslösen, und sie sind vergänglich, sodass sie sich mit Ende der Sitzung in Luft auflösen. Die meisten Teams können diese Probleme bereits beobachten (etwa 90 % erfassen ihre Agent-Traces), doch weitaus weniger setzen dies in Korrekturmaßnahmen um: Nur etwa 37–52 % werten die erfassten Daten systematisch aus (LangChain, Juni 2026).

Die bereits vorhandenen Verbesserungszyklen sind gut, und diese Vorgehensweise baut auf allen auf: Aktualisierungen von Kontextdateien, Speichersysteme, Pipelines zur Selbstoptimierung der Anbieter AGENTS.mdsowie Fehleranalysen anhand von Trace-Daten (Husain & Shankar, FAQ zu Evaluierungen). Selbst die Anbieter greifen auf den Begriff „Retro“ zurück: In den Codex-Leitlinien von OpenAI heißt es: „Wenn Codex denselben Fehler zweimal macht, bitten Sie es um eine Retrospektive und aktualisieren Sie AGENTS.md“ (Best Practices). Doch fast alle diese Kreisläufe finden im Alleingang statt: eine Person und ihr Agent oder eine Plattform und ihre Flotte. Was die Teamebene hinzufügt, ist Aggregation: Reibungsverluste, die pro Person nur fünf leichtfertig abgetane Minuten ausmachen, werden erst in der aggregierten Sicht zu einem erheblichen Kostenfaktor für das Team, und um darauf zu reagieren (die gemeinsame Vorlage umschreiben, den Aufnahmeprozess ändern, das Tool anschaffen), ist eine Entscheidungsbefugnis erforderlich, über die kein Einzelner verfügt. Rahul Gargs „Feedback Flywheel“ benennt den Rahmen: „Ein Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ (martinfowler.com), und dieser Leitfaden ist eine Möglichkeit, dies umzusetzen.

Ein ehrliches Eingeständnis gleich zu Beginn: Was hier benötigt wird, ist eine regelmäßig stattfindende, unvoreingenommene und auf Fakten basierende Besprechung, an der die für die Fehlerbehebung Verantwortlichen teilnehmen. Für die meisten Teams ist das die Retrospektive, aber auch ein Termin im Rahmen der Sprintplanung, eine monatliche Betriebsbesprechung oder die Account-Besprechung des Medienteams eignet sich dafür ebenso gut. Die Retrospektive oder Ihre bestehende Zeremonie ähnlicher Art.

Wissenswertes für Moderatoren: Scrum.org nähert sich demselben Thema aus der Perspektive der Metriken; ihr Leitfaden zur Durchführung der Sprint-Retrospektive, wenn die Hälfte Ihres Teams aus KI-Agenten besteht, betrachtet die Veranstaltung als datengestützte Überprüfung der Agentenleistung (Neufassung von Prompts, Abweichungsraten, Token-Verbrauch). Dieser Leitfaden verfolgt den komplementären Ansatz: Ursachenanalyse und Abhilfemaßnahmen über die gesamte Zusammenarbeit hinweg, wobei die Agenten ihre eigenen Berichte zur Arbeit beisteuern, die – sofern Sie TeamRetro nutzen – über den TeamRetro-MCP-Server eingereicht werden. Teams mit umfangreichen Agentenflotten sollten möglicherweise Elemente aus beiden Ansätzen kombinieren.

So funktioniert die Praxis von Anfang bis Ende

1. Protokollierung pro Sitzung. Am Ende jeder umfangreichen, KI-gestützten Sitzung verfasst der Mitarbeiter einen kurzen, strukturierten Eintrag: Was lief gut, was zog sich in die Länge (jeder Punkt wird mit einer Grundursache und einer Lösungsvorschlag versehen), welche Vermutungen wurden angestellt und welche Maßnahme hat die größte Wirkung. Pro Eintrag wird eine Datei in einem gemeinsamen Protokoll angelegt.
2. Zusammenfassung nach ca. 5 Einträgen. Vor der Zeremonie fasst der Bearbeiter das Protokoll zu einem einseitigen Bericht zusammen: wiederkehrende Themen, geordnet nach Häufigkeit × Kosten, eine Verteilung der Grundursachen, eine Überprüfung, ob frühere Korrekturmaßnahmen umgesetzt wurden, sowie die drei wichtigsten empfohlenen Maßnahmen.
3. Entscheiden Sie sich innerhalb von 15 Minuten. Der Bericht ist ein Tagesordnungspunkt in Ihrer bestehenden Retrospektive, kein neues Meeting. Das Team nimmt eine Priorisierung vor: Es entscheidet, ob jedes Hindernis beibehalten oder beseitigt werden soll, legt fest, wo die jeweiligen Korrekturmaßnahmen umgesetzt werden sollen, und weist den wichtigsten Maßnahmen Verantwortliche zu. Im Bericht des nächsten Zyklus wird festgehalten, ob das Hindernis tatsächlich abgebaut wurde.

Die Erfassungs- und Syntheseschritte sind als Open-Source-Agentenfähigkeiten in unserem „TeamRetro-skills“-Repository implementiert, falls Sie einen schnellen Einstieg wünschen.

Der Agent meldet ohne Einschränkung: Ein Agent, der eine Berechtigung zur Erfassung von Reibungsverlusten benötigt, meldet diese unvollständig, und nachträgliche manuelle Korrekturen stellen ein zusätzliches Signal dar, nicht jedoch einen Kontrollpunkt, auf den die Schleife wartet. Die Entscheidung liegt beim Team, und das nicht nur aus Höflichkeit: Die Korrekturen fließen in Budgets, Dokumente, Prozesse und Werkzeuge ein, für die die Mitarbeiter verantwortlich sind und Rechenschaft ablegen. Der Agent legt Belege und Entwürfe vor; das Team entscheidet.

So sieht ein guter Beitrag aus

Hier ist ein Beispiel aus der Praxis, bei dem es bewusst nicht um das Programmieren geht:

# 2026-07-16: Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June, unverified

## Do this first
Campaign-status flags in the brief template. Kills the largest single time sink this month.

Beachten Sie die Disziplin. Jeder Reibungspunkt enthält einen Zeitpunkt und Kosten (grobe Schätzungen sind mit gekennzeichnet(est.)) sowie genau eine Ursache aus einem kleinen, festgelegten Vokabular (Bezeichnungen wie ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool, agent-error, oder work-material-friction, wobei das Material selbst den Widerstand darstellte: eine verworrenen Kampagnenstruktur, eine veraltete Tabellenkalkulation, ein Modul, das niemand anfassen möchte – stets unter Nennung des konkreten Materials) und schließt mit einer Lösung in Ticket-Größe, die deren Priorität benennt: Gehört diese Korrektur in eine private Notiz, eine Vorgehensweise, die Umgebung, die Dokumentation, das Arbeitsmaterial selbst, den Prozess oder weiter oben bei einem Lieferanten? Feste Bezeichnungen sorgen dafür, dass Einträge über Personen und Sitzungen hinweg vergleichbar sind; „die Dokumentation war verwirrend“ lässt sich nicht aggregieren, acht Einträgemissing-documentation hingegen schon. Unbestimmtheit ist der Fehlermodus; „nichts Bemerkenswertes“ ist ein gültiger Eintrag.

Ein guter Überblick umfasst eine Seite: Themen mit Häufigkeitsangaben („4 von 9 Sitzungen“) und datierte Beispiele, eine klare Angabe, welche Gruppe von Grundursachen überwiegt (Briefing, Dokumentation, Arbeitsmaterial, Werkzeuge oder Mitarbeiter; darauf sollte sich die Aufmerksamkeit des Teams konzentrieren), die Überprüfung der Umsetzung früherer Vorschläge sowie drei Maßnahmen, denen jeweils ein Verantwortlicher zugewiesen werden kann. Er dient als Grundlage für die Diskussion; er ersetzt diese jedoch nicht.

Geltungsbereich: ein Protokoll pro Prüfungsbereich

Führen Sie pro Prüfungsbereich ein Protokoll: Dies ist der Bereich, in dem Korrekturen vorgenommen werden. Bei der Entwicklungsarbeit ist dies in der Regel das Repository, da sich dort die Dokumentation, die Konfiguration und die Konventionen befinden. Bei nicht-codebezogenen Aufgaben ist es das Anzeigenkonto, der Support-Posteingang oder die Kundenbetreuung; das Protokoll wird im Dokumentenverzeichnis des jeweiligen Arbeitsbereichs abgelegt. Ein Eintrag, der außerhalb seines Geltungsbereichs abgelegt wird, wird vom späteren Verantwortlichen für die Behebung niemals gefunden. Das Schema bleibt überall identisch; das Schema – nicht der Speicherort – sorgt dafür, dass Einträge zusammengefasst werden.

Die „Never-Log“-Regeln

Einträge werden festgehalten, weitergegeben und überdauern ihren Kontext; daher dürfen bestimmte Dinge niemals darin erscheinen: Geheimnisse, Zugangsdaten oder Schlüssel jeglicher Art; Kundendaten oder personenbezogene Informationen; noch nicht veröffentlichte Geschäftszahlen; und – was für die Retro-Kultur am wichtigsten ist – Namen, Rollen oder alles, was eine Person identifiziert. Beschreiben Sie die Lücke und die damit verbundenen Kosten, niemals jedoch, wer sie verursacht hat: „Das Briefing ließ die Zielgruppe offen“, nicht „das Briefing von X“. Reibungspunkte kritisieren Eingaben und Systeme, nicht Personen. Wenn sich die Reibung eines Projektumfangs nicht ohne sensiblen Kontext beschreiben lässt, halten Sie diese Einträge privat und geben Sie nur das zusammengefasste Briefing weiter.

Teil 2: Die Vorlage „AI Collaboration Retro“

Ein gebrauchsfertiges Format: fünf Leitfragen, die auf dem Einstiegsschema basieren und in TeamRetro oder auf jedem Whiteboard umgesetzt werden können:

Kolumne	Eingabeaufforderung	Einzeiler
Es ist gut gelaufen	Was konnte in diesem Zyklus durch KI-gestützte Arbeit schneller oder besser erledigt werden?	Ausschließlich zitierte Belege: Was geschützt und wiederholt werden sollte, ohne übertriebene Lobeshymnen.
Reibung und deren Ursache	Wo kam es zu Verzögerungen, und was war die eigentliche Ursache dafür?	Auf jeder Karte sind der Zeitpunkt, die ungefähren Kosten und ein Begriff aus dem festgelegten Vokabular des Teams angegeben.
Vermutungen, die wir unkommentiert lassen	Was hat der Makler (oder haben wir) ohne ausreichende Informationen angenommen?	Latente Reibungspunkte, die bislang noch keine negativen Auswirkungen gezeigt haben; kennzeichnen Sie alles, was noch nicht überprüft wurde.
Behalten oder töten	Welche dieser Reibungspunkte haben wir bewusst gewählt?	Prüfschritte und Genehmigungsphasen können bewusst festgelegte Kontrollpunkte sein (Zusammenfassung des Vortrags von Ronacher auf der AIE Europe); die Streichung eines solchen Schritts ist eine Teamentscheidung.
Bitte führen Sie dies zuerst durch	Von all dem hier: Welche Maßnahme zahlt sich am meisten aus, und in welcher Höhe?	Maximal drei, jeweils mit einem Verantwortlichen und der Ebene, auf der sie angesiedelt sind: Dokumente, Umgebung, Prozess, Material oder vorgelagerte Bereiche.

Teil 3: Hinweiskarten für Moderatoren

Fragen, die Sie stellen sollten, wenn ein Team einen AI-Retro-Auftrag zur Sitzung mitbringt. Je eine pro Karte; verwenden Sie diejenigen, die für das Gespräch erforderlich sind.

1. „Aus welcher Sitzung stammt diese Aufzeichnung, und wie hoch waren die Kosten?“ Für Musterbehauptungen sind datierte Belege erforderlich; eine Aufzeichnung ohne Zeitangabe und Kostenangabe kann nicht geprüft werden.
2. „Ist diese Reibung ein Kontrollpunkt, den wir bewusst gewählt haben?“ Zunächst einmal das Prinzip „Behalten oder streichen“: Ein gewisses Maß an Reibung dient der Steuerung (Zusammenfassung von Ronachers Vortrag auf der AIE Europe), und Reibungslosigkeit hat ihren Preis; Thoughtworks warnt vor der kognitiven Verschuldung, die dadurch entsteht (Ankündigung).
3. „Wir haben diese Lösung bereits beim letzten Mal vorgeschlagen. Was hat die Umsetzung verhindert?“ Nicht umgesetzte, wiederholt vorgebrachte Vorschläge sind der wichtigste Punkt in jedem Bericht; ohne diese Frage ist das Ganze nur Show.
4. „Das hat jeden von Ihnen zehn Minuten gekostet – wie hoch sind die monatlichen Kosten für das Team?“ Die Aggregation ist der entscheidende Vorteil der Teamebene; fragen Sie danach, wann immer eine Karte ignoriert wird.
5. „Gehört diese Korrektur in die Dokumentation, in die Umgebung oder in die Arbeitsanweisungen?“ Die Frage nach dem richtigen Maß. Liegt das Ziel zu niedrig, tritt das Problem erneut auf; liegt es zu hoch, blähen Sie das falsche Artefakt auf.
6. „Wem gehört das Artefakt, bei dem diese Korrektur ansetzt?“ Eine Handlung ohne Eigentümer ist ein Wunschobjekt. Befindet sich der Eigentümer nicht im Raum, handelt es sich ebenfalls um einen Fund.
7. „Bevor wir dies als Fehler des Agenten bezeichnen, sollten wir uns fragen: Waren die Eingaben angemessen?“ – dies istagent-error die Restbezeichnung, nicht die Standardbezeichnung; die abzulehnende Standardhaltung besteht darin, dem Agenten die Schuld zu geben, obwohl das Problem beim Harness oder bei der Aufgabenstellung lag – beheben Sie daher stattdessen den Harness (Osmani, Agent Harness Engineering).
8. „Welche Gruppe von Grundursachen dominiert die Verteilung, und richten wir unsere Aufmerksamkeit darauf?“ Die Zahlen in der Zusammenfassung geben Aufschluss darüber, ob das Problem bei der Einweisung, der Dokumentation, den Arbeitsunterlagen, den Arbeitsmitteln oder der Einrichtung der Arbeitsstationen liegt. Die Aufmerksamkeit sollte sich an den Daten orientieren.
9. „Hat dies eine Person bemerkt oder der Agent?“ Die Korrektur durch Menschen ist nach wie vor der maßgebliche Sensor: Eine Produktionsstudie ergab, dass etwa 70 % der stillen Fehler zunächst von einer Person entdeckt wurden, der etwas Ungewöhnliches auffiel (arXiv 2606.14589). Behandeln Sie diese Entdeckungen als erstklassige Hinweise und nicht als Unterbrechungen.
10. „Handelt es sich hierbei um den Zuständigkeitsbereich unseres Teams oder um den eines anderen Teams?“ Korrekturen werden dem jeweiligen Überprüfungsbereich zugeordnet; eine Karte, die sich auf die gemeinsame Vorlage oder den Prozess eines anderen Teams bezieht, sollte weitergeleitet und nicht übernommen werden.
11. „Ist dies eine Diskussion oder eine Erfassung?“ Die offensichtlichen Korrekturen werden direkt in den Tracker eingetragen; widmen Sie die fünfzehn Minuten ausschließlich den umstrittenen Entscheidungen: Beibehalten oder Streichen, Höhenstreitigkeiten, Prioritäten.
12. „Liegt diese Entscheidung über den Befugnissen eines Einzelnen von uns?“ Der Kauf eines Werkzeugs, die Änderung der Zufuhr, die Eskalation an einen Lieferanten: Die neu gewichtete Prioritätenliste überschreitet oft die Grenzen der individuellen Entscheidungsbefugnis. Genau das ist der Grund, warum dieser Punkt überhaupt zur Sprache kommt.

---

Nächstes Kapitel: In zehn Minuten loslegen. Installieren Sie die Skills und führen Sie Ihre erste Erfassung durch, oder übertragen Sie die obige Vorlage auf das Board, das Ihr Team bereits nutzt. Teil des Leitfadens zu Retrospektiven mit KI-Agenten.