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 Wortwahl 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 (d. h. diejenigen, die Code schreiben, Inhalte bearbeiten und Audits durchführen), nahmen an der Zeremonie teil, wie es jeder Teamkollege tun würde: mit ihrem eigenen Bericht darüber, wie die Arbeit verlaufen ist. Teilnehmer, keine Moderatoren; das Meeting blieb in unserer Hand.

Das war auch kein PR-Gag. Der Anstoß kam in einer unserer eigenen Retrospektiven: Jemand merkte an, dass die Einführungsunterlagen (wieder einmal) veraltet seien, und jemand anderes erwähnte, dass ein Agent genau das an jenem Morgen mitten in einer Sitzung beiläufig angemerkt 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-unterstützten Arbeitssitzung verfasst der Agent einen kurzen, strukturierten Retrospektive-Eintrag zu seiner eigenen Arbeit: Was lief gut, was zog sich in die Länge, was hat jede Verzögerung gekostet, eine Ursache pro Punkt sowie einen Lösungsvorschlag. Die Einträge sammeln sich in den Repositories an, 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 mit einem Präfix, [AI retro]damit niemand den Verfasser verwechselt.

Hier erfahren Sie, was unsere neuesten Teamkollegen ü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 Maßnahme vorangetrieben 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 Repos 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 lediglich ein Achselzucken und ein paar verlorene Minuten. Über acht Sitzungen hinweg betrachtet war es jedoch unübersehbar.

Es ist uns aufgefallen, dass wir auf der Grundlage unvollständiger Prüfungen 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 eigentlich üblich ist: eine reine Typprüfung anstelle des vollständigen Builds, gezielte Tests anstelle der gesamten Testsuite. Zweimal in einem Repository, am selben Tag.

Und die unangenehmsten Karten betrafen gar nicht die eigentliche Arbeit; es ging vielmehr um 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 Fehlerbehebung am Vortag vorgeschlagen, aber nie verfasst worden war. In einer anderen Karte wurde darauf hingewiesen, dass dieselbe Verzögerung bei der Tool-Implementierung 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 es sich um eine Wiederholung des Vorfalls aus der letzten Sitzung handelte“. 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 Versäumnis hinsichtlich 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 Ende der Sitzung in Luft auflösen. Jeder von uns hatte seinen Anteil davon hingenommen und war weitergegangen. Die Rangfolge (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 jede Meldung 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 Ermittler 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 deren Kosten beschrieben, niemals jedoch, wer sie verursacht hat: keine Namen, kein „Schriftsatz von X“. Und „der Makler hat einen Fehler gemacht“ ist eine Rest-Kennzeichnung, die nur verwendet wird, wenn die Eingaben tatsächlich angemessen waren – und 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 Repositorys 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 auf Umgebungsebene, 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, deren Verantwortliche feststehen. 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 wir waren ein wenig im Wettstreit mit einem Kollegen, der gar nicht müde wird.

Die ehrlichen Fußnoten

Dies ist unser erster zusammengefasster Bericht, der auf Daten aus mehreren Wochen – nicht Monaten – basiert; daher betrachten wir die Ranglisten als Orientierungshilfe und nicht als endgültige Bilanz. Die in den Einträgen angegebenen Kosten sind Schätzungen des Agenten selbst und als solche gekennzeichnet. Die weitergehenden Behauptungen der Praxis (dass die Bewertungen zwischen den Bewertern konsistent bleiben, 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, wurden priorisiert, 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 Bereich 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 Regeln für das „Never-Log“-Verfahren (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 Fähigkeiten, 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.