Sinds het ontstaan van Agile zou je verwachten dat we wel beter zouden weten. Maar we blijven we in de meeste gevallen stevig vasthouden aan een watervalaanpak hoewel we inmiddels toch wel de bijbehorende bekende nadelen ervan kennen. En dat terwijl dit in veel gevallen een uitstekende alternatieve aanpak mogelijk is; de Agile-aanpak. Wat me opvalt is dat vele organisaties er niet toe willen overgaan om de projecten volgens Agile te gaan uitvoeren, ondanks de evidente voordelen.
Het doen van projecten op een traditionele watervalmanier is kennelijk een kwestie van gemak. Iedereen kent het; uitgebreid en gedetailleerd requirements verzamelen, een voorstel maken, een functioneel en technisch ontwerp maken, bouwen, testen, opleveren,en klaar. Impliciet nemen we de volgende zaken op de koop toe: veel te veel requirements (onderzoek heeft aangetoond dat we uiteindelijk bijna de helft niet gebruiken), veranderingen in scope tijdens de uitvoering van het project en de gevolgen voor de prijs en opleverdatum, soms weken tot maanden later dan initieel gepland. Tenslotte blijkt achteraf maar al te vaak dat de klant eigenlijk iets ander bedoelde dan er uiteindelijk geleverd wordt.
Waarom dan toch niet voor een alternatief kiezen? De Agile-aanpak adresseert juist die zaken die in de traditionele aanpak (lees waterval) meestal mis gaan. De Agile-aanpak zorgt voor oplevering binnen tijd en budget en een zeer hoge klanttevredenheid. Agile kan prima omgaan met aanpassingen tijdens de uitvoering van het project en het uiteindelijk resultaat sluit nauw aan bij de verwachtingen.
Bovendien wordt bij de Agile-aanpak veel sneller van start gegaan omdat de uitgebreide requirementsfase beperkt blijft tot het verzamelen van high level requirements. De high level inventarisatie van de requirements wordt vervolgens verwerkt tot een projectscope die in een bepaalde tijd, de timebox, geleverd wordt. Ook de doorlooptijd van Agile-projecten is doorgaans veel korter omdat er gefocust wordt op de features die echte business value brengen. De realisatie vindt plaats in zogenaamde iteraties. Iedere Iteratie, met een typisch duur van twee tot drie weken, zorgt voor een werkende oplossing die direct door de business gebruikt en getest wordt. Iedere iteratie zorgt voor een qua functionaliteit rijker wordende applicatie. De applicatie is gereed als de timebox opgebruikt is.
Voorwaardelijk voor de Agile-aanpak is dat de business zelf actief betrokken is bij de projectrealisatie. Dit is beslist een kritische succesfactor. Door zelf actief deel te nemen aan de verwezenlijking, kan en moet de business direct invloed uitoefenen op het uiteindelijke projectresultaat. Op deze manier zijn change requests tijdens de uitvoering in te voegen. Uiteraard zullen andere features, die een lagere prioriteit hebben, moeten wachten op een volgende release.
Deze Agile-manier van werken garandeert een projectresultaat dat zeer nauw aansluit bij de businesswensen. Dat eist echter wel van de business dat zij mede verantwoording nemen voor het eindresultaat. Hoewel deze werkwijze voor sommigen eng lijkt, zijn de resultaten van Agile-projecten beslist kwalitatief beter. Bovendien is er door een goed Agile-ontwikkelplatform te gebruiken, in combinatie met een ondersteunende projectmanagementomgeving, een aanzienlijke tijd- en kostenbesparing te realiseren!
Kortom Agile is niet eng, meer een kwestie van angst voor het onbekende!
Ruud Hochstenbach
Technical account/partner manager
OutSystems
Goed artikel en interessante reacties. Wat ik in Agile mis is het integreren van documentatie en QA mensen in de scrum teams. Want ook zij hebben bij normale methoden en indien niet in vertegenwoordigd in een scrum team te maken met de “Waterfall”. Je kunt hen mee laten doen in het team en ze als vereiste voor de “Definition of done” in een taak zetten, maar hiermee heb je het probleem niet geheel opgelost. Er zijn namelijk per definitie meer ontwikkelaars dan QA en documentatie mensen en dus moeten ze in meerdere scrums tegelijkertijd zitten….. Hoe wordt dit opgelost?
@Gideon,
RUP en DSDM voorzien beide in integratie van documentatie en QA. Maar ook hier moet je documentatie en QA Agile toepassen, doen wat werkt en schrappen wat niet werkt. Een Agile manier van werken is eigenlijk QA in de praktijk, er wordt continu getoetst aan de business doelstellingen, de bouwbaarheid en de kwaliteit van het opgeleverde. Geld en tijd zijn continu meetbaar en te relateren aan werkelijk opgeleverde producten.
Andere methoden hebben ook zo hun eigen QA momenten en documentatiemomenten.
De belangrijkste reden om niet agile te gaan werken is inderdaad de bedrijfscultuur. De business vindt dat software realiseren iets is wat je vooral aan de IT afdeling moet overlaten. Budgethouders willen best tekenen, maar alleen als je ze precies kunt vertellen wat ze krijgen.
Zeker voor IT intensieve bedrijven is overschakelen op agile best een klus. Wat je daar ziet gebeuren is dat er vooraf “ongeveer precies” wordt vastgelegd wat er gerealiseerd gaat worden, zodat de budgethouder een idee heeft wat hij krijgt. Daarvoor zijn indicatieve omvangsbepalingen op basis van COSMIC of FPA prima geschikt en is ook de Outsystems aanpak prima te gebruiken.
Ik ben nog geen project tegen gekomen dat niet “ongeveer precies” wist wat ze zouden gaan realiseren. Je ontwikkelt niet per ongeluk een Mobile App als je aan een uitbreiding van je grootboek begint te werken.
Als je budget vraagt voor 500 functiepunten, dan weet je er vooraf meestal wel zo’n 350-400 zeker. En hoe de rest wordt ingevuld ligt dan aan de vrijheid van het team, maar daar is de klant/opdrachtgever zelf bij.
metrieken.sogeti.nl