Iteratiesnelheid: wat snelle teams echt meten

De snelste iteratieloops ter wereld zitten niet in software.

Sinds 2022 is de ontwikkeling van drones en tegenmaatregelen in de Russisch-Oekraïense oorlog teruggebracht tot een cyclus die defensiejournalisten en de fabrikanten zelf in weken beschrijven. Aan het front duikt een stoor- of onderscheppingstechniek op. Ontwerpen worden daarop aangepast. Het aangepaste ontwerp stuit op een nieuwe tegenmaatregel en de lus begint opnieuw. Reguliere defensie-inkoop is daarentegen georganiseerd in jaren: eisen, aanbesteding, integratie, acceptatie.

Niet omdat iemand snelheid tot kernwaarde heeft verheven of een transformatieprogramma heeft opgetuigd. Ze zijn snel omdat de feedback direct en ondubbelzinnig is, en omdat de prijs van traagheid absoluut is. Een ontwerp overleeft het contact of niet, en het antwoord komt binnen dagen terug. Niemand hoeft een dashboard te bouwen om te achterhalen wat het werd.

Dat is belangrijk om expliciet te zeggen, want daar houdt de vergelijking ook op. Dit is een oorlog waarin mensen omkomen, en de druk achter die korte cycli is er een die geen enkele softwareorganisatie heeft, wil of zou moeten nabootsen. De bruikbare observatie is smaller en werkt juist andersom: waar feedback snel en ondubbelzinnig is, regelt iteratiesnelheid zichzelf. Overal daarbuiten moet je die bewust bouwen — en wat de meeste teams missen is geen urgentie, maar de lus.

De tweede plek waar dit nu zichtbaar is, ligt een stuk dichterbij. Assistenten, reviewbots en testgeneratoren veranderen maandelijks, en de werkwijzen eromheen veranderen mee. Elk team dat de afgelopen twee jaar een AI-codetool invoerde, voert een experiment uit — of iemand het zo behandelt of niet.

Het verschil tussen teams die er iets uit halen en teams die dat niet doen, zit zelden in de tool. Het zit in de vraag of iemand kan zien wát er veranderde. Dat begint bij weten wat je bijhoudt vóórdat de code er is; we zetten de adoptiesignalen die de moeite waard zijn op een rij in AI-adoptie en toolgebruik meten.

Dat is het eigenlijke probleem. De prijs van een trage iteratie in software is nooit absoluut en zelden direct. Een release schuift een kwartaal op. Een concurrent levert iets vergelijkbaars eerder. Een ontwerpkeuze uit maart blijkt in september verkeerd, en inmiddels hangen er vier dingen aan. Geen enkel moment meldt zich als hét moment waarop het misging, dus niemand escaleert en er verandert niets.

Teams compenseren dat door elkaar te vragen hoe het voelt. Het voelt trager dan vorig jaar. Het voelt alsof reviews langer duren. Soms klopt dat, en soms is het enige dat werkelijk veranderde dat één wachtrij langer werd terwijl de rest precies hetzelfde bleef. Gevoel is een prima begin van een gesprek en een slecht einde ervan.

Het valt uiteen in vier meetbare dingen, en die zijn het scheiden waard omdat ze onafhankelijk van elkaar stuklopen.

De eerste twee zijn DORA-metrics, en als het verschil tussen de derde en de tweede niet meteen duidelijk is, is dat tien minuten waard: cycle time en lead time beantwoorden verschillende vragen en worden voortdurend door elkaar gehaald. Voor waar die vier vandaan komen en wat het onderzoek erachter wel en niet zegt, begin bij wat DORA metrics zijn en waarom ze belangrijk zijn.

Een team dat twee keer zo vaak levert en twee keer zo vaak productie omlegt, heeft niets verbeterd; het heeft de kosten alleen naar een minder zichtbare plek verschoven. Iteratiesnelheid betekent pas iets als je haar naast change failure rate en hersteltijd leest. Snel én stabiel is de combinatie die teams onderscheidt, en het is ook de combinatie die zich moeilijk laat faken — je kunt elk getal apart bespelen, maar allebei tegelijk bespelen komt neer op het werk gewoon goed doen.

Daar is Agile Analytics voor gebouwd. Het koppelt aan de systemen waar het werk toch al doorheen loopt — je ticketsysteem, je repositories, je pipelines — zodat lead time, deployment frequency en cycle time komen uit gebeurtenissen die echt hebben plaatsgevonden, en niet uit wat iemand zich in een retro herinnert. Sprint Insights laat zien waar de tijd binnen een sprint bleef, inclusief het werk dat nooit op het bord terechtkwam.

Wat dat oplevert is geen getal om naar boven te rapporteren. Het is een eigen lus: verander één ding — het reviewbeleid, de omvang van een batch, wie er piket heeft, of AI-ondersteuning aanstaat — en kijk of de lead time beweegt. Houd de verandering, of draai hem terug. Dat is hetzelfde mechanisme dat de snelle domeinen hebben, nagebouwd voor een domein waarin de werkelijkheid niet uit zichzelf terugmeldt.

Iteratiesnelheid is geen deugd die je aanneemt. Het is de uitkomst van een feedbacklus die kort genoeg is om van te leren, en de eerste stap is kunnen zien welke lus je nu hebt.