Komt een man bij de fietsenzaak en zegt: ik wil meedoen aan de Ronde van Spanje, lever mij de beste fiets! Goed, zegt de fietsenmaker, dan gaan we die agile voor je maken. De man trekt een sprintje op een bestaand model en de fietsenmaker maakt het perfecte voorwiel. De man maakt nog een sprintje en de fietsenmaker maakt het tweede wiel. Hij komt erachter dat er lucht om het wiel moet en hij maakt twee banden. Een dag voor de Vuelta is de fiets klaar. Helemaal tiptop. Eén probleem: er zit geen stuur op. Oeps.
De fiets is drie keer zo duur geworden dan die ene die al klaar in de hoek stond, met stuur. Op die ene supersonische versie zonder stuur zitten wel geweldige onderdelen, maar hij moet de Ronde aan zich voorbij laten gaan. Pijnlijk, maar wie z’n schuld is het nu eigenlijk? En hoe had dit voorkomen kunnen worden?
Het op een agile manier ontwikkelen van software raakt tegenwoordig behoorlijk ingeburgerd in steeds meer organisaties die software ontwikkelen. Waarom ook niet? Vroeger werden projecten op een meer traditionele (‘waterval’) manier ontwikkeld, maar de lange time-to-market, de matige betrokkenheid van de gebruikers en de beperkte mogelijkheden om tijdens het project veranderingen door te voeren, bleken voor veel organisaties een belangrijke reden om de afgelopen jaren één van de agile methodieken te implementeren.
In agile uitgevoerde projecten is de gebruiker via een speciale projectrol, de product owner, vanaf het begin betrokken. Sterker, de product owner bepaalt de prioritering en beslist in feite wat op welk moment wordt gerealiseerd. In agile projecten wordt iteratief gewerkt in sprints van twee tot vier weken. Binnen deze sprints worden alle benodigde activiteiten uitgevoerd, dus vanaf requirements analyse tot en met de tests en implementatie. Volgens de theorie moet er na iedere sprint een product zijn dat voldoet aan de ‘definition of done’ en dat zonder problemen in productie genomen kan worden. Agile ontwikkelen zorgt ervoor dat de gebruikers optimaal betrokken zijn en dat de functionaliteit die voor de gebruikers het belangrijkst is zo snel mogelijk beschikbaar is.
Er zit echter een nadeel aan de agile filosofie: het management heeft minder grip op het project en de voortgang van de teams wordt minder voorspelbaar. Agile teams staan erom bekend dat ze nauwelijks gebruik maken van professionele begrotingstechnieken en dat ze vaak gebruik maken van story points als schattingsmethodiek. Story point schattingen zijn echter per definitie zeer subjectief en metrieken gebaseerd op deze eenheid kunnen alleen in het team zelf gebruikt worden. De story points methodiek is een zeer nuttige methodiek om te plannen hoeveel welke backlog items er in een sprint gerealiseerd kunnen worden, maar de methodiek is niet bruikbaar om te begroten of de applicatie (het product) die over bijvoorbeeld zes maanden in productie is, voldoet aan de verwachtingen of de noodzaak. Zoals de montage van een stuur.
Simpel gesteld, is het beoogde team groot genoeg om de gewenste functionaliteit te realiseren in de gewenste doorlooptijd en met de gewenste kwaliteit? Het starten met een te klein team kan immers makkelijk leiden tot onoverbrugbare achterstanden.
Zeker ook voor agile projecten is het belangrijk een goed onderbouwde parametrische begroting op te stellen op basis van een ISO/IEC omvangmaat van de functionaliteit, relevante historische data en parametrische modellen. Bij voorkeur moet de begroting worden gebaselined in een ‘Basis of Estimate for Software services’ (zoals o.a. gepubliceerd door Nesma). Niet iedereen heeft hiertoe de kennis en de mogelijkheden, maar wij helpen u graag.
Als dit niet haalbaar is, dan is het in ieder geval verstandig om een reality check te laten uitvoeren op de afgegeven begroting, zeker als het belangrijk is dat er op een bepaald moment een product staat dat aan bepaalde voorwaarden moet voldoen. METRI beoordeelt de realiteitswaarde van uw begroting door gebruik te maken van haar uitgebreide database met de project data van vele afgeronde agile uitgevoerde projecten. Hierdoor kunt u de maatregelen nemen die nodig zijn om het gewenste product op het gewenste moment opgeleverd te krijgen en daarmee krijgt u grip op het resultaat. En hoeft niemand met losse handen te fietsen.