Velocity: de snelheid van een ontwikkelteam

Voor aanvang van een software-ontwikkelproject is het verstandig te kijken welke ontwikkelmethodiek het beste aansluit bij het project en bij het type klant. In het ene geval is dat de Agile-methodiek, waaronder de inmiddels bekende Scrum-methode valt, in een ander geval is dat het Rational Unified Process (RUP). Voor welke methode er ook wordt gekozen, het moet de basis zijn voor een duurzame relatie tussen de opdrachtgever en de IT-afdeling/leverancier. Waarbij er zo efficiënt en effectief mogelijk aan een project gewerkt wordt. Maar hoe kun je ontwikkel-efficiëntie concreet maken? Hiervoor is een eenvoudig kengetal te gebruiken: Velocity.

In feite zegt Velocity iets over hoe goed of snel het team het doet in een project. Dat lijkt misschien eenvoudig, maar de praktijk laat toch iets anders zien. Voor het gemak gaan we er in dit verhaal even van uit dat we op basis van Scrum gaan ontwikkelen. Om ‘zeker’ te stellen wat gemaakt moet worden, leggen we vooraf met de klant (in Scrum heet dit: Product Owner) de doelen en scope vast (Scrum: Product Backlog). Moeilijkheid bij scoping is dat er meestal onverwachte veranderingen optreden en dat er een toevlucht genomen moet worden naar change management. Change management lijkt effectief, maar is eigenlijk erg kostbaar. Je kunt de overhead van het change management namelijk niet in resultaat omzetten. Mijn vraag is dan ook: waarom zouden we dit niet loslaten?

Niet WAT, maar HOE
Als we bij een project nu eens niet gaan sturen op het WAT (de Scope), maar juist dieper ingaan op het HOE (de ontwikkel-efficiëntie)? Door elke keer uit te gaan van korte iteraties (Scrum: Sprints) van 2 tot 4 weken, waarin bepaald wordt welke functionaliteiten (Scrum: User Story) als eerste opgeleverd moeten worden, kan gemeten worden hoeveel werk (Scrum: Story Points) het team in die periode heeft gerealiseerd. Het resultaat hiervan is de Velocity.

Voorafgaand aan iedere Sprint worden sessies (Scrum: Pokersessie) georganiseerd waarin de klant (Scrum: Product Owner) het team vertelt welke functionaliteiten de hoogste prioriteit hebben en wat hij met de functionaliteit wil. Bijvoorbeeld de functionaliteit is inloggen op de website met een gebruikersnaam en wachtwoord. Vervolgens gaat de Project Manager (Scrum: Scrum Master) met het team aan de slag en geeft elk teamlid individueel aan hoeveel tijd (Scrum: Story Points) er nodig is om de functionaliteit te realiseren. Dit varieert veelal per teamlid en na een paar rondes komt daar een ideaal getal (Scrum: Story Point) uit. Laten we er voor het gemak vanuit gaan dat 1 Story Point = 1 Ideale dag. Dit gebeurt dan voor alle functionaliteiten die voor die betreffende periode (Scrum: Sprint) zijn ingedeeld.

Schematisch ziet dat er bijvoorbeeld als volgt uit.

In de eerste Sprint blijkt dat het team functionaliteit X en Y opgeleverd heeft en dat functionaliteit Z niet klaar is (voldoet niet aan de ‘Definition of Done’). Gekozen is voor een hoeveelheid tijd (Scrum: Story Points) van 38, maar er is 18 verbruikt. We zeggen dan dat ‘de Velocity’ van het team 18 is. Het zegt dus iets over hoe goed en hoe snel het team het doet. In de volgende iteratie (Scrum: Sprint) worden weer nieuwe functionaliteiten afgesproken. Er is dan de keuze om deze te splitsen in een deel dat klaar is en een deel dat niet klaar is. Of de gehele functionaliteit Z weer toevoegen. De laatste optie wordt het meest gekozen.

Standaard Microsoft Scrum Rapport over Velocity

Forming of performing
Eén van een de lastigste onderwerpen voor een IT-afdeling/leverancier is de bemensing van een project. Vaak wordt dit op individuele basis gedaan. Ook vanuit de opdrachtgever is vaak het standpunt om de beste mensen op een project te hebben. Maar de beste mensen zijn niet per definitie de meest efficiënte mensen in groepsverband. Vaak is het juist beter om een al goed functionerend bestaand team op een project te zetten. De leden van een bestaand team hebben namelijk de opstartfase al in eerdere (vergelijkbare) projecten samen gedaan en dit team zal daarom starten met een hogere Velocity dan een nieuw startend team.

Organisaties hoeven nu alleen nog maar garanties voor de team Velocity te eisen in plaats van uit te gaan van individuele cv’s. De inzetbaarheid van welk team (met welke focus) en de grootte van het team zal blijven afhangen van de projectdoelen. Hoe effectiever een team samenwerkt, hoe beter de planning en haalbaarheid van de vooraf gestelde Story Points. Een team waarin de leden heel goed op elkaar zijn ingespeeld heeft vaak ook een hoge Velocity, oftewel is een high performing team.

Maar ook zonder team history is Velocity al bruikbaar
Indien er toch gekozen wordt voor een nieuw team, kan er toch een goede inschatting gemaakt worden van de Velocity. Neem bijvoorbeeld de volgende berekening.

^*) Met de focusfactor worden de bruto beschikbare uren gecorrigeerd.

De focusfactor is laag omdat er in het begin tijd (en geld) verloren gaat aan het opstarten van het project. Over de uiteindelijke Velocity zijn moeilijk prognoses te maken, maar het zal nagenoeg altijd beter zijn dan de eerste berekening. Organisaties kunnen ervan uit gaan dat de eerste initiële inschatting al direct de voorzichtige inschatting zal zijn.

Zijn Story Points niet te abstract?
Ja, veel discussie ontstaat omdat Story Points snel een (te) abstracte lading gaan krijgen. Het is een getal zonder dimensie en het geeft een relatieve zwaarte aan van een Product Backlog Item. Story Points kunnen handig zijn indien de klant nauw betrokken is bij het ontwikkelteam. De praktijk laat vaak zien dat er een afstand is tussen de klant en de IT-afdeling/leverancier. In dit geval kunnen we Story Points beter interpreteren als ‘ideal working days’. Voorbeeld: 8 Story Points betekenen 8 dagen werk zonder enige verstoring bij de ontwikkelteams.
Onbewust denkt iedereen ook in deze termen indien er een planning gemaakt wordt. In de praktijk komen er natuurlijk wel verstoringen voor. Een ontwikkelteam probeert zichzelf te verbeteren en verstoringen te minimaliseren (focusfactor). Teams met een relatief constante Velocity hebben deze verstoringen kunnen minimaliseren en zijn betrouwbaar bij de voortgang van een project.

Conclusie
Waarom zal een organisatie opdracht geven voor het bouwen van een website? Natuurlijk omdat er een business-voordeel behaald kan worden ten opzichte van concurrenten in de markt. Er is een concreet beeld (of misschien minder concreet) welke functionaliteiten op de website nodig zijn. Het is daarom verstandig om inhoudelijk de functionaliteiten (WAT) bij de opdrachtgever te laten (eventueel kan de IT-afdeling/leverancier wel ondersteunen). Echter, eis als opdrachtgever van de IT-afdeling/leverancier de technische haalbaarheid en inzicht in HOE deze functionaliteiten het best ontwikkeld kunnen worden. Door deze scheiding te leggen, blijft het altijd duidelijk waar de verantwoordelijkheden liggen. Door de HOE-vraag bij de IT-afdeling/leverancier te leggen kunnen er eenvoudig Velocity-afspraken gemaakt worden. Dus laat de IT-afdeling/leverancier (het team) uitleggen hoe bepaalde functionaliteiten gemaakt kunnen worden en laat optimaliseren op Velocity. Zo wordt een project uiteindelijk het meest efficiënt en effectief uitgevoerd.