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 met opzet buiten de leveringsstatistieken gehouden.

Vrijwel iedereen die zich in dit debat mengt, 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 genuanceerd 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 omvang door het recente gemiddelde van het team en u krijgt een ruw aantal sprints dat u kunt opleveren. Het stelt u in staat 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 intentie van het management achter ‘velocity als meetmaatstaf’ is eveneens legitiem en verdient het om eerlijk te worden vermeld. Leidinggevenden zijn verantwoordelijk voor de oplevering en willen daar inzicht in hebben. „Als we het team op de een of andere manier niet kunnen meten, hoe weten we dan of het presteert?” is een redelijke vraag, geen uitspraak van een schurk. Het probleem ligt niet in de wens zelf. Het probleem is dat velocity hiervoor het verkeerde instrument is.

Het argument dat snelheid een valstrik is

Richt de snelheid naar buiten en het vertoont voorspelbare patronen. Stel het als doel („verhoog de snelheid dit kwartaal met twintig procent”) en het team voldoet daaraan door hetzelfde werk omvangrijker te maken 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 erger, 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, en 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 hiervan volledig afzien in twee gevallen. Ten eerste, indien het werk zo uniform is dat zowel het tellen van verhalen als het optellen van punten, dan vormt de snelheid een extra belasting en is de doorvoer eenvoudiger en moeilijker te manipuleren. Ten tweede, indien de organisatie er niet van af kan blijven het cijfer als wapen in te zetten. Wanneer de spiraal cultureel verankerd is 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

• Snelheid meet het tempo, niet de productiviteit. Zeg dit hardop in de vergaderzaal zodra iemand dit voor het eerst interpreteert als een prestatiemaatstaf.
• Vergelijk nooit teams, stel dit nooit als doel en reken het nooit om naar verwachte uren per ontwikkelaar. Dit zijn allemaal dezelfde fout, maar dan in een ander jasje.
• Rapporteer resultaten naar boven toe, niet het aantal punten. De vier kernpunten van DORA, de frequentie van implementaties, de doorlooptijd voor wijzigingen, het percentage mislukte wijzigingen en de tijd die nodig is om de situatie te herstellen: meet de prestaties zonder ruimte te bieden voor manipulatie en zorg ervoor dat deze indicatoren, in tegenstelling tot punten, voor alle teams dezelfde betekenis hebben. Dat is de reeks meetcriteria die het management daadwerkelijk wenst.
• Pas de waardering van 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 waardering 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 productiviteitsmaatstaf?

Nee. Velocity meet het tempo, niet de productiviteit: het geeft aan hoeveel story points een bepaald team per sprint voltooit volgens zijn eigen kalibratie. Het zegt niets 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 hetzelfde werk inschatten, komen tot verschillende snelheidscijfers omdat zij verschillende referentieverhalen hanteren, en 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 minste suggestie dat snelheden met elkaar zullen worden vergeleken, er sprake is van een consistente opdrijving van de punten.

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

Rapporteer resultaten, geen puntentotalen. 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 mechanica ervan, en waarom deze niet meer klopt zodra deze tot doelwit wordt.
• Story points versus #NoEstimates: de strijd in de beginfase: wat het getal waard is voordat het een prognose wordt.
• Storypoints 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 instrumenten van controle.