Heeft een business case nog wel waarde binnen het Agile werken?

Artikel verschenen op FM.nl

In mijn ervaring is bij opdrachtgevers vaak niet duidelijk hoe zij hun business case van waarde laten zijn binnen het Agile werken. Dankzij een goede business case kun je als opdrachtgever een gefundeerde keuze maken op basis van kosten, de verwachte benefits en de risico’s. De business case helpt je zo besluiten om te starten danwel verder te gaan met een project. Hoe zorg je voor dergelijke besluitvorming over de afweging tussen kosten, risico’s en benefits binnen het Agile werken? Heeft een business case daarin nog wel waarde? Of is de business case overbodig geworden?

De business case kan bij Agile werken veel waarde toevoegen. Mits je als opdrachtgever de business case een andere, meer dynamische invulling weet te geven. Ik licht dit toe door een vergelijking te maken tussen het werken met de business case in het klassieke werken en het werken met de business case bij Agile werken:

De business case in het klassieke werken

Bij klassieke trajecten lijken de business case en het projectplan vaak los van elkaar te staan. De business case gaat over ‘baten voor de organisatie’ en het projectplan gaat over ‘projectresultaat’. In de praktijk lopen beide zaken vaak ver uit elkaar.

De business case bij Agile werken

In tegenstelling tot klassieke ontwikkeltrajecten wordt bij Agile continue gehamerd op klantwaarde of ‘business value’ en wordt geëist om dit zo concreet mogelijk en liefst meetbaar in beeld te brengen. Deze filosofie helpt om in business cases de baten veel scherper te definiëren, de baten te koppelen aan sprints en het baten management beter vorm te geven.

Door het verschil dat ik hierboven schets wordt de business case in Agile trajecten meer een levend document. Als opdrachtgever pak je na iedere sprint de business case erbij om te bepalen of een volgende sprint nog verantwoord is vanuit kosten-baten perspectief. Je hebt daarnaast ook de mogelijkheid om te meten of de implementatie van opgeleverde features in de organisatie ook daadwerkelijk de verwachte baten oplevert. Dus veel eerder dan bij klassieke trajecten kun je al meten of je aannames over de baten klopten en hierop in een volgende sprint bijsturen.

In de traditionele business case maak je een kosten-baten analyse om op basis daarvan het besluit te nemen een project te starten. Kenmerkend voor de Agile manier van werken is dat op voorhand niet exact duidelijk is welke functionaliteit wordt opgeleverd aan het einde van een sprint. Dus ook de baten kunnen vooraf niet exact worden aangegeven. Je zult bij besluitvorming over de start van een project de business case anders moeten inzetten. In de business case moet meer gewerkt worden met een aantal scenario’s dat afhankelijk is van de op te leveren features. De meeste Agile methoden werken volgens het zogenaamde MoSCoW-model om te bepalen welke features de komende sprint zullen worden ontwikkeld en opgeleverd.

Het MoSCoW-model gaat uit van Must haves, Should haves, Could haves en Won’t haves:

• ‘Must have’ features zijn de ondergrens en moeten absoluut worden opgeleverd.
• ‘Should have’ features zijn belangrijk, maar niet vitaal. Het niet leveren van de ‘Should haves’ is pijnlijk maar de oplossing functioneert nog steeds met mogelijke dure workarounds.
• ‘Could have’ features zijn gewenst, maar minder belangrijk. Wanneer ze niet worden opgeleverd heeft dat slechts een beperkte impact.
• ‘Won’t have’ feautures zijn de requirements die niet zullen worden opgeleverd door dit project.

Bij het toepassen van het MoSCoW-model voor sprints wordt grofweg gewerkt met de volgende ervaringscijfers: 60% van de features valt in de ‘Must’ categorie, 20% van de features valt in de ‘Should’ categorie en 20 procent van de features valt in de ‘Could’ categorie. Opdrachtgevers kunnen de onzekerheid over de op te leveren features ondervangen door de Agile-business case op te stellen volgens het MoSCoW-model en de ervaringscijfers in de Agile-business case op te nemen:

1. Eén scenario waarbij alleen de ‘Must’ features worden opgeleverd (60%). Waarbij er extra kosten moeten worden gemaakt voor workarounds en tijdelijke tussenoplossingen met de nodige risico’s.
2. Eén scenario waarbij de ‘Must en Should’ feautures worden opgeleverd (80%).
3. Eén ideaalscenario waarbij de ‘Must, Should en Could’ features (100%) worden opgeleverd.

Vooraf besluit je als opdrachtgever of je bij scenario 1, 2, of 3 akkoord gaat met de business case.

In de praktijk zie ik dat opdrachtgevers het goed inzetten van de Agile-business case lastig vinden binnen de Agile ontwikkelomgeving. Het vraagt immers een dynamischer gebruik van je business case waarin je denkt vanuit verschillende scenario’s én waarbij je actiever stuurt op baten management; een wezenlijk verschil met het werken met een klassieke business cases. Dit vraagt om een nieuwe manier van opdrachtgeverschap. Helaas is er nog te weinig aandacht voor dit vraagstuk. Bij Bisnez ondersteunen wij opdrachtgevers die met deze uitdagingen bij hun ontwikkeltrajecten te maken krijgen.