CLAUDE.md für Teams: Wie wir die KI-Erinnerungen von fünf Personen in gemeinsame Regeln umgewandelt haben

Jeder Entwickler, der mit einem KI-Programmierassistenten arbeitet, erstellt still und leise ein Regelwerk. Der automatische Speicher von Claude Code speichert während der Arbeit Notizen zu Ihren Korrekturen, Ihr persönliches Profil sammelt~/.claude/CLAUDE.md die Einstellungen, die Sie nicht mehr immer wieder neu eingeben möchten, und es entwickeln sich einige persönliche Fähigkeiten rund um die Aufgaben, die Sie jede Woche erledigen. All dies ist privat. Der automatische Speicher ist gerätegebunden und gilt pro Repository: Die Agenten Ihrer Teamkollegen haben keinen Zugriff darauf.

So lernen fünf Personen unabhängig voneinander dieselbe Lektion, jede in einer eigenen Datei. Die Regeln, die Ihr Team am dringendsten benötigt, sind bereits festgehalten. Sie sind lediglich nicht an einem gemeinsamen Ort festgehalten.

Im September führten wir zu fünft eine „Erinnerungssammlung“ durch: Wir legten diese privaten Aufzeichnungen zusammen und fragten uns, welche Regeln es verdienten, zu Teamregeln zu werden. So sind wir vorgegangen, welche Regeln den Sprung geschafft haben, wo jede Regel ihren Platz fand und was wir dabei festgestellt haben – einschließlich der Regeln, bei denen wir uns geirrt haben.

Was eine „Ernte der Erinnerungen“ ist

Eine „Memory Harvest“ ist eine Teamübung, die aus drei Schritten besteht. Jede Person exportiert ihre privaten Agenten-Erinnerungen und persönlichen Regeln. Ein Prüfer fasst die Einträge aus den Exporten aller Teilnehmer zu Clustern zusammen. Die Regeln, die mehrere Personen unabhängig voneinander notiert haben, werden für die gemeinsamen Dateien vorgeschlagen: das ProjektCLAUDE.md``AGENTS.md, eine gemeinsame Kompetenz oder einen Check-in in CI.

Es handelt sich um den Wartungsschritt, den das Context Engineering in der Regel überspringt. Wir haben bereits zuvor dargelegt, dass Kontextdateien eine Rückkopplungsschleife benötigen, die von den Agenten gesteuert wird, die sie nutzen. Ein „Harvest“ ist dieselbe Schleife, die nicht auf Sitzungen, sondern auf Personen angewendet wird: Es handelt sich um Phase 4 des Agenten-Feedback-Lebenszyklus, die auf die Notizen abzielt, die bereits im privaten Gedächtnis gestrandet sind.

Die entsprechenden Werkzeuge hierfür sind noch spärlich. Von zehn KI-Programmierwerkzeugen, die wir uns angesehen haben, bietet nur Devin eine Schleife, die eine Sitzung überwacht, eine gemeinsame Regel vorschlägt und darauf wartet, dass ein Mensch diese genehmigt. Die übrigen stützen sich auf Dateien, die von Nutzern manuell geschrieben und committet werden, oder auf Anweisungssätze, die ein Administrator bereitstellt. Keines dieser Tools wertet die persönlichen Erinnerungen mehrerer Personen aus, um mögliche Teamregeln zu ermitteln.

Was wir getan haben

Am 17. September 2026 führten fünf Entwickler jeweils ein Exportskript auf ihre eigenen Claude-Code-Speicher, ihre persönlichen globalen Daten undCLAUDE.md ihre persönlichen Fähigkeiten aus. Das Skript überträgt keinerlei Daten. Jede Person las ihr eigenes Datenbündel durch, löschte alles, was nicht übertragen werden sollte, und reichte es erst danach ein.

Die fünf Bündel enthielten 444 Speichereinträge, 5 globale CLAUDE.mdDateien, 13 persönliche Fähigkeiten und 194 Zeilen, die die in jedem Repo installierten Fähigkeiten beschrieben. Ein Prüfer – ein KI-Agent, der mit einem Menschen zusammenarbeitete – gruppierte die Einträge über alle fünf Bündel hinweg und verfasste für jede Gruppe einen Vorschlag. Am 22. September stimmten vier von uns auf zwei Überprüfungsseiten ab. Die Beförderungen wurden als gewöhnliche Pull-Anfragen in drei Repositories übernommen: unserem Hauptprodukt-Repository, einem Spiele-Repository und unserem gemeinsamen Fähigkeiten-Plugin.

Die Bundles befinden sich auf einem Branch, der niemals zusammengeführt wird. Lediglich die Promotions werden ausgegeben, jeweils als separater Pull-Request für das Repository, das sie betreffen, und wie jede andere Änderung geprüft.

Was zur Beförderung führt: Zählen Sie die Autoren, nicht die Beiträge

Eine Regel wird hochgestuft, wenn zwei oder mehr Personen sie unabhängig voneinander niedergeschrieben haben. Zählen Sie die einzelnen Autoren, niemals die Einträge. Diese eine Regel leistete den größten Teil der Arbeit, und es bedurfte dreier Verfeinerungen, bevor man sich darauf verlassen konnte.

Berücksichtigen Sie den Intensivnutzer. Ein Bundle umfasste 251 der 444 Einträge, verteilt auf 10 Repos. Alle anderen trugen 37 bis 68 Einträge aus 1 bis 4 Repos bei. Somit bedeutete „zwei Autoren“ in der Regel „unser aktivster Agent-Nutzer plus einer“, und ein Cluster ohne den aktivsten Nutzer war seltener und stellte einen stärkeren Beleg dar. Diese Cluster haben wir gesondert gekennzeichnet.

Eine Person entspricht einem Verfasser. Ein Entwickler, der Daten von zwei Rechnern exportiert hat. Das ist ein Verfasser. Wenn eine Person dieselbe Regel dreimal wiederholt, dient dies der Hervorhebung. Zur Bestätigung ist eine zweite Person erforderlich.

Gemeinsam genutzte Quellen sind nicht unabhängig. Die „global“-DateienCLAUDE.md zweier Personen waren in ihren ersten vier Abschnitten byteweise identisch, da beide denselben veröffentlichten Text übernommen hatten: Andrej Karpathys Programmierrichtlinien für KI-Agenten. Beide zitierten ein einziges übergeordnetes Dokument, sodass dies als eine einzige Quelle galt. Jeder zukünftige Cluster, der ausschließlich auf diesem Paar basiert, wird zunächst mit dem Wortlaut des übergeordneten Dokuments abgeglichen.

Zur Klassifizierung der einzelnen Cluster haben wir die vier Operatoren aus ExpeL übernommen, einer Forschungsmethode für Agenten, die Regeln aus Erfahrungen lernen: ADD – eine neue Regel hinzufügen, UPVOTE – eine Regel, die bereits in den gemeinsamen Dokumenten enthalten ist, DOWNVOTE – eine Regel, der die Beweislage widerspricht, EDIT – eine Regel, die zwar nahe daran liegt, aber falsch ist. „Downvote“ und „Edit“ sind ebenso wichtig wie „Add“. Ein Harvesting-Vorgang, der lediglich Regeln hinzufügen kann, verlängert Ihre Kontextdateien, ohne deren Richtigkeit zu verbessern.

Der Schwellenwert legt fest, was der Gutachter vorschlägt, nicht jedoch, was das Team möglicherweise annimmt. Auf einer zweiten Begutachtungsseite wurden die von einem einzelnen Autor verfassten Fakten aufgelistet, deren Veröffentlichung sinnvoll erschien, und die Anwesenden stimmten über jeden einzelnen ab. Sie wurden aufgenommen, weil die Anwesenden sie gelesen hatten und zustimmten.

Wo die einzelnen Regeln abgelegt werden sollten

Sich auf eine Regel zu einigen, ist bereits die halbe Entscheidung. Die andere Hälfte betrifft ihre „Ebene“: die Ebene, auf der sie tatsächlich gelesen und angewendet wird. (Unser Leitfadenkapitel darüber, wo eine Korrektur ansetzen sollte, behandelt diesen Ablauf ausführlich.) Für die gesammelten Regeln haben wir folgende Routing-Tabelle verwendet:

Die Regel lautet	Es gehört in	Warum
Eine unveränderliche Tatsache ist, dass jede Sitzung in diesem Repository Folgendes benötigt:	Das Projekt CLAUDE.md	Es wird zu Beginn jeder Sitzung geladen
Das Gleiche gilt für jedes KI-Tool, das das Team einsetzt	AGENTS.md, importiert aus CLAUDE.md	Eine Datei, die jedes Tool lesen kann
Betrifft nur einen Teil des Quellcodes	Eine Regel mit Pfadgültigkeitsbereich in .claude/rules/	Wird nur geladen, wenn der Agent auf entsprechende Dateien stößt
Ein Verfahren, das in mehreren Repositories zum Einsatz kommt	Eine Funktion in einem gemeinsam genutzten Plugin	Plugins enthalten Fähigkeiten, nicht CLAUDE.md
Eine für ein Repo spezifische Prozedur	Eine Repo-Fähigkeit	Wird geladen, wenn die Aufgabe dies erfordert
Die Referenzangaben sind zu umfangreich, um sie bei jeder Sitzung anzugeben	Ein Dokument sowie ein einzeiliger Hinweis in CLAUDE.md	Ein Dokument, das nicht geladen wird, ist ein Dokument, das der Agent niemals liest
Mechanisch überprüfbar	Eine Lint-Regel, ein Test oder eine CI-Prüfung	Prose warnt; ein Scheck verhindert es
Eine Präferenz hinsichtlich Ihrer eigenen Werkzeuge, Maschinen oder Ihres Budgets	Ihre persönliche Erfahrung CLAUDE.mdoder Erinnerung	Dies ist keine Tatsache bezüglich des Quellcodes

Zwei Punkte müssen besonders hervorgehoben werden. Erstens: Ein „Claude Code“-Plugin kann Skills, Agenten und Hooks enthalten, jedoch keine CLAUDE.md. Die Abläufe erstrecken sich über mehrere Repositories hinweg; allgemeine Regeln müssen in jedem Repository hinterlegt werden, in dem sie benötigt werden.

Zweitens: Löschen Sie den privaten Speicher erst, sobald das Ziel automatisch geladen wird. Wenn Sie eine Regel in ein Dokument verschieben, das nicht geladen wird, vergisst der Agent diese einfach. Wurde eine Regel in Referenzdokumente verschoben, schrumpfte der private Speicher auf einen Zeiger, anstatt vollständig zu verschwinden.

Wie geht man mit Widersprüchen um?

Die gesammelten Erinnerungen stimmen nicht überein. Lösen Sie Widersprüche nach Geltungsbereich, wo dies möglich ist, überschreiben Sie die veraltete Seite und legen Sie Meinungsverschiedenheiten hinsichtlich der Präferenz in einem expliziten, ungelösten Speicherbereich ab.

Prüfen Sie zunächst den Geltungsbereich. Ein Widerspruch betraf die Frage, wie Abhängigkeiten in einer zweiten Arbeitskopie eines Repositorys eingerichtet werden sollten: Zwei Personen hatten gegensätzliche Regeln verfasst. Beide waren in ihrem jeweiligen Repository zutreffend. Eine spätere Änderung an einer gemeinsam genutzten Funktion hatte die Frage inzwischen für beide geklärt, und es stellte sich heraus, dass die Erinnerung unseres intensivsten Nutzers veraltet war; daher sollte diese Regel ersetzt und nicht stillschweigend gelöscht werden.

Ersetzen Sie die alte Regel, überschreiben Sie sie niemals. Wenn sich eine gemeinsam genutzte Regel ändert, fügen Sie die neue Regel mit einem Datum hinzu und lassen Sie die alte lesbar, so wie ein Protokoll über eine Architekturentscheidung eine frühere Entscheidung ersetzt. Der nächste Prüfer kann so erkennen, was sich geändert hat und warum.

Behalten Sie einen ungelösten Punkt bei. Der zweite Widerspruch betraf die Frage, welches KI-Modell die Unteragenten verwenden sollten. Zwei Personen sprachen sich für ein Spitzenmodell für jeden Unteragenten aus; eine Person wählte die Modelle je nach Aufgabe aus. Die Abstimmung ergab zwei Stimmen für „diskutieren“ und zwei für „zustimmen“. Die Frage blieb absichtlich ungelöst, da es darum geht, wie viel jede Person bereit ist, auf eigene Rechnung auszugeben, und nicht um eine Tatsache der Codebasis. Dies bleibt in den privaten Regeln jeder einzelnen Person verankert.

Was die Ernte zutage brachte

Fünfzehn Promotions wurden von der ersten Überprüfungsseite angenommen: elf für unser Hauptprodukt-Repo (von denen zwei auch für das Spiele-Repo galten), drei für das „Shared Skills“-Plugin und eine zur Behebung eines Fehlers im eigenen Exporter von „The Harvest“. Siebzehn weitere wurden von der zweiten Seite angenommen: Fakten mit einem einzigen Autor, deren Weitergabe die Gruppe zustimmte, sowie zwei Cluster, die bei der ersten Zählung fälschlicherweise als Ein-Autor-Beiträge erfasst worden waren. Auf der zweiten Seite wurde ein Eintrag abgelehnt, drei wurden zur weiteren Diskussion oder zur Suche nach einem passenderen Ort zurückgestellt, und drei wurden zwar angenommen, erfordern jedoch Code oder eine Funktion anstelle einer Dokumentationszeile. Die Modellfrage blieb offen.

Der am häufigsten wiederholte Themenkomplex betraf Kommentare. Drei Autoren, von denen einer dies viermal notiert hatte, führten aus: Kommentare geben dauerhafte Fakten über den Code wieder; sie beschreiben niemals die Änderung selbst oder deren Entstehungsgeschichte. Ein Autor merkte an, dass Subagenten hierfür in der Regel verantwortlich sind.

Der umfassendste Punkt betraf den Nachweis. Vier der fünf Autoren hatten eine Variante des Grundsatzes „Erst überprüfen, dann behaupten; eine erfolglose Suche ist kein Beweis für das Nichtvorhandensein“ verfasst. Behauptungen von Gutachtern sind Hypothesen, und die Tatsache, dass ein Fehler nicht reproduziert werden kann, beweist nicht, dass er nicht auftreten kann. Dies kam einer gemeinsamen Hausregel des Teams am nächsten, und sie war nirgendwo schriftlich festgehalten.

Eine damit zusammenhängende Gruppe von Vorfällen, die von zwei Autoren beschrieben wurde, betraf einen veralteten Git-Status: einen lokalen Zweig, der weit hinter dem Remote-Zweig zurücklag, sowie eine Suche, die auf der Grundlage eines falschen Checkouts durchgeführt wurde. Jeder der fünf Vorfälle führte zu einer als sicher geltenden, falschen Behauptung, die ihren Weg in eine Commit-Meldung oder eine Pull-Request-Beschreibung fand.

Es wurden nicht nur fehlende Leitlinien, sondern auch fehlerhafte Leitlinien korrigiert. Bei drei Feststellungen handelte es sich um Aufforderungen zur „Niederstufung“ oder „Bearbeitung“ bereits vorhandener Leitlinien:

• In unseren gemeinsamen Richtlinien wurde den Bearbeitern mitgeteiltAGENTS.md, beilint:fix Änderungen an Lint-Regeln eine repo-weite Überprüfung durchzuführen. Drei Personen hatten unabhängig voneinander davor gewarnt: Das Repo ist im Ausgangszustand nicht Lint-konform, sodass eine repo-weite Korrektur Ihren Diff in nicht damit zusammenhängenden Formatierungsänderungen untergehen lässt.
• Eine gemeinsam genutzte Funktion, die angeblich im Falle eines Fehlersgh pr edit auf die API zurückgreift. Es tritt jedoch kein Fehler auf: Es wird eine nicht schwerwiegende Meldung ausgegeben, das Programm beendet sich mit dem Status 0 und der Pull-Request bleibt unverändert. Ein Fallback, der auf einen Fehler ausgelegt ist, der niemals auftritt, wird niemals ausgeführt. Drei Autoren waren in drei Repositories auf dieses Problem gestoßen.
• In einer bestehenden Warnung in unserer Agent-Dokumentation wurde ein Datenbankfehler als „harmlos“ bezeichnet, da er sofort zu einem Fehler führt. Drei Personen waren bei drei verschiedenen Tabellen darauf gestoßen. In einem Fall durchlief der Fehler die Überprüfung und die CI-Prüfung und führte erst zur Laufzeit zu einem Absturz.

Einige vereinbarte Regeln gehörten in eine automatische Prüfung. Die oben genannte Datenbankwarnung lässt sich automatisch überprüfen: Ein Test, der das Schema ausliest, würde die gesamte Klasse beenden, während die Dokumentation lediglich darauf hinweist. „Bearbeiten Sie die generierte Schemadatei niemals manuell“ wurde als zutreffend anerkannt und dennoch zurückgestellt, da eine textliche Festlegung nicht die richtige Durchsetzungsmethode ist. Zwei weitere vereinbarte Punkte waren bereits als Schritt-für-Schritt-Anleitungen verfasst, wodurch sie zu Fertigkeiten werden. Mehrere Punkte wurden aus der Abstimmung als Tickets statt als Dokumentation herausgenommen.

Eine Regel kann zwar als Standardverhalten gelten, muss aber dennoch schriftlich festgehalten werden. Zwei Personen hatten unabhängig voneinander geschrieben: „Niemals committen oder pushen, es sei denn, man wird dazu aufgefordert.“ Einer brachte es auf den Punkt: „Das Erstellen von Dateien ist keine Erlaubnis, diese zu committen.“ Jeder Mitarbeiter sollte sich ohnehin bereits so verhalten. Zwei Personen haben dies schriftlich festgehalten, weil es dennoch immer wieder vorkam – was ein Argument dafür ist, dies ausdrücklich festzuhalten.

Bei der Ernte wurde ein Fehler in der Ernte entdeckt. Jedes Bundle trug einen Versionsstempel, sodass die Überprüfung den Vergleich von Bundles verweigerte, die nach unterschiedlichen Erfassungsregeln erstellt worden waren. Der Stempel stammte aus der Version des Plugins, nicht aus der des Exporters. Alle fünf Bundles wurden mit byte-identischen Skripten erstellt und mit drei verschiedenen Versionen versehen. Die Sicherheitsabfrage würde bei einer tatsächlichen Regeländerung niemals ausgelöst werden, hingegen bei jeder nicht damit zusammenhängenden Plugin-Aktualisierung. Diese Korrektur war eine der fünfzehn.

Wie oft sollte man es ausführen?

Die erste Ernte ist die aufwendigste: monatelange private Notizen, die in einer einzigen, zeitlich begrenzten Sitzung gesichtet werden. Führen Sie danach bei regelmäßigen Team-Abstimmungen eine fünfminütige Schnellüberprüfung durch: Gibt es etwas Neues, das mehr als eine Person notiert hat?

Fünf Fehlermodi, die bei der Konstruktion zu berücksichtigen sind:

• Nur-Schreiben: Regeln werden übernommen, und niemand überprüft, ob sich das Verhalten des Agenten geändert hat.
• Veraltet und ohne Eigentümer: Eine gemeinsam genutzte Regel überdauert den Code, den sie beschreibt.
• „Promoted on n=1“: Die entschiedene Meinung einer einzelnen Person wird zur Teamregel, weil diese Person sie als Erste niedergeschrieben hat.
• Ein Dokument, das vier Arten von Inhalten enthält: allgemeine Richtlinien, Verfahren, Referenzinformationen und historische Hintergründe – alles in einer einzigen Datei, die niemand von Anfang bis Ende liest.
• So stark abstrahiert, dass sie nutzlos ist: Eine Regel, die so weit vom auslösenden Vorfall verallgemeinert wurde, dass sie dem Akteur nicht mehr sagt, was er tun soll.

Führen Sie einen manuell aus

Sie benötigen keine speziellen Werkzeuge. Unser Export bestand aus einem kleinen Skript, doch jeder Schritt lässt sich auch manuell ausführen:

1. Privater Export. Jede Person kopiert ihren „Auto-Memory“-Ordner (in Claude Code: ~/.claude/projects/<project>/memory/), ihre ~/.claude/CLAUDE.mdsowie alle persönlichen Fähigkeiten in einen eigenen Ordner pro Person.
2. Vor der Weitergabe bitte bereinigen. Jede Person löscht alles, was nicht weitergegeben werden darf: Zugangsdaten, Kundendaten, alles, was einen namentlich genannten Kollegen betrifft. Nichts wird versendet, ohne dass der Verfasser es zuvor gelesen hat.
3. Nach Bedeutung gruppieren. Ein Prüfer – sei es ein Mensch oder ein Bot – fasst Einträge zusammen, die denselben Inhalt mit anderen Worten ausdrücken, und hält fest, wer den jeweiligen Eintrag verfasst hat.
4. Zählen Sie die einzelnen Autoren. Zwei oder mehr unabhängige Autoren stellen einen Kandidaten dar. Fassen Sie die Rechner einer Person zusammen, lassen Sie gemeinsam genutzten Upstream-Text außer Acht und notieren Sie, welche Cluster auch ohne Ihren aktivsten Nutzer bestehen bleiben.
5. Klassifizieren und weiterleiten. Weisen Sie jedem Kandidaten die Bezeichnung „ADD“, „UPVOTE“, „DOWNVOTE“ oder „EDIT“ zu und ordnen Sie ihm anschließend anhand der obigen Routing-Tabelle ein Ziel zu.
6. Führen Sie Widersprüche separat auf. Lösen Sie diese, soweit möglich, anhand des Geltungsbereichs; lassen Sie den Rest ungelöst und weisen Sie darauf hin.
7. Lassen Sie die Anwesenden abstimmen. Tragen Sie die Vorschläge auf einer Seite und die Fakten eines einzelnen Verfassers auf einer zweiten Seite ein und treffen Sie gemeinsam eine Entscheidung.
8. Behandeln Sie jede Änderung als eigenständige PR gegenüber dem Repo, auf das sie sich bezieht. Halten Sie die Rohdaten-Bundles aus dem Hauptzweig fern.

Häufig gestellte Fragen

Was ist eine „Memory Harvest“?

Eine „Memory Harvest“ ist eine Teamübung für KI-Programmieragenten: Jeder Entwickler exportiert die Erinnerungen seines privaten Agenten sowie seine persönlichen Regeln; ein Prüfer fasst die Einträge aus den Exporten aller Beteiligten zu Clustern zusammen, und die Regeln, die mehrere Personen unabhängig voneinander verfasst haben, werden in gemeinsam genutzte Dateien wie oderCLAUDE.md überführtAGENTS.md. Dies ist der Wartungsschritt auf Teamebene im Rahmen des Context Engineering.

Wie viele Personen müssen zustimmen, bevor eine Regel in CLAUDE.md aufgenommen wird?

Wir ziehen zwei oder mehr unabhängige Autoren heran. Zählen Sie dabei einzelne Personen, nicht Einträge: Eine Person, die eine Regel dreimal wiederholt oder Inhalte von zwei Computern exportiert, gilt weiterhin als ein Autor. Zwei Personen, die denselben veröffentlichten Text kopiert haben, gelten ebenfalls nicht als unabhängig. Der Schwellenwert legt fest, was vorgeschlagen wird; das Team stimmt jedoch weiterhin über jede Beförderung ab.

Was gehört in ein Team – CLAUDE.md oder das persönliche Gedächtnis?

Es gilt grundsätzlich, dass alle Inhalte dieses Repos in das Projekt gehörenCLAUDE.md, da es automatisch geladen wird. Vorgehensweisen gehören in den Bereich „Skills“, Referenzdetails in die Dokumentation mit einem Verweis, und alles, was maschinell überprüft werden kann, gehört in eine Lint-Regel oder einen Test. Präferenzen hinsichtlich Ihrer eigenen Tools, Ihrer Maschine oder Ihres Budgets bleiben privat.

Sollten die Teamregeln in CLAUDE.md oder in AGENTS.md aufgeführt werden?

Regeln, die jedes KI-Tool befolgen sollte, werden hier eingefügtAGENTS.md; Claude-spezifische Anweisungen verbleiben hierCLAUDE.md. Claude Code kann diese AGENTS.mddirekt oder über einen Import@AGENTS.md lesen, sodass eine einzige Datei für alle von Ihrem Team verwendeten Tools ausreicht.

Was tun Sie, wenn sich die Erinnerungen zweier Entwickler widersprechen?

Prüfen Sie zunächst den Geltungsbereich: In verschiedenen Repositories können beide Varianten zutreffen, und möglicherweise wurde das Problem durch einen späteren Tool-Wechsel bereits gelöst. Sollte eine der beiden Varianten veraltet sein, ersetzen Sie diese, anstatt sie zu überschreiben. Handelt es sich bei der Diskrepanz um eine Frage der Präferenz und nicht um eine Tatsache der Codebasis, lassen Sie sie ungelöst und behalten Sie sie in den privaten Regeln der jeweiligen Person bei.

Wie oft sollte ein Team eine „Memory Harvest“ durchführen?

Führen Sie eine begrenzte Sitzung durch, um den Rückstand abzubauen, und führen Sie anschließend im Rahmen einer regelmäßigen Teamabstimmung eine fünfminütige Standbesprechung durch, um neue Kandidaten zu ermitteln. Die erste Runde ist die aufwendigste; danach sollte das Volumen gering sein.

Treffen Sie diese Entscheidung gemeinsam im Team

Bei einer „Memory Harvest“ entscheidet das Team, welche Regeln gemeinsam festgelegt werden; der Prüfer unterbreitet lediglich Vorschläge. Der Export, die Clusterbildung und die Zählung lassen sich vollständig automatisieren. Die Abstimmung hingegen kann und sollte nicht automatisiert werden. Welche Regeln für alle verbindlich sind, welche persönlich bleiben und welche Meinungsverschiedenheiten offen bleiben, entscheiden diejenigen, die damit leben müssen. Dies ist derselbe Punkt, den wir in dem Bericht „Exists, the room doesn’t“ hervorheben: Eine aggregierte Sichtweise ist erst dann sinnvoll, wenn die Verantwortlichen für die Korrekturen gemeinsam entscheiden.

Das ist eine Retrospektive mit unterschiedlichen Inputs. Als unsere KI-Agenten ihre eigenen Retrospektive-Punkte einreichten, stammten die Erkenntnisse aus ihren Sitzungen. Dieses Mal stammten sie aus unseren eigenen privaten Notizen, und der Raum übernahm dieselbe Aufgabe: das Muster erkennen, die Ebene auswählen und jedem Punkt einen Verantwortlichen zuweisen. Falls Ihr Team bereits regelmäßige Retrospektiven durchführt, lässt sich eine „Memory Harvest“ gut als ein Tagesordnungspunkt einbauen. Die vollständige Vorgehensweise finden Sie in unserem Leitfaden zu Retrospektiven mit KI-Agenten.

Führen Sie eine eigene Ernte durch oder sind Sie der Meinung, dass unser Schwellenwert falsch ist? Teilen Sie uns dies bitte mit: ai-discussion@teamretro.com.