Waarom u als klant voor Agile ontwikkelen zou moeten kiezen!

stap voor stap werken naar een beter projectresultaat

“Dit had ik zo niet verwacht” is helaas een vaak gehoorde opmerking van klanten bij de oplevering van software met veel maatwerk. Blijkbaar kunnen de verwachtingen van het uiteindelijke opgeleverde product maar moeilijk onderling afgestemd worden. Dit is zeker het geval wanneer er weinig communicatie plaatsvindt tussen de opdrachtgever en de softwareleverancier. Deze situatie komt juist voor indien er voor een fixed-price, fixed-date contract gekozen wordt.

Wat is dan het “probleem” van fixed-price, fixed date opdrachten? Het gevaar van het vooraf “vastzetten’ van functionaliteiten en een eventuele opleverdatum is dat er een schijnzekerheid ontstaat bij de opdrachtgever over het uiteindelijke resultaat. Veel van de “zekerheden” zullen gebaseerd zijn op onvolledige specificaties en aannames op technische haalbaarheid. Deze risico’s van het project worden zichtbaar in de prijs of erger nog, in de kwaliteit van de opgeleverde software. De details van de functionaliteiten en de technische haalbaarheid komen namelijk pas tijdens het ontwikkelen van de software naar voren. De opdrachtgever kan ogenschijnlijk een contract afdwingen maar niet het uiteindelijke resultaat.

Wie bepaalt de volgorde van ontwikkelen?

Het is een feit dat het ontwikkelen van nieuwe software per definitie een complexe onderneming is. Bij de start van het project is het daarom bijna onmogelijk om in groot detail het hele projectplan over de lange periode vast te leggen. Om het project met de “vastgezette” functionaliteiten toch onder controle te houden, wordt het project in een aantal project faseringen opgesplitst. Meestal in deze volgorde:

• beschrijf eerst de volledige functionaliteit,
• ontwikkel op basis van deze functionaliteiten een architectuur,
• begin met de grootste risico’s in de bouwfase en doe dat allemaal in kort-cyclische iteraties.

In de werkelijkheid veranderen de functionaliteiten, zijn de aangenomen architecturele aannames toch niet haalbaar en blijken de grootste risico’s toch in andere delen van het project te zitten.

Kan het ook anders?

De volgorde van een project moet juist in grote mate bepaald worden door de business prioriteiten van dat moment. Dit lijkt in eerste instantie niet de juiste volgorde, maar in de praktijk geeft dit wel de beste resultaten. Een klant zou daarom meer invloed moeten hebben en nemen in een software ontwikkelproject. De invloed zal niet zozeer liggen op het proces, maar juist in de prioriteitstelling. Functionaliteiten en technische haalbaarheid moeten continu getoetst worden met het ontwikkelteam. Dus het ontwikkelteam moet in eerste instantie bouwen wat de opdrachtgever belangrijk vindt.

Hoe kan dit het beste aangepakt worden?

Stel iemand in de rol van ‘Product Owner’ aan. De Product Owner is iemand met uitgebreide kennis van het product en heeft het mandaat van een stuurgroep om beslissingen te mogen nemen. Laat hem of haar onderhandelen met het gehele team om vast te stellen welke functionaliteiten haalbaar zijn. Laat een coach het proces bewaken en geef hem de vrijheid om belemmeringen die ontstaan weg te nemen. Wat haalbaar is en in welke tijd (meestal 30 dagen) moet vooraf met elkaar vastgesteld worden. Wat haalbaar is, kan een team met zijn ontwikkel-specialisten uitstekend bepalen.

De timebox!

Bij de start van een timebox bespreekt de Product Owner de visie en de top prioriteiten met het gehele team. Het team is direct op de hoogte en kan gerichte vragen stellen indien er onduidelijkheden zijn. Het team zal vervolgens de keuze maken welke functionaliteiten voor de komende 30 dagen haalbaar zijn. Voordeel is dat het team zelf de keuze maakt wat haalbaar is en zal daarom extra gemotiveerd zijn om deze functionaliteiten tot een goed einde te brengen. Belangrijk is dus om heel duidelijk de doelen van de timebox vast te stellen en vast te stellen wanneer iets klaar is. Aan het einde van de timebox zal de gebouwde software en opleverdocumenten direct aan de opdrachtgever getoond worden. Er wordt dus tussentijds inzichtelijk gemaakt wat er bereikt is.

Is dit dan Agile ontwikkelen?

Ja, deze vorm van ontwikkelen is een Agile ontwikkelmethodiek. In de basis gaat het om de volgende uitgangspunten:

• niet in beton gegoten contracten, maar directe klant onderhandelingen.
• noodzakelijke veranderingen voorrang geven boven het projectplan.
• niet de nadruk op tools en processen, maar juist op individuele interactie.

Met een aantal eenvoudige regels kunnen de verwachtingen tussen de opdrachtgever en een software leverancier eenvoudig en sterk verbeterd worden. De opdrachtgever weet exact wat er per timebox opgeleverd gaat worden. De softwareleverancier kan eenvoudig het proces aanpassen en de noodzakelijke wijzigingen in het product aanbrengen.

Uiteraard is het noodzakelijk om een aantal regels met elkaar af te spreken. Deze regels zijn nodig om de samenwerking en verwachtingen op een hoog peil te brengen en te houden. De beste manier om bovenstaande aanpak te realiseren is om de methode ‘Scrum’ te gebruiken. Scrum levert een uitstekend raamwerk waarin de bovenstaande regels vastgelegd zijn. Scrum kan de productiviteit en kwaliteit sterk verhogen, juist omdat de opdrachtgever nu een voorname rol in het proces heeft. Nogmaals de rol van de opdrachtgever ligt niet in het proces en de dagelijkse voortgang, maar juist in het stellen van de business prioriteiten en het gezonde spanningsveld tussen de opdrachtgever en de softwareleverancier.

Wat levert het organisaties op?

De voordelen op een rijtje:

• De opdrachtgever kan direct met het team communiceren. Het levert de opdrachtgever grote invloed op welke, belangrijke, functionaliteiten gebouwd moeten worden. Voor iedere timebox kan de opdrachtgever een nieuwe geprioriteerde lijst samenstellen. De opdrachtgever bepaalt daarmee de scope van het project en laat veranderingen die nodig zijn in de lijst terugkomen.
• Door deze directe communicatie van het team weet de opdrachtgever precies welke functionaliteiten in de komende timebox opgeleverd gaan worden. De opdrachtgever zal aan het einde van de timebox een live demo krijgen met daarin de functionaliteiten die voldoen aan de Definition of Done (DoD).
• Door het onderhandelen met het team weet de opdrachtgever welke globale werkzaamheden er nodig zijn om de gekozen functionaliteiten te realiseren. Onbelangrijke functionaliteiten en details kunnen direct weggefilterd worden.
• De opdrachtgever loopt minder risico met de keuze van een leverancier. Per timebox kan de opdrachtgever bepalen wat er gebouwd moet worden. De opdrachtgever krijgt bruikbare tussenresultaten en kan een project (zonder total-loss van het project tot nu toe) te allen tijde stoppen als het niet meer aan de verwachtingen voldoet.

We ontkomen er niet aan door te zeggen dat we als Macaw alleen maar op de Agile manier projecten uitvoeren. Er zitten bij ons ook fixed-price, fixe-date projecten bij. Echter, we omarmen de Agile manier en staan hier ook achter. Daarom proberen we in onze projecten wel zoveel mogelijk onze klanten op deze manier met ons te laten werken. Onze ervaring is dat met Agile betere projectresultaten bereikt worden wat onder andere ook resulteert in een hogere klanttevredenheid.