Sturen op een Agile ontwikkelstraat in de praktijk

Sturen op drie variabelen

Om een goed beeld te krijgen van hoe de fabriek het doet, hoeveel voortgang er wordt geboekt én wat de bijbehorende kosten zijn, is één variabele niet genoeg. Ik kijk daarom het liefst naar drie variabelen, gekoppeld aan input (uren), proces (storypoints) en output (functiepunten).

Variabele 1: sturen op input, op basis van uren

De meeste organisaties kijken in elk geval naar uren. Dat is ook logisch, want uren schrijven is op veel plekken heel gebruikelijk. Het is zeker nuttig om naar uren te kijken, het geeft een beeld bij de hoeveelheid tijd die is gespendeerd aan het product. Met behulp van het uurtarief kunnen de kosten ook snel worden bepaald. Lastiger is het, om uren goed toe te wijzen aan een of meerdere specifieke delen van een product. In mijn praktijk probeer ik urencodes te koppelen aan Epics en/of Features. Daarbij heb ik als vuistregel, dat er in principe niet meer dan 4 urencodes per week voor elke medewerker van toepassing moeten zijn.

De urencode leg ik vast in Jira (een veel gebruikte backlog management tool) in een Epic. Met de teams spreek ik af dat het bovenliggende Epic bepaalt op welke code ze moeten schrijven voor user stories, bugs of andere items. Jira kent van zichzelf maar drie bruikbare niveau’s: het Epic niveau, het backlog item niveau (User Story of vergelijkbare items) en het Sub-Tasks niveau. Daarom zijn “Epics” in Jira toch vaak Features en administreer ik de Epics en hun relatie met de Features, in een aparte lijst.

Als de Features groot genoeg zijn, dan geeft dit een voldoende nauwkeurig beeld om te kunnen sturen. Het Sub-Task niveau laat ik vooral aan de teams om zelf hun sprint mee te besturen. Een belangrijk nadeel van sturen op uren, is dat het alleen “input” betreft en niet zoveel zegt over de output of het proces. Een sprint is in de basis altijd hetzelfde aantal uren (los van vakanties en dergelijke), maar dat zegt niets over wat de sprint heeft opgeleverd.

Variabele 2: sturen op proces, op basis van storypoints

Om continu te kunnen verbeteren wil je ook een beeld hebben bij hoe het Scrum proces verloopt. Een veel gebruikte variabele in Scrum zijn de storypoints. Het is een relatieve maat voor de omvang, complexiteit en het risico voor de realisatie van een klein stukje functionaliteit (User Story). Deze variabele is team specifiek, elk team kan zelf bepalen wat ze onder 1 storypoint verstaan. Het is wel de bedoeling dat deze binnen het team zijn geijkt op referentie stories, zodat er geen “inflatie” ontstaat. De hoeveelheid storypoints dat een team per sprint kan afronden is de “Velocity”. Als de velocity stijgt (en de stories blijven geijkt), dan is het team aan het versnellen of verbeteren. Ook het stabiel zijn van de velocity geeft inzicht in hoe goed het team in staat is om voorspelbaar te leveren.

Het doel van storypoints is om het team zelf een handvat te geven om te verbeteren en voorspelbaar te worden. Hierbij kun je het team, van buitenaf, met behulp van de storypoints coachen. Als je dat doel wilt blijven nastreven, zijn storypoints naar mijn mening niet geschikt om voortgang mee te sturen in een ontwikkelstraat met meerdere teams:

1. Storypoints zijn team specifiek en niet onderling vergelijkbaar
2. Bij wijzigingen in de teamsamenstelling, een nieuw onderwerp of nieuwe technologie, kan de velocity flink veranderen
3. Sturen op een procesverbeteringsvariabele levert een “perverse prikkel” op, waardoor je krijgt waar je op stuurt. Bewust of onbewust zullen mensen streven naar een beter of het gewenste getal, zonder dat het onderliggend doel is gehaald

Het mooie is dat je, zolang een team stabiel is, wel inzicht kunt creëren door een relatie te leggen tussen uren en storypoints, zolang je er maar niet over rapporteert of op stuurt. Het geeft je inzicht bij het coachen van het team. Belangrijk is in elk geval om storypoints niet te gebruiken als maat voor wat er is opgeleverd.

Variabele 3: sturen op output met behulp van functiepunten

Gelukkig zijn er andere mogelijkheden om te sturen op wat er aan functionaliteit is opgeleverd. Functiepunten worden al heel lang gebruikt als maat van de hoeveelheid functionaliteit voor gebruikers. Er zijn uitgebreide benchmarks beschikbaar over de relatie tussen functiepunten (output) en de geleverde inspanning (uren), zelfs per sector en per ontwikkeltaal/stack. Het verloop van het aantal geproduceerde functiepunten in een klassiek project, kenmerkt zich vaak door een S-curve. In het begin is er een aanlooptijd om op te starten, daarna versnelt de softwarefabriek en aan het einde wordt vooral gewerkt aan non-functionals en het oplossen van bugs (die geen functiepunten opleveren).

Een prettige eigenschap van functiepunten is dat ze gestandaardiseerd zijn en door een onafhankelijke derde kunnen worden geteld. Ze zijn met een paar kanttekeningen (zie de uitdagingen hieronder) wel geschikt om een beeld te vormen bij de voortgang. Al geldt ook hier dat je er niet direct op moet sturen om perverse prikkels te voorkomen.

Er zijn twee uitdagingen bij functiepunten:

1. Functiepunten zijn niet echt geschikt voor het meten van verbetering van de technische implementatie (refactoring) of van de invulling van non-functional requirements, zoals performance
2. Functiepunten zijn vooral gericht op functionaliteit en niet op business waarde. De business waarde is niet direct gerelateerd aan de hoeveelheid functionaliteit alleen. Om de business waarde te maximaliseren (het doel van Agile) moet het backlog worden geprioriteerd door mensen die kunnen inschatten wat de relatieve waarde is van elk item op de lijst

Samenhang

Elk van de drie stuurvariabelen heeft zo zijn eigen voor- en nadelen. Door ze alle drie in samenhang te beschouwen, krijg je een solide inzicht in de ontwikkelstraat. Dat inzicht kun je dan gebruiken om zo nodig interventies te plegen, zonder direct te sturen op de cijfers. Een goed voorbeeld is de constatering dat er onvoldoende analyse/specificatie capaciteit is. De uren die worden besteed blijven gelijk, terwijl de velocity daalt en het aantal uren per functiepunt stijgt. Natuurlijk is het nog wel nodig om de onderliggende oorzaak vast te stellen door interactie met de teams. Belangrijk is dat de stuurvariabelen helpen bij het vaststellen dat er een bottleneck is en ook bij het meten óf de interventie (toevoegen van capaciteit), het gewenste effect heeft.

Meer weten over agile?

Heb jij een vraag of een uitdaging waarover je met ons wilt sparren? Neem dan direct contact met ons op. We denken graag met je mee.

Wil je weten of jouw organisatie agile geschikt is of niet, bestel dan ons boekje Agile: Geschikt/Ongeschikt of neem contact met ons op. We gaan graag met je in gesprek over wat jou bezighoudt op agile gebied.