Kostenbeheersing in Scrum: creëer waarde en grip

Als ontwikkelaar heb ik geleerd dat niets zo moeilijk is als het begroten van grote softwareprojecten. Een van de eerste projecten van Ambrero, zo’n 20 jaar geleden, was een EPD (Elektronisch Patiëntendossier) voor Stichting CASA. We schatten de eerste fase op ongeveer 100 uur, maar het project werd veel groter. Toch deden we het goed, want CASA bleef lang klant. In deze blog deel ik mijn ervaring met kostenbeheersing in Scrum.

We zijn veel beter geworden in het inschatten van werk, maar het blijft lastig. Bij maatwerkprojecten zijn er geen exacte specificaties, dus iedereen, inclusief de klant, maakt veel aannames.

Waterval ontwikkelmethode voor meer zekerheid?

Sommigen vergelijken het met de bouwsector: een aannemer maakt toch ook een exacte prijscalculatie? Voor software is dat moeilijker. Aannemers werken met standaardproducten en bouwtekeningen. Voor software moet je precies definiëren wat je wilt en een specialist inhuren voor de specificatie. Dit kost tijd en geld, maar geeft meer zekerheid over doorlooptijd en budget.

Uitgewerkte specificaties garanderen echter geen succes. In de bouw zijn dingen vaak zichtbaar en meetbaar, bij software niet. Specificaties beschrijven de verwachte output, maar details zijn lastig vast te leggen. Vaak lopen ontwikkelaars tegen scenario’s aan die niet zijn voorzien. Bovendien kunnen specificaties verschillend geïnterpreteerd worden en de behoeften van gebruikers veranderen. Zeker bij het waterval model waarbij de periode tussen specificeren en ontwikkelen behoorlijk lang is. Met deze ontwikkelmethode kun je in de tussentijd slecht meten of de interpretatie van het team correct is en of je aansluit bij gebruikersbehoeften.

“Hofstadter’s Law “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Agile en Scrum voor meer flexibiliteit

Het watervalmodel wordt door de meeste IT-bedrijven verlaten. Tegenwoordig kiezen bedrijven voor Agile. Dit betekent: korte stappen richting je doel, regelmatig evalueren en leren van elke stap. De methodiek die we gebruiken is Scrum. In plaats van uitgebreide specificaties, werken we met een Product Backlog. Functionaliteiten die op korte termijn gemaakt moeten worden, zijn helder; verderop wordt het vager.

Dit geeft flexibiliteit om functionaliteit te ontwikkelen die op dat moment waarde creëert. Daarnaast kun je snel inspelen op veranderingen binnen je bedrijf. Zo kun je in kortere tijd een productierijp systeem opleveren, wat twee voordelen heeft:

• Testresultaten van echte gebruikers
• Het product verdient zichzelf sneller terug

Het grootste voordeel van Scrum is de samenwerking tussen opdrachtgever (Product Owner) en het ontwikkelteam. Er is een korte feedback-loop, stakeholders zien iedere twee weken resultaat en kunnen feedback geven. Dit verbetert de kwaliteit en acceptatie van het product.

Projectfactoren Goed, Snel, Goedkoop – kies er twee

Scrum heeft ook nadelen. De stip op de horizon blijft vaag en het is moeilijk om hier een datum of budget aan te koppelen. Hierdoor kan de opdrachtgever denken dat het project een bodemloze put is. Dus hoe krijg je meer zekerheid?

Met deze 3 factoren:

• Scope; welke functionaliteit gaan we ontwikkelen?
• Budget; hoeveel gaat het kosten? Oftewel, hoeveel mensen werken aan het project.
• Tijd; wanneer is het af?

Voor kostenbeheersing in Scrum kun je er maar twee tegelijk fixeren. Enkele scenario’s:

Scope en Tijd vast, Budget variabel
De leverancier garandeert dat hij op een bepaalde datum een bepaalde hoeveelheid functionaliteit af heeft. De enige manier waarop hij dit kan garanderen is als hij flexibel mag zijn in de inzet die hij op het project zet. Budget is dus variabel.

Budget en Tijd vast, Scope variabel
De leverancier garandeert een bepaalde inzet (budget) over een bepaalde periode, maar geeft geen garanties over de hoeveelheid functionaliteit die ontwikkeld wordt.

Budget en Scope vast, Tijd variabel
De enige variabele is tijd, oftewel snelheid van ontwikkelen. Sneller ontwikkelen heeft een negatief effect op de kwaliteit en onderhoudbaarheid. Op de lange termijn is dit de duurste optie.

Alle factoren fixeren is niet realistisch. Een fixed-price per Sprint kan wel. Voor een Sprint staan de eisen vast, waardoor er geen risico op interpretatieverschillen is. Een compleet Product Backlog helpt ook bij budgetoverwegingen. Hiermee kan het team al een voorlopige schatting maken over de gevraagde functionaliteit om mee te nemen in budgetoverwegingen.

Business Value creëren

Voor meer zekerheid op projectniveau is een Fixed Budget, Fixed Tijd scenario een goede optie. Het projectteam werkt hard om samen met de Product Owner maximale Business Value te creëren. Dit dwingt het team en de klant om pragmatisch en waarde-gedreven te werken.

Bovenstaand plaatje illustreert hoe dat in zijn werk gaat. In de eerste fase nemen we risico’s weg door visievorming en het ontwikkelen van prototypes. Daarna richten we ons op Business Value. Functionaliteiten die de meeste waarde toevoegen, worden als eerste ontwikkeld. Naarmate het project vordert en de toegevoegde waarde per Sprint afneemt, kan de klant het project afronden (trimming the tail).

Kostenbeheersing in Scrum; communicatie is het sleutelwoord

Kostenbeheersing blijft een uitdaging, met of zonder Scrum. Budgetbewaking is een gezamenlijke verantwoordelijkheid. Vooral bij gebrekkige communicatie gaat het vaak mis. Blijf voortdurend in dialoog, bespreek voortgang, verwachtingen en budget. Communicatie is en blijft het sleutelwoord!!