Is snelheid een bruikbare maatstaf? Ons oordeel

Ja, binnen het team, maar schadelijk daarbuiten. Velocity is een input voor prognoses waarop het team zich baseert; zodra het een streefcijfer wordt of wordt gebruikt voor vergelijkingen tussen teams, wordt het opgeblazen en verliest het zijn betekenis. DORA heeft het bewust buiten de leveringsstatistieken gelaten.

Vrijwel iedereen in het debat is het erover eens dat ‘velocity’ nooit uit het team mag verdwijnen — en toch laat vrijwel elke organisatie dit toch gebeuren. Die kloof vormt de kern van de discussie. Deze maatstaf is voor één taak daadwerkelijk nuttig en voor de overige taken onmiskenbaar schadelijk; het oordeel moet dus gemengd zijn.

Het argument dat snelheid nuttig is

Binnen het team levert velocity daadwerkelijk resultaat op. Het stelt u in staat om prognoses te maken: deel de resterende scope door het recente gemiddelde van het team en u krijgt een ruw aantal sprints dat u kunt opleveren. Het stelt u in staat om een realistische sprintomvang te bepalen: selecteer stories totdat deze samen ongeveer tachtig tot negentig procent van de recente gemiddelde omvang bedragen, zodat er ruimte overblijft voor onvoorziene zaken. En het signaleert daadwerkelijke veranderingen — een daling van dertig procent is een signaal dat een gesprek rechtvaardigt, geen beschuldiging.

De wens van het management om ‘velocity’ als maatstaf te hanteren, is eveneens legitiem en verdient het om op een eerlijke manier te worden toegelicht. Leidinggevenden zijn verantwoordelijk voor de oplevering en willen daar inzicht in hebben. „Als we het team op geen enkele manier kunnen meten, hoe weten we dan of het presteert?” is een redelijke vraag, geen uitspraak van een schurk. Het probleem ligt niet bij de wens zelf. Het probleem is dat velocity hiervoor het verkeerde instrument is.

Het argument dat snelheid een valstrik is

Als u de snelheid naar buiten richt, verloopt het proces op voorspelbare wijze. Stel het als doel — „verhoog de snelheid dit kwartaal met twintig procent“ — en het team voldoet daaraan door hetzelfde werk omhoog bij te stellen in plaats van er meer van te doen. Verander een paar „drieën“ in „vijven“ en het cijfer stijgt zonder dat de output daadwerkelijk toeneemt. Dit is de wet van Goodhart in een cyclus van twee weken, en het is geen hypothetisch scenario: zelfs Mike Cohn, de belangrijkste voorstander van story points, geeft toe dat de geringste aanwijzing dat snelheden zullen worden vergeleken, leidt tot een geleidelijke maar consistente inflatie van het aantal punten.

Een vergelijking tussen teams is nog problematischer, omdat deze weliswaar rigoureus lijkt, maar in feite zinloos is. Twee teams die dezelfde backlog inschatten, komen tot verschillende cijfers omdat zij hun schattingen afstemmen op verschillende referentieverhalen — dat is nu juist de essentie van relatieve schatting. Het berekenen van gemiddelden of het rangschikken van deze cijfers verstoort de afstemming van beide teams, louter om een dashboard te voeden. Een duidelijk teken dat een organisatie dit verkeerd aanpakt, is wanneer een leidinggevende zijn of haar teams persoonlijk moet beschermen tegen ‘velocity’ als KPI — een oplossing die precies zo lang werkt als die persoon in die functie blijft.

In welke gevallen wij van gedachten zouden veranderen

Wij zouden velocity zonder voorbehoud toestaan voor elk team dat het uitsluitend gebruikt voor prognoses en planning, en het nooit buiten de vergaderruimte laat komen. Op die manier gebruikt is het helemaal geen valstrik — het is gewoon een rekenkundige berekening die het team voor zichzelf uitvoert.

Wij zouden dit in twee gevallen volledig achterwege laten. Ten eerste, indien het werk zo uniform is dat zowel het tellen van verhalen als het optellen van punten — dan vormt de velocity een extra belasting, en is de doorvoer eenvoudiger en moeilijker te manipuleren. Ten tweede, als de organisatie niet kan voorkomen dat het cijfer als wapen wordt ingezet. Wanneer de spiraal cultureel vastzit en geen enkel individu deze kan tegenhouden, is de eerlijke stap om te stoppen met het produceren van het cijfer dat wordt misbruikt en over te stappen op flow-statistieken die dat niet worden.

De praktische kant van de zaak

• Snelheid meet het tempo, niet de productiviteit. Zeg dit hardop in de vergaderruimte zodra iemand dit voor het eerst interpreteert als een prestatiemaatstaf.
• Vergelijk nooit teams, stel het nooit als doel en reken het nooit om naar verwachte uren per ontwikkelaar. Dit zijn allemaal dezelfde fout, maar dan in een andere gedaante.
• Rapporteer resultaten, geen puntentotalen. De vier kernpunten van DORA — implementatiefrequentie, doorlooptijd voor wijzigingen, percentage mislukte wijzigingen, hersteltijd — meten de leveringsprestaties zonder ruimte te bieden voor manipulatie en hebben, in tegenstelling tot punten, voor alle teams dezelfde betekenis. Dat is de set van prestatie-indicatoren die het management daadwerkelijk wenst.
• Pas de punten in de backlog niet aan wanneer het team sneller gaat werken. De stories zijn niet kleiner geworden — het team is sneller geworden, en het velocity-cijfer zal vanzelf stijgen. Het aanpassen van de punten om de velocity op peil te houden, is alsof de ratel achteruit draait, en het verpest de prognose op precies dezelfde manier.

Velocity dient als kompas voor het team, niet als beoordelingsinstrument voor managers. Als u het binnen het team houdt, is het een van de nuttigste indicatoren binnen agile. Als u het naar buiten brengt, wordt het het duidelijkste voorbeeld van een Power failure mode dat er bestaat.

Veelgestelde vragen

Is snelheid een maatstaf voor productiviteit?

Nee. Velocity meet het tempo, niet de productiviteit — namelijk hoeveel story points een bepaald team per sprint voltooit volgens zijn eigen kalibratie. Het geeft geen uitsluitsel over de vraag of het werk waardevol was, en daar is het ook nooit voor bedoeld geweest. Het onderzoek van DORA sluit velocity juist om deze reden bewust uit van zijn leveringsstatistieken.

Kunt u de snelheid tussen verschillende teams vergelijken?

Nee. Twee teams die dezelfde hoeveelheid werk inschatten, komen tot verschillende snelheidscijfers omdat zij verschillende referentieverhalen hanteren — dat is nu juist de kern van relatieve schatting. Het vergelijken ervan is te vergelijken met het vergelijken van twee thermometers met verschillende nulpunten. Mike Cohn, die pleit voor story points, geeft toe dat al bij de geringste suggestie dat snelheden met elkaar zullen worden vergeleken, er sprake is van een consistente opblazing van de punten.

Wat moeten wij aan het management rapporteren in plaats van de velocity?

Rapporteer resultaten, geen cijfers. De vier kernindicatoren van DORA — implementatiefrequentie, doorlooptijd voor wijzigingen, percentage mislukte wijzigingen en tijd die nodig is om de dienstverlening te herstellen — meten de prestaties op een manier die geen ruimte biedt voor manipulatie en die tussen teams onderling vergelijkbaar is. De ‘velocity’ blijft binnen het team als input voor de planning; de vier kernindicatoren zijn waar het management daadwerkelijk op moet letten.

Aanbevolen lectuur

• Snelheid: waarvoor dient deze en hoe berekent u deze? — de werking ervan, en waarom deze niet meer klopt zodra deze tot doelwit wordt.
• Story points versus #NoEstimates — de strijd in de vroege fasen: wat het getal waard is voordat het een prognose wordt.
• Story points versus uren — waarom het omrekenen van een van beide naar uren opnieuw het probleem veroorzaakt dat met ‘velocity’ juist wordt verholpen.
• Wat is een burndown-grafiek? — het bijhouden van de toegewezen punten binnen een sprint; een eerlijke weergave van het aantal.
• Agile Theatre: de ‘Power failure’-modus — hoe maatstaven zoals velocity worden omgevormd tot controle-instrumenten.