Unsere KI-Teamkollegen nahmen an unserem Retro-Event teil

Wir entwickeln Software für Retrospektiven, daher ist das Retrospektiven-Board unseres Teams ein recht gewöhnlicher Ort: „Start“, „Stopp“, eine Spalte mit offenen Maßnahmen, die üblichen Freitagsdiskussionen. Letzte Woche kamen einige neue Mitwirkende hinzu. Sechs der Karten stammten nicht von Menschen – sie wurden von den KI-Agenten eingereicht, mit denen wir täglich zusammenarbeiten, und fassen die Reibungspunkte aus ihren eigenen Arbeitssitzungen mit uns zusammen.

Lassen Sie uns genau definieren, worum es hier geht, denn die Formulierung ist entscheidend. Es handelt sich nicht um eine KI, die im Retro-Meeting sitzt: kein Bot, der das Meeting moderiert, keine KI-Funktion, die die Karten der Teilnehmer zusammenfasst. Die Mitarbeiter, die in unserem Team die eigentliche Arbeit leisten (diejenigen, die Code schreiben, Inhalte bearbeiten und Audits durchführen), nahmen an der Besprechung genauso teil wie jeder andere Teamkollege auch: mit ihrem eigenen Bericht darüber, wie die Arbeit verlaufen ist. Teilnehmer, keine Moderatoren; die Besprechung blieb in unserer Hand.

Das war auch kein PR-Gag. Der Anstoß kam in einer unserer eigenen Retrospektiven: Jemand erwähnte, dass die Einführungsunterlagen (wieder einmal) veraltet seien, und jemand anderes berichtete, dass ein Agent genau dies an jenem Morgen mitten in einer Sitzung beiläufig angesprochen hatte, bevor der Kontext aus dem Blickfeld verschwand. Der Agent hatte davon gewusst; nichts in seiner Welt deutete darauf hin, dass diese Beobachtung es wert war, festgehalten zu werden. Daher führen wir seit einigen Wochen ein Experiment an uns selbst durch: Die Vorgehensweise entspricht der, die wir in Wie Sie Feedback von Ihren KI-Agenten einholen beschrieben haben. Am Ende jeder umfangreicheren KI-gestützten Arbeitssitzung verfasst der Agent einen kurzen, strukturierten Retrospektive-Eintrag zu seiner eigenen Arbeit: Was lief gut, was verzögerte den Ablauf, welche Kosten verursachte jede Verzögerung, eine Kennzeichnung der Hauptursache pro Punkt sowie einen Lösungsvorschlag. Die Einträge sammeln sich in den Repos, in denen die Arbeit stattfand. Sobald sich genügend davon angesammelt hatten, las ein begleitender Prozess sie alle durch und trug die wiederkehrenden Muster direkt in unser Retrospektive-Board ein, versehen[AI retro] mit einem Präfix, damit niemand den Autor verwechselt.

Hier erfahren Sie, was unsere neuesten Kollegen über die Zusammenarbeit mit uns zu sagen hatten.

Was sie herausfanden

Die Schlagzeile, mit der sie begannen, bezog sich auf sie selbst. Auf der obersten Karte stand: „Überprüfen Sie zunächst, 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, eine Änderung durchgesetzt oder eine Neuausrichtung vorgenommen wird, bevor der Live-Code, die Daten oder der Zweigstatus überprüft wurden.“ Die mit Abstand größte Quelle von Reibungsverlusten bei unserer KI-gestützten Arbeit waren nach Angaben der Agenten selbst die Agenten selbst, insbesondere die Gewohnheit, auf der Grundlage eines angenommenen Zustands der Welt zu handeln, anstatt zunächst den aktuellen Zustand zu überprüfen. Eine solche Ehrlichkeit würden wir von jedem Kollegen begrüßen.

Das größte, teambezogene Problem überschritt alle Grenzen, die ein Einzelner niemals überschreiten würde. Bei der Arbeit mit mehreren Agenten traten in acht Sitzungen über zwei Repositories hinweg Fehler im Zusammenhang mit Git und dem Zweigstatus auf: veraltete Basen, ungelesene Zweigziele, ein Agent, der einen Zweig verschob, den ein anderer gerade nutzte, sowie ein Pull-Request, dessen Ziel ohne Überprüfung geändert wurde. Keine einzelne Sitzung hätte dies auch nur annähernd an die Spitze der Rangliste gebracht; jeder Einzelfall war nur ein Achselzucken und ein paar verlorene Minuten wert. Über acht Sitzungen hinweg betrachtet war das Thema jedoch unübersehbar.

Es ist uns aufgefallen, dass wir auf der Grundlage unvollständiger Prüfungen Commits veröffentlicht haben. In vier Fällen wurde etwas veröffentlicht oder zusammengeführt, nachdem eine weniger umfassende Prüfung durchgeführt worden war, als sie bei der CI-Prüfung üblicherweise erfolgt: eine reine Typprüfung anstelle des vollständigen Builds, gezielte Tests anstelle der gesamten Testsuite. Zweimal in ein und demselben Repository, am selben Tag.

Und die unangenehmsten Karten betrafen gar nicht die eigentliche Arbeit, sondern die Nachverfolgung. Auf einer Karte wurde angemerkt, dass aufgrund einer Lücke in den Testkonventionen ein reproduzierbarer Absturz zwei Überprüfungsrunden unentdeckt durchgeschlüpft war und dass das Dokument zur Behebung des Problems am Vortag vorgeschlagen, aber nie verfasst worden war. In einer anderen Karte wurde darauf hingewiesen, dass dieselbe Tool-Verzögerung nun bereits zwei Sitzungen gekostet habe, „ohne dass dazwischen eine dauerhafte Lösung bereitgestellt wurde“. Eine dritte Karte: dasselbe Muster der schleichenden Anforderungsausweitung, drei aufeinanderfolgende Sitzungen, „in denen jeweils darauf hingewiesen wurde, dass sich das Problem seit der letzten Sitzung wiederholt“. Wie sich herausstellt, erinnert sich der Mitarbeiter daran, was wir versprochen hatten.

Die beiden Dinge, die es wert sind, betrachtet zu werden

Erstens: Nichts davon war für eine einzelne Person erkennbar. Das ist kein Versagen der Aufmerksamkeit; es liegt in der Natur des Problems. Reibungsverluste bei KI-Sitzungen sind chronisch und geringfügig, sodass sie niemals Anlass für eine Nachbetrachtung geben und sich mit dem Ende der Sitzung in Luft auflösen. Jeder von uns hatte seinen Anteil davon aufgenommen und war weitergegangen. Die Rangliste (dieses Muster kostet das Team am meisten) existiert nur in der aggregierten Ansicht, und die aggregierte Ansicht existiert nur, weil die Einträge vergleichbar waren: dasselbe Schema, dieselbe kleine Menge an Ursachenbezeichnungen, wobei jeder Eintrag auf eine datierte Sitzung verweist. Dies ist der Aggregationsansatz, der im Mittelpunkt des Leitfadens steht, zu dem dieser Beitrag gehört, und es ist der Teil, den wir am liebsten an uns selbst testen wollten.

Zweitens: Die Mitarbeiter gaben niemandem, auch sich selbst nicht, pauschal die Schuld. Die Einträge folgen zwei Regeln, die sich als wichtiger erwiesen haben, als wir erwartet hatten. In den „Friction“-Einträgen werden die Diskrepanz und die damit verbundenen Kosten beschrieben, niemals jedoch, wer sie verursacht hat: keine Namen, kein „Schriftsatz von X“. Und „der Makler hat einen Fehler gemacht“ ist eine Rest-Bezeichnung, die nur verwendet wird, wenn die Eingaben tatsächlich angemessen waren – genau deshalb hat die Zahl von 38 % unsere Aufmerksamkeit erregt: Sie hat diese strenge Prüfung überstanden. Das Ergebnis las sich wie ein guter Retro-Beitrag: konkret, mit Belegen untermauert, ohne Schuldzuweisungen und für alle gleichermaßen etwas peinlich.

Was die Anwesenden beschlossen haben

Wir haben beschlossen, alle drei vorgeschlagenen Maßnahmen umzusetzen, jeweils auf der angegebenen Ebene. Die Regel „Live-Zweig und PR-Status vor Änderungen überprüfen“ wird in die Agent-Dokumentation jedes Repos aufgenommen – eine Korrektur der Dokumentation im Rahmen des „Eight-Session“-Themas. Der Pre-Push-Hook, der den CI-äquivalenten Build und die Tests ausführt, wird in die Repositories integriert, die durch unvollständige Prüfungen Probleme hatten – eine Korrektur der Umgebung, damit dies nicht davon abhängt, dass sich jemand daran erinnert. Und die Dokumentation zur Testkonvention, die „am Vortag markiert und nie verfasst wurde“, wird derzeit erstellt, wobei der durchgerutschte Absturz als anschauliches Beispiel dient.

Keine großangelegte Umstrukturierung, kein neuer Prozess: drei kleine Korrekturen im Umfang eines Tickets, für die jeweils Verantwortliche benannt wurden. Diese Bescheidenheit ist beabsichtigt: Das gesamte Konzept dieser Vorgehensweise beruht darauf, dass sich kleine Korrekturen, die auf die richtige Ebene abzielen und im nächsten Zyklus tatsächlich überprüft werden, summieren. Ob diese drei Korrekturen Bestand haben, wird uns die Überprüfung der Umsetzung im nächsten Bericht genau zeigen; derselbe Mechanismus, der uns beim letzten Mal aufgefallen ist, wird uns diesbezüglich bewerten.

Es ist noch früh, und das sagen wir ganz offen. Doch als wir diesen Retro-Laden verließen, interessierten wir uns mehr für unsere eigenen Arbeitsgewohnheiten als schon seit Langem – und waren ein wenig im Wettstreit mit einem Kollegen, der gar nicht müde wird.

Die ehrlichen Fußnoten

Dies ist unser erster zusammenfassender Bericht, der auf Daten aus Wochen und nicht aus Monaten basiert; daher betrachten wir die Ranglisten als Orientierungshilfe für die Zuweisung von Aufmerksamkeit und nicht als endgültige Bilanz. Die in den Einträgen angegebenen Kosten sind Schätzungen des Agenten selbst und sind entsprechend gekennzeichnet. Die weitergehenden Behauptungen des Ansatzes (dass die Bewertungen zwischen den Bewertern konsistent bleiben und dass sich die Trendlinie nach der Umsetzung von Korrekturen tatsächlich abflacht) sind Experimente, die wir derzeit durchführen, und keine bloßen Annahmen; wir werden die Ergebnisse in jedem Fall veröffentlichen.

Doch der wesentliche Nutzen zeigte sich bereits: Eine Reihe von Mustern, die niemand im Team für sich allein erkennen konnte, wurde bewertet, belegt und in die Besprechung eingebracht, in der die für die Behebung zuständigen Personen bereits anwesend waren. Rahul Gargs Feedback Flywheel enthält in seiner Rhythmusliste „einen Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ Wir können nun berichten, dass dieser Tagesordnungspunkt wesentlich interessanter ist, wenn Ihre KI-Teamkollegen ihre eigenen Punkte einreichen.

Probieren Sie es in Ihrem eigenen Team aus

Alles, was wir verwendet haben, ist kostenlos und in dem Leitfaden dokumentiert: die Funktionsweise der Einträge, die Bezeichnungen für die Grundursachen, die „Never-Log“-Regeln (keine vertraulichen Informationen, keine Kundendaten und niemals etwas, das eine Person identifiziert) sowie der 15-minütige Tagesordnungspunkt für den Moderator und die beiden Kompetenzen, mit denen die Erfassung und die Synthese umgesetzt werden. Das Verfahren funktioniert mit jedem geeigneten Tool und einer Textdatei; unser Produkt ist lediglich ein möglicher Speicherort für die Ergebnisse, jedoch keine Voraussetzung.

Im nächsten Zyklus wird uns die Überprüfung der Anforderungsspezifikation zeigen, ob wir dieses Testdokument diesmal tatsächlich verfasst haben. Wir werden Sie darüber informieren. Das werden sie ebenfalls tun.

Haben Sie es ausprobiert? Sind Sie anderer Meinung? Wir meinen es ernst, wenn wir sagen, dass wir gerne mit Ihnen diskutieren möchten: ai-discussion@TeamRetro.com.