In organisaties waarin agile transities plaatsvinden zie ik dat het oude gezegde Het bloed kruipt waar het niet gaan kan regelmatig van toepassing is. Er wordt besloten over te gaan op agile werken, men heeft het over Scrum, zelf-organiserende teams, Sprints, staand vergaderen, enzovoort, enzovoort. Iedereen moet met de tijd mee, de hele organisatie moet om. Maar als puntje bij paaltje komt wordt al snel teruggegrepen naar oude vertrouwde gewoonten door de Command and Control methode van stal te halen, met als resultaat een flinke deuk in het geloof in zelf-organisatie.

Er wordt vaak gezocht naar methoden om inzicht te krijgen in de kosten en baten van het agile werken, met als doel te controleren en daarop te kunnen sturen. Voor dergelijke gegevens zoekt zijn veel agile tools een uitkomst, want deze zijn vaak voorzien van allerlei rapportage mogelijkheden. Met één druk op de knop worden allerlei gegevens, overzichten en grafieken tevoorschijn gehaald die betrekking hebben op de prestaties van de agile teams, mits deze teams de tool ook netjes vullen met data.

Neem nou de rapportage omtrent velocity van de teams. Het komt regelmatig voor dat deze rapportages gebruikt worden om teamprestaties met elkaar te vergelijken. Of om te zien hoe de velocity van het team zich in de loop van de tijd ontwikkelt, “want naarmate een team beter wordt, stijgt de velocity”, zo denkt men. En het komt ook voor dat velocity gekoppeld wordt aan kosten; m.a.w. wat kost het team per story point?

Dit baart mij zorgen. Ten eerste kun je teams niet met elkaar vergelijken met behulp van velocity cijfers. Een gemiddelde velocity van 20 bij team A en 25 bij team B wil niets meer zeggen dan dat team A een velocity heeft van 20 story points en team B een velocity van 25 story points. Meer niet. Elk team kent zijn eigen waarde toe aan story points; een 5 bij team A is iets anders als een 5 bij Team B.

Wanneer de velocity in de loop van de tijd stijgt, kan het zijn dat het team steeds beter wordt, maar dat hoeft niet. Het kan zo maar zijn dat het team Product Backlog Items hoger inschat dan voorheen. Een team kan ook groeien zonder dat dit zichtbaar is in de velocity cijfers. Bijvoorbeeld als het team steeds minder tijd nodig heeft om items te realiseren en vervolgens de Definition of Done aanscherpt/uitbreidt. Het team voert dan in dezelfde tijd extra werkzaamheden uit die de kwaliteit van het werk verhogen, maar de velocity blijft zo’n beetje gelijk. Natuurlijk kan het zijn dat de velocity gelijk blijft doordat een team nooit verbeteringen doorvoert en niet groeit. In dat geval heb je als Scrum Master nog een flinke uitdaging.

De velocity is van het team. Het is alleen een indicatie voor het team zelf en voor de Product Owner om enigszins een beeld te krijgen hoeveel werk in een Sprint verzet kan worden en (voor de Product Owner) als planningsindicatie om te bepalen hoeveel Sprints er ongeveer nog te gaan zijn alvorens een bepaald Product Backlog item opgepakt wordt (als de huidige situatie niet verandert).

Mijn advies; laat de velocity bij het team. Je weet wat de kosten zijn; je kent de bezetting per team, je weet hoelang een Sprint duurt, dus je weet ook de kosten per Sprint per team. Als je wil vergelijken, vergelijk dan op waarde, op outcome niet op output.