Terug naar overzicht

De afgelopen jaren zijn steeds meer organisaties overgegaan tot een Agile projectaanpak. Welke impact heeft deze aanpak op de controlfunctie? Hoe kunnen vragen als ‘Wat gaat dit project kosten,’ ‘Wanneer is het af,’ en ‘wat levert het op?’ bij een Agile aanpak worden beantwoord en op welke wijze kan de controller bij de beantwoording ondersteunen? In dit artikel een aantal aanknopingspunten.

Agile en de impact op de controlfunctie

Het Agile Manifest (Manifesto for Agile Software Development) dateert uit 2001 en is een reactie op traditionele (software) ontwikkelmethoden uit de jaren ‘90 die als traag en weinig efficiënt werden ervaren. Agile laat zich vertalen als wendbaar en beoogt een ontwikkelmethode te zijn die zich snel aanpast aan veranderende omstandigheden. Het Manifest hanteert de volgende uitgangspunten:

  • Meer aandacht voor mensen en hun onderlinge interactie en minder voor processen en hulpmiddelen
  • Meer focus op werkende software en minder op allesomvattende documentatie
  • Samenwerking met de klant is belangrijker dan contractonderhandelingen
  • Inspelen op verandering is belangrijker dan het volgen van een plan

Zo op het eerste oog uitgangspunten waar niemand op tegen kan zijn. De praktijk blijkt echter weerbarstiger. Soms is de ICT organisatie wel over gegaan tot Agile voortbrenging, maar houdt de rest van de organisatie vast aan de traditionele manier van werken en oude ‘zekerheden’. De focus ligt nog op processen en uitgebreide documentatie. Zo wordt (project)financiering bijvoorbeeld pas beschikbaar gesteld nadat een (uitgebreide) Business Case en Plan van Aanpak zijn opgesteld en goedgekeurd. Soms neemt de realisatie van deze managementproducten maanden in beslag, wat haaks staat op de Agility of slagvaardigheid die veelal nodig is.

Nu biedt het tot in detail uitwerken van een Business Case en Plan van Aanpak etc. wel enige houvast, maar leidt niet perse tot een hogere mate van voorspelbaarheid. Immers, hoe vaak komt het niet voor dat relatief kort na aanvang van een project Business Case, planning, scope en prognoses al worden bijgesteld. Vanuit dat oogpunt is het ‘eindeloos’ uitwerken van dergelijke projectdocumentatie een verspilling van tijd en biedt dit hooguit een schijnzekerheid. Hieraan vasthouden is dus, ook vanuit control perspectief, geen oplossing.

Agile in Control

Maar hoe dan wel? Hoe kun je binnen kort tijdsbestek inzicht verkrijgen in relevante aspecten zoals tijd, kosten en scope?

Bij aanvang van het project

De eerste en waarschijnlijk belangrijkste voorwaarde is het opstellen van een duidelijke opdrachtformulering. Wat moet het project eigenlijk realiseren?

Aan de hand van deze opdrachtformulering stelt het (beoogde) projectteam, samen met de Product Owner, vervolgens op hoofdlijnen vast welke werkzaamheden minimaal moeten worden uitgevoerd om het geformuleerde projectdoel te realiseren. Dit resulteert in het zogenaamde Minimal Viable Product (MVP), het projectresultaat waarmee (nog net) aan de opdrachtdoelstelling wordt voldaan en de ondergrens waar de opdrachtgever genoegen mee neemt.

Het MVP wordt beschreven in features of user stories. De zwaarte van deze de feactures en/of user stories wordt door het (scrum)team ingeschat en uitgedrukt in storypoints. Het (scrum)team maakt ook een eerste inschatting van de verwachte hoeveelheid storypoints die per sprint kunnen worden gerealiseerd, dit heet de velocity.

Aan de hand van de informatie verkregen in deze eerste stap, soms ‘sprint 0’ genoemd, wordt een eerste inschatting gemaakt van tijd en kosten. Het MVP uitgedrukt in storypoints en de velocity bepalen hoeveel sprints het team nodig denkt te hebben om het MVP te realiseren. Grafisch kan dit in een in simpele grafiek worden weergegeven:

Automatische concepten

Omdat een (scrum)team veelal een stabiele samenstelling kent zijn de kosten per sprint (gemiddeld aantal uren x tarief) normaalgesproken goed voorspelbaar. Aantal benodigde sprints x kosten per sprint geven dan de geprognosticeerde totale projectkosten weer.

Uiteraard kent een dergelijke eerste inschatting nog een hoge mate van onzekerheid; het aantal te realiseren story points kan verkeerd zijn ingeschat of de velocity blijkt in de werkelijkheid anders dan vooraf gedacht. Bij een onervaren (scrum)team kan de mate van onnauwkeurigheid aanzienlijk zijn. Maar, zoals hiervoor reeds vermeld, onzekerheid bestaat ook bij een traditionele projectaanpak. Het grote voordeel van een ‘Agile’ inschatting van resultaten, tijd en kosten is echter dat deze veel sneller worden gemaakt.

Gedurende de realisatiefase

Ook gedurende de realisatiefase is het vanuit control perspectief natuurlijk van belang om de voortgang te kunnen volgen en een inschatting te kunnen maken inzake de nog resterende looptijd van het project en de daarmee gemoeide kosten.
Het meten van de voortgang is bij een Agile traject relatief eenvoudig; er wordt immers in principe iedere sprint werkende software opgeleverd. Er kan simpelweg worden geconstateerd of deze werkende software conform (sprint)planning is opgeleverd.
De resterende doorlooptijd en kosten worden op dezelfde wijze bepaald als bij aanvang van het project; het aantal nog te realiseren story points en de velocity bepalen samen resterende doorlooptijd en kosten. Gedurende de looptijd van het project zal de prognose verder in nauwkeurigheid toenemen; het (scrum)team kan immers steeds beter de zwaarte van een feature en user story inschatten en ook de velocity zal naarmate de ervaring van het team toeneemt steeds stabieler worden.

Helaas kan op geen enkele wijze de uitkomst van een project met absolute zekerheid worden voorspeld. Ook bovengenoemde aanpak biedt deze garantie niet. Maar bovenstaande werkwijze biedt de controller wel degelijk de mogelijkheid om ook bij een Agile aanpak snel te kunnen meebewegen en tussentijds zijn beeld te vormen over de status en voortgang van projecten.