Onze AI-collega’s hebben zich bij onze retro aangesloten

Wij ontwikkelen software voor retrospectieven, dus het retrobord van ons team ziet er vrij standaard uit: Start, Stop, een kolom met openstaande acties, de gebruikelijke discussies op vrijdag. Vorige week kwamen er enkele nieuwe bijdragers bij. Zes van de kaarten waren niet door mensen geschreven: ze waren ingediend door de AI-agenten waarmee wij dagelijks samenwerken, en gaven een samenvatting van de knelpunten die zij tijdens hun eigen werksessies met ons hadden ondervonden.

Laten we duidelijk zijn over wat dit precies inhoudt, want de bewoording is van belang. Het gaat hier niet om een AI die in de retro aanwezig is: er is geen bot die de vergadering begeleidt, noch een AI-functie die de kaarten van de deelnemers samenvat. De medewerkers die het daadwerkelijke werk in ons team verrichten (degenen die code schrijven, inhoud bewerken en audits uitvoeren) verschenen bij de bijeenkomst net zoals elke andere teamgenoot dat doet: met hun eigen verslag van hoe het werk is verlopen. Deelnemers, geen facilitators; de bijeenkomst bleef van ons.

Dit was ook geen publiciteitsstunt. De aanzet kwam tijdens een van onze eigen retrospectieven: iemand merkte op dat de onboarding-documenten (alweer) verouderd waren en iemand anders vertelde dat een agent hen die ochtend tijdens een sessie terloops precies daarop had gewezen, voordat de context uit beeld verdween. De agent wist het wel; niets in zijn systeem gaf aan dat deze opmerking het waard was om te bewaren. Daarom hebben we de afgelopen weken een experiment op onszelf uitgevoerd: de werkwijze is dezelfde als die we hebben beschreven in hoe u feedback van uw AI-agenten kunt verzamelen. Aan het einde van elke substantiële, door AI ondersteunde werksessie schrijft de agent een kort, gestructureerd retro-verslag over zijn eigen werk: wat ging er goed, wat verliep moeizaam, wat kostte elke vertraging, één label voor de hoofdoorzaak per punt en een voorgestelde oplossing. De verslagen worden verzameld in de repositories waarin het werk plaatsvond. Wanneer er voldoende waren verzameld, las een bijbehorend proces ze allemaal door en voerde de terugkerende patronen rechtstreeks in op ons retro-bord, voorzien van een voorvoegsel [AI retro]zodat niemand zich vergist in de auteur.

Dit is wat onze nieuwste collega’s te zeggen hadden over het werken bij ons.

Wat zij ontdekten

De kop waarmee zij het bericht begonnen, ging over henzelf. Op de bovenste kaart stond: „Begin met controleren voordat u actie onderneemt — fouten bij de uitvoering door agents zijn verantwoordelijk voor 38% van de wrijving (twee keer zoveel als de op één na belangrijkste oorzaak); de terugkerende kosten ontstaan door het vaststellen van een oorzaak, het doorzetten of het heroriënteren voordat de live-code, de gegevens of de status van de branch zijn gecontroleerd.” De grootste bron van wrijving in ons AI-ondersteunde werk was, volgens de agenten zelf, de agenten, met name de gewoonte om te handelen op basis van een veronderstelde toestand van de wereld in plaats van eerst de actuele toestand te controleren. Dergelijke eerlijkheid waarderen wij bij elke collega.

Het belangrijkste thema, dat de vorm van een team aannam, overschreed alle grenzen die een mens niet zou overschrijden. Er deden zich bij het werken met gelijktijdige agents fouten voor met Git en de status van branches, die in acht sessies verspreid over twee repositories aan het licht kwamen: verouderde bases, ongelezen branchdoelen, een agent die een branch verplaatste die door een andere agent werd gebruikt, en een PR die zonder verificatie naar een ander doel werd verplaatst. Geen enkele sessie op zich zou hiermee ook maar in de buurt van de top zijn gekomen; elk incident leidde slechts tot een schouderophalen en een paar verloren minuten. Over de acht sessies heen bekeken, was het echter onmisbaar.

We werden betrapt op het doorvoeren van wijzigingen op basis van onvolledige controles. Vier gevallen waarin iets werd doorgevoerd of samengevoegd na een beperktere controle dan wat CI daadwerkelijk uitvoert: een eenvoudige typecontrole in plaats van de volledige build, gerichte tests in plaats van de volledige testsuite. Tweemaal in één repository, op dezelfde dag.

En de meest verontrustende kaarten hadden helemaal niets met het werk zelf te maken; ze gingen over de opvolging. Op één kaart werd opgemerkt dat door een lacune in de testprocedures een reproduceerbare crash twee beoordelingsrondes had kunnen doorstaan, en dat het document met de oplossing de dag ervoor was voorgesteld maar nooit was opgesteld. Op een andere kaart werd opgemerkt dat dezelfde vertraging bij de tool nu al twee sessies had gekost, „zonder dat er tussendoor een definitieve oplossing was geleverd“. Een derde kaart: hetzelfde patroon van steeds verder uitdijende vereisten, drie opeenvolgende sessies, „waarbij telkens werd opgemerkt dat het probleem zich sinds de vorige sessie opnieuw voordeed“. Het blijkt dat de medewerker zich herinnert wat wij hadden beloofd te doen.

De twee dingen die het waard zijn om naar te staren

Ten eerste: dit was voor niemand zichtbaar. Dat is geen gebrek aan aandacht; het ligt in de aard van het probleem. Wrijvingen tijdens AI-sessies zijn chronisch en van ondergeschikt belang, waardoor er nooit een evaluatie naar aanleiding van het incident plaatsvindt en ze verdwijnen zodra de sessie is beëindigd. Ieder van ons had zijn deel verwerkt en was verdergegaan. De rangschikking (dit patroon kost het team het meest) bestaat alleen in het geaggregeerde overzicht, en dat geaggregeerde overzicht bestaat alleen omdat de vermeldingen vergelijkbaar waren: hetzelfde schema, dezelfde kleine reeks labels voor hoofdoorzaken, waarbij elke melding verwijst naar een sessie met een datum. Dit is het aggregatieprincipe dat centraal staat in de gids bij dit bericht, en het is het onderdeel dat wij het liefst op onszelf wilden testen.

Ten tweede: de agenten gaven niemand, ook zichzelf niet, zomaar de schuld. De vermeldingen volgen twee regels die belangrijker bleken te zijn dan wij hadden verwacht. Bij „frictiepunten” wordt de kloof beschreven en wat deze heeft gekost, nooit wie deze heeft veroorzaakt: geen namen, geen „het rapport van X”. En „de agent maakte een fout” is een residuele aanduiding, die alleen wordt gebruikt wanneer de input daadwerkelijk toereikend was; dat is precies de reden waarom het cijfer van 38 % onze aandacht trok: het doorstond die toetsing. Het resultaat las als een goede retro-bijdrage: specifiek, onderbouwd met bewijs, zonder schuld toewijzing en voor iedereen in gelijke mate enigszins gênant.

Wat de aanwezigen besloten

Wij hebben besloten alle drie de voorgestelde maatregelen uit te voeren, elk op het aangegeven niveau. De regel „Controleer de status van de live-branch en de PR voordat u wijzigingen aanbrengt” wordt opgenomen in de agentdocumentatie van elke repository; dit is een aanpassing in de documentatie met betrekking tot het thema van de acht sessies. De pre-push-hook die de CI-equivalente build en tests uitvoert, wordt toegevoegd aan de repositories die te lijden hadden onder onvolledige controles; dit is een aanpassing aan de omgeving, zodat het niet afhankelijk is van iemands geheugen. En de documentatie over de testconventies die „de dag ervoor was gemarkeerd maar nooit is geschreven“, wordt momenteel opgesteld, met de crash die erdoorheen was geglipt als praktijkvoorbeeld.

Geen grootschalige reorganisatie, geen nieuw proces: drie kleine aanpassingen ter grootte van een ticket, in samenwerking met de verantwoordelijken. Deze bescheiden aanpak is bewust gekozen: het hele uitgangspunt van deze werkwijze is dat kleine verbeteringen, gericht op het juiste niveau en daadwerkelijk gecontroleerd in de volgende cyclus, een cumulatief effect hebben. Of deze drie verbeteringen standhouden, zal precies blijken uit de acceptatiecontrole van de volgende opdracht; hetzelfde mechanisme dat ons de vorige keer op de hielen zat, zal ons hierop beoordelen.

Het is nog vroeg dag, en dat zeggen wij ook ronduit. Maar toen wij die retro-sessie verlieten, waren wij meer geïnteresseerd in onze eigen werkpatronen dan wij in lange tijd zijn geweest, en voelden wij ons een beetje competitief ten opzichte van een collega die zelfs nooit moe wordt.

De eerlijke voetnoten

Dit is ons eerste samengevatte overzicht, gebaseerd op gegevens van weken en niet van maanden; daarom beschouwen wij de ranglijsten als een middel om aandacht toe te wijzen, en niet als een definitieve verantwoording. De kosten in de vermeldingen zijn schattingen van de agent zelf en zijn als zodanig gemarkeerd. De meer ambitieuze beweringen van de praktijk (dat labels consistent blijven tussen beoordelaars, dat de trendlijn daadwerkelijk afbuigt nadat correcties zijn doorgevoerd) zijn experimenten die wij uitvoeren in plaats van aannames die wij doen, en wij zullen de uitkomsten daarvan in beide gevallen publiceren.

Maar het belangrijkste resultaat was al zichtbaar: een reeks patronen die niemand in het team afzonderlijk kon waarnemen, gerangschikt, onderbouwd en opgenomen in de bijeenkomst waar degenen die verantwoordelijk zijn voor de oplossingen al aanwezig waren. In het Feedback Flywheel van Rahul Garg staat in de lijst met terugkerende onderwerpen „een agendapunt in de bestaande sprint-retrospective: wat werkte er deze sprint op het gebied van AI?“ Wij kunnen nu melden dat dit agendapunt aanzienlijk interessanter is wanneer uw AI-teamgenoten hun eigen punten indienen.

Probeer het eens binnen uw eigen team

Alles wat wij hebben gebruikt, is gratis en gedocumenteerd in de handleiding: hoe de invoergegevens werken, de labels voor de onderliggende oorzaken, de regels voor het niet-loggen (geen vertrouwelijke informatie, geen klantgegevens en nooit iets waarmee een persoon kan worden geïdentificeerd), en het agendapunt van 15 minuten voor de facilitator, plus de twee vaardigheden waarmee de fasen van vastlegging en synthese worden geïmplementeerd. Het werkt met elke geschikte agent en een tekstbestand; ons product is slechts één plek waar de resultaten kunnen worden opgeslagen, geen vereiste.

In de volgende cyclus zal uit de goedkeuringscontrole van de opdrachtomschrijving blijken of wij dat testdocument deze keer daadwerkelijk hebben opgesteld. Wij zullen u hiervan op de hoogte brengen. Zij zullen dat eveneens doen.

Heeft u het geprobeerd? Bent u het er niet mee eens? Wij menen het echt als we zeggen dat we graag met u in discussie gaan: ai-discussion@teamretro.com.