Agile projectkosten- en tijdmanagement

Agile softwareontwikkeling draait om het leveren van klantwaarde. Omdat al het werk vanaf het begin gericht is op klantwaarde en een werkend product, is het van nature efficiënter en minder verspillend. Een goed uitgevoerde agile ontwikkeling is agile omdat het zich aanpast aan en reageert op veranderingen. Als budgetten opraken of de eisen ingrijpend veranderen, krijgt de klant uiteindelijk toch een werkend product. Agile ontwikkeling is zo logisch dat het breed is overgenomen, ook buiten de softwareontwikkeling.

Agile softwareontwikkeling draait om het leveren van klantwaarde.

Prima, maar betekent dit dat de kosten niet hoger zullen uitvallen dan de schatting, zoals bij softwareprojecten vaak het geval is? Hoe beheer en schat je de kosten?

Een veelgehoord cynisch antwoord is: Agile softwareprojecten hebben een budget nodig, geen schatting. Het vervangen van een schatting door een budget zou de zaken zoveel overzichtelijker en het leven zoveel gemakkelijker maken. Helaas zijn dingen vaak ingewikkelder dan ze lijken, en daar gaan we nu dieper op in.

Hebben Agile-projecten een kostenraming nodig?
Het antwoord op deze vraag is eigenlijk een andere vraag: waarom vindt de klant een kostenraming nodig?

Als het antwoord simpelweg is om de ontwikkelaar aan een vaste afspraak te houden of om de ontwikkelaar onder druk te zetten als hij niet aan de verwachtingen voldoet, dan zouden we geneigd zijn nee te zeggen. Aan de andere kant, als belangrijke beslissingen of plannen afhangen van de kostenraming, zullen we er dieper op in moeten gaan.

Soms is een project zo urgent dat er, zolang de klant en de leverancier het maar eens kunnen worden, meteen aan gewerkt moet worden zonder kostenraming. Een project in de verkenningsfase vereist slechts een ruwe schatting, zodat de klant de juiste middelen kan toewijzen, kan beslissen of het project betaalbaar is of dat het beter is om te wachten tot het is afgerond.

Het hele punt van agile ontwikkeling is juist om niet vast te houden aan de oorspronkelijke verwachtingen, die misschien niet eens haalbaar zijn. Daarom zijn de meeste schattingen van nature ruw. Er zullen echter altijd momenten zijn waarop we een meer gedetailleerde schatting moeten maken.

De 5 stappen van schatten en plannen
Schatten en plannen zijn nauw met elkaar verweven in agile ontwikkeling. Er zijn tools beschikbaar om de efficiëntie van het proces te volgen. Een ander kenmerk van agile ontwikkeling is dat de schatting zo vaak als nodig kan worden bijgewerkt, dus het is geen probleem, zelfs als de details van een project in het begin onbekend zijn.

We zullen het Scrum-framework voor agile softwareontwikkeling gebruiken. Er zijn 3 rollen in een Scrum-project: Product Owner, ScrumMaster en Team. Een backlog is een lijst met functionaliteiten en een backlogitem is een functionaliteit. Een backlogitem wordt vastgelegd in een story-formaat, een zogenaamde user story. Deze kan verder worden onderverdeeld in story points, waarvan de som de hoeveelheid inspanning vertegenwoordigt die nodig is om de user story of feature te voltooien. Een sprint is een iteratie. De rest wordt gaandeweg geïntroduceerd. (De Scrum-nomenclatuur is nuttig, los van de elegantie ervan. Waarom geen sprint in plaats van iteratie, waardoor mensen in slaap vallen? Zou je liever een story of werk toegewezen krijgen?)

1. Backlog creëren
Een productbacklog is een lijst van alle features in het product. Eerst splitsen we het initiële idee op in kleinere features, oftewel backlogitems. Het initiële idee kan abstract zijn, maar backlogitems moeten definieerbaar zijn. Deze backlogitems worden vastgelegd en beschreven in user stories. Een agile user story beschrijft de feature tot in elk gewenst detailniveau, dat continu kan worden aangepast. De productbacklog wordt van tevoren gepland, maar zal natuurlijk evolueren naarmate elke user story wordt aangepast, toegevoegd of verwijderd. Een backlog kan tientallen of zelfs honderden user stories bevatten.

2. Prioriteer items in de backlog
Rangschik de user stories in de backlog op aflopende prioriteit (dit wordt gedaan door de Product Owner). In lijn met het principe van vroegtijdig waarde leveren, begint Agile softwareontwikkeling altijd met de items met de hoogste prioriteit.

Bijvoorbeeld, om een Magento e-commerce website te bouwen, zouden voorraadbeheer en winkelwagen een hogere prioriteit hebben dan reviews en blogs. De website zou nog steeds functioneel zijn, zelfs als het project niet verder zou gaan met reviews en blogs.

3. Schat de projectomvang
Schat de omvang van het project door het totale aantal story points op te tellen. Een Scrum-team van ontwikkelaars kent aan elk gebruikersverhaal een aantal story points toe. Het totaal aantal story points is een maatstaf voor de omvang en complexiteit van het project (hoe hoger het aantal, hoe complexer het project).

Aan elk gebruikersverhaal wordt een Fibonacci-getal toegekend, bijvoorbeeld van 1 tot 21. Het getal in oplopende volgorde weerspiegelt de complexiteit van een gebruikersverhaal en daarmee de relatieve hoeveelheid inspanning die nodig is om het te voltooien. Dit getal wordt het aantal story points van het betreffende gebruikersverhaal. Merk op dat een story point van 8 niet betekent dat het verhaal 8 uur of iets dergelijks in een sprint zou kosten – het is slechts een voorlopig aantal story points. Een populaire methode om deze voorlopige schatting te bepalen is Scrum poker.

Scrum poker zou cognitieve vertekeningen zoals anchoring (overmatige afhankelijkheid van de eerste informatie) en het Dunning-Kruger-effect (een illusie van grootheidswaanzin) verminderen.

4. Schat de benodigde projecttijd in
Deze schatting is geen exacte voltooiingsdatum. Begin met een productroadmap en een releaseplan. De productroadmap van een agile ontwikkelomgeving laat de evolutie van het product zien door middel van een aantal belangrijke releases. Het releaseplan is een schema van belangrijke releases, gebaseerd op de productbacklog.

De benodigde projecttijd wordt voor elke sprint geschat. De meeteenheid is de velocity, die in Scrum het aantal voltooide user stories per sprint is. Een goede richtlijn voor het voorspellen van de initiële velocity is te vinden in de blogpost van Mike Cohn: blogpost. Het schatten van de benodigde tijd is een iteratief proces, omdat de velocity fluctueert voordat deze na een paar sprints stabiliseert.

Het incrementele karakter van agile ontwikkeling betekent dat het product stukje bij stukje kan worden opgeleverd, waarbij elk stukje een werkend en leverbaar product is, ook al is het nog niet compleet. Hoeveel en welke functionaliteiten er worden uitgebracht, kan op andere manieren dan deadlines worden beheerd en gecontroleerd.

5. Schat de projectkosten
Het berekenen van de projectkosten is vrij eenvoudig zodra de projectomvang en -snelheid bekend zijn. Er zijn twee standaardbenaderingen hiervoor: via een gemengd tarief of specifieke arbeidscategorieën. Bekijk het artikel van Jesse Fewell, aangezien de details hier buiten het bestek vallen. Beide methoden gaan uit van een constant aantal teamleden en sprints zoals vastgelegd in het releaseplan.

Een snellere schatting kan worden verkregen door de burn rate van het team per sprint te berekenen en aan te nemen dat deze vaststaat. Het totale aantal benodigde sprints kan worden berekend door het totale aantal user stories te delen door de snelheid.

De meeste dienstverlenende bedrijven hebben een tarieflijst met uurtarieven voor elke arbeidscategorie. De burn rate van elk teamlid (inclusief Product Owner en ScrumMaster) per sprint is: Uurloon x Werkuren/dag x Aantal dagen in een sprint

De burn rate van het team per sprint is de som van de burn rates van elk teamlid per sprint, zoals hierboven berekend.

Hoewel deze als vast wordt beschouwd, kan de geschatte burn rate van het team per sprint continu worden verfijnd, aangezien de werkelijke velocity na afloop van elke sprint bekend is.

Het bijhouden van de workflowefficiëntie
Agile softwareontwikkeling is inherent efficiënter. Bovendien zijn er kant-en-klare oplossingen voor workflowefficiëntie ingebouwd in Scrum en andere agile frameworks. Uiteindelijk zijn echter inzichten en goed management nodig om er absoluut zeker van te zijn dat er op geen enkel moment tijdens de ontwikkeling resources worden verspild.

De aanwezigheid van positieve synergie en de gelijktijdige afwezigheid van negatieve omstandigheden zijn essentieel voor een efficiënte workflow. Het bereiken van positieve synergie betekent het creëren van een omgeving waarin individuele inspanningen worden gericht op maximale impact. Ongunstige omstandigheden in softwareontwikkeling omvatten onder andere het tegenkomen van knelpunten en het oplopen van codeschuld.

Veel activiteiten in agile ontwikkeling kunnen worden geautomatiseerd met als uiteindelijk doel een efficiëntere workflow. Een bekende en beproefde tool is JIRA Software, een aanpasbare agile projectmanagementtool met ondersteuning voor alle agile frameworks, waaronder Scrum en Kanban en hun populaire varianten.

Burndown-grafiek
Een burndown-grafiek houdt de resterende taken bij die in een sprint moeten worden voltooid. Het is een grafiek met de geplande hoeveelheid werk (user stories, story points of het equivalent daarvan in dagen) op de y-as en de sprinttijdlijn op de x-as. De grafiek begint bij het geplande totale aantal user stories in een sprint en loopt af naar nul, idealiter op of vóór de laatste dag van de sprintcyclus.

Er worden twee lijnen of curven in de grafiek weergegeven. De ene grafiek toont de geprojecteerde of ideale burndown rate, de andere de daadwerkelijke burndown rate die aan het einde van elke dag wordt weergegeven.

De burndown-grafiek van een sprint houdt de voortgang bij en geeft aan of het team op schema ligt om al het geplande werk aan het einde van de sprint af te ronden. Teamleden weten wanneer ze indien nodig moeten bijsturen door de sprint-burndown-grafiek in de gaten te houden.

De burndown-grafiek kan worden uitgebreid naar het hele project door de x-as uit te breiden naar de geprojecteerde releasedatum en de y-as naar het geplande totale aantal user stories of story points voor het project. Dit wordt de release burndown-grafiek genoemd, in tegenstelling tot de sprint burndown-grafiek.

Earned Value Management (EVM)
Earned Value Management (EVM) is sinds de introductie in agile frameworks in 2006 uitgegroeid tot een enorm populaire methode voor het meten van de prestaties van agile projecten. EVM wordt meestal toegepast op releaseniveau in plaats van op individuele sprints.

De verschillende metrics van EVM worden berekend op basis van het geplande aantal user stories en het aantal dat daadwerkelijk is voltooid. We zullen er specifiek drie bekijken: werkelijke kosten (AC), verdiende waarde (EV) en geplande waarde (PV). AC staat voor de werkelijke kosten van het uitgevoerde werk, EV voor de gebudgetteerde kosten van het uitgevoerde werk en PV voor de gebudgetteerde kosten van het geplande werk.

AC, EV en PV kunnen worden opgenomen in de release burndown-grafiek om de efficiëntie van een agile project in een bepaalde fase te illustreren. De totale kosten en duur van het project, zoals voorspeld door een release burndown-grafiek met EVM, geven de klant en leverancier waardevolle tijd om weloverwogen beslissingen te nemen over noodzakelijke of gewenste wijzigingen.

EV is een belangrijke maatstaf voor kostenefficiëntie, maar is vaak niet gelijk aan AC en PV. Dit wordt veroorzaakt door efficiëntieproblemen zoals inefficiënte workflows en een verkeerde afstemming van prioriteiten en schattingen, of door andere variabelen zoals de initiële opstartfase en veranderingen in vereisten en prioriteiten.

EVM-gegevens zijn historisch, actueel en voorspellend van aard. Ze maken het mogelijk om historische gegevens te gebruiken voor iteratieve schattingen, diagnose van actuele gegevens tijdens het volgen van de voortgang en voorspelling van toekomstige gegevens voor tijdige beslissingen om de klantwaarde te optimaliseren.

De EVM-gegevens geven aan of er sprake is van inefficiëntie, en niet veel meer. Het is aan het team om de oorzaak van de inefficiëntie te achterhalen. Zou een StrumMaster zijn of haar reputatie op het spel zetten om de werkelijke oorzaak te achterhalen?

De ware waarde van agile ontwikkeling
Agile softwareontwikkeling levert al vroeg en vaak waarde voor de klant. Na slechts een paar sprints is een agile softwareproduct klaar voor een vervroegde release, met alle kernfunctionaliteiten aanwezig, en de eindgebruikers merken er misschien niets van.

Agile ontwikkeling gedijt op veranderingen, dus gedetailleerde planning kan achterwege worden gelaten. Het is het beste om met een voorlopige prioriteitenlijst aan de ontwikkeling te beginnen. Volg de voortgang bij elke stap om wijzigingen te kunnen bedenken en weloverwogen beslissingen te nemen.