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 baten. De business case helpt je zo besluiten om te starten dan wel verder te gaan met een ontwikkeling. Hoe zorg je voor besluitvorming over de afweging tussen kosten en baten binnen het Agile werken? Heeft een business case daarin nog wel waarde? Of is de business case overbodig geworden?

Aan de hand van een goede business case kan de opdrachtgever een keuze maken op basis van kosten en verwachte baten. Zeker om de baten scherp te krijgen moet er tijdens het opstellen van de business case duidelijk zijn welke features worden opgeleverd. Immers aan de hand van deze features kunnen de baten worden bepaald…en daar ‘wringt de schoen’ bij Agile werken.

Een dynamische invulling van je business case
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.

Het MoSCoW-model

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, waarbij de ‘Must have’ de ondergrens is en wordt gezien als het Minimal Viable Product (MVP). Het niet leveren van de Should haves is pijnlijk maar de oplossing functioneert nog steeds met vaak kostbare ‘workarounds’

Bij Agile werken en MoSCoW worden de volgende ervaringscijfers gebruikt: circa 60% van de features vallen in de M-categorie, 20% in de S en 20% in de C. Opdrachtgevers gaan niet op voorhand uit te van 80% maar laten een aantal scenario’s uitwerken, met één scenario voor 'alleen Must’ (60%) het zogenaamde Minimal Viable Product (MVP) en één scenario voor Must én Should (80%) en een ideaalscenario waarbij Must, Should en Could dus 100% van de features wordt opgeleverd. Juist bij de uitwerking van het scenario met alleen maar de Must moet duidelijk worden wat de extra kosten en risico’s zijn van het organiseren van ‘workarounds’ en dure tussenoplossingen. Besluitvorming over wel of niet te starten vindt dan plaats op het scenario Must.

Dit vraagt wel na besluitvorming een actieve sturing van de opdrachtgever. Immers het resultaat is de grote variabele bij Agile werken. Door de resources (en daarmee het budget) en de tijd (in een time box) vast te zetten is de enige variabele nog de op te leveren features. Om dit te ondervangen is het MoSCoW model toegevoegd, maar dat geeft “alleen maar” een prioritering, geen resultaatgarantie. Met de prioritering wordt vervolgens het risico gemitigeerd dat het minimale (de Must Have) gerealiseerd wordt terwijl de opdrachtgever aan de hand van terugkoppeling op de iteraties onderweg kan bijsturen in het resultaat.

Door de business case op die manier in te richten wordt de business case ook meer een levend document waar de opdrachtgever bij iedere ‘iteraties’ de business case ter hand neemt en bepaalt A. Of verder werken nog verantwoord is vanuit kosten/baten perspectief en B. Of, bij oplevering van S en C onderdelen, de hogere baten ook worden gerealiseerd en er actief gestuurd wordt op batenrealisatie.

Conclusie

Wat betekent dit voor de business case en de besluitvorming over de afweging tussen kosten en baten?  Is de business case overbodig geworden? In mijn ogen is dat zeker niet het geval. Agile werken en een goede business case kunnen elkaar versterken op een aantal onderdelen.

• Allereerst wordt bij Agile werken veel meer dan bij klassieke ontwikkelmethoden heel nadrukkelijk gezocht naar de aansluiting gezocht met ‘business goals of business value’. Bij klassieke methoden staat het projectresultaat centraal en is er weinig aandacht voor de ‘waarde of baten voor de organisatie of het realiseren van organisatiedoelen. Deze relatie wordt alleen in de business case gelegd maar kom je verder niet meer tegen in de projectplannen.
• Ook wordt er bij Agile gehamerd op korte ontwikkel iteraties, waarbij de resultaten zo snel mogelijk in productie worden genomen, zodat e baten snel kunnen worden gerealiseerd. Op die manier kan al tijdens de duur van het project gestuurd worden op het realiseren van baten en als dit afwijkt hierop ‘in volgende iteraties’ worden bijgestuurd. Bij klassieke methoden was de oplevering van het projectresultaat aan het einde van het project. De stuurgroep en het projectteam worden ontbonden, pas daarna, de opdrachtgever is al met hele andere zaken bezig, wordt er als het goed is nog nagedacht over baten realisatie. Bij klassieke methoden zijn mogelijke baten alleen maar belangrijk bij besluitvorming over het project. Als het project eenmaal gestart is en zeker na afloop lijkt niemand zich meer zorgen te maken over de oorspronkelijke doelstelling van het project.
• De business case en Agile werken versterken elkaar ook door het incrementele karakter van Agile. Bij iedere tussentijdse oplevering worden ‘werkende oplossingen’ in productie gebracht. Dat betekent ook dat na iedere oplevering kan worden bepaald of de baten worden gehaald, zodat kan worden bijgestuurd voor het volgende increment. Bij business cases voor klassieke projecten waren de features en daarmee ook de baten vast. Tussentijds kon de business case alleen herijkt worden op basis van tegenvallende kosten of verlenging van de doorlooptijd. Aan de stuurgroep werd een bijna onmogelijke vraag gesteld: ‘De baten zijn nog gelijk, de projectkosten zijn met X% toegenomen. Als we dit van tevoren hadden geweten hadden we het project nooit gestart, moeten we nu het project voortzetten of stopzetten’. Het gebeurt vrijwel nooit dat de opdrachtgever zijn verlies neemt en stopt. Meestal wordt knarsetandend extra budget vrijgemaakt.

_{Door Peter Noordam.
Hij is één van de grondleggers van Bisnez en organisatieadviseur op het raakvlak van business en ICT. Hij ondersteunt opdrachtgevers bij het goed inzetten van de Agile business case.}