Veranderingen moeten steeds sneller worden geïmplementeerd, de time to market moet korter wil het resultaat van een project nog concurrerend zijn. Veel grote projecten falen, sterven een schone dood in de realisatiefase door verouderde ideeën en specificaties.
Daarom wordt tegenwoordig steeds vaker gebruik gemaakt van een agile aanpak bij de uitvoering van projecten. Binnen verschillende branches groeit de methode zelfs in rap tempo uit tot een bepalende, nieuwe standaard voor het realiseren van veranderingen. De overgang van de ‘traditionele’ waterval benadering naar een agile werkwijze roept veel vragen op die te maken hebben met voorspelbaarheid, planning en scope. De claim van agile is dat snel kan worden geanticipeerd op veranderingen en dat het kan worden ingezet wanneer de exacte klantvraag en requirements nog niet helder zijn. Dit klinkt mooi. De vraag is echter in hoeverre al deze veranderingen nodig zijn wanneer op voorhand het gewenste resultaat en plan goed worden uitgedacht. Tegelijk kan men zich afvragen of een agile aanpak wel altijd mogelijk is en zo ja, onder welke condities en welke afwegingen zijn hierbij te maken? In dit artikel zullen we deze kwestie onder de loep nemen en de keuze voor agile of waterval verder duiden.Moeten we wel voorspelbaar willen zijn
Voorspelbaarheid is wat we graag willen omdat we bang zijn dat de benefits tegenvallen, in termen van tijd, geld of kwaliteit. Echter vernieuwing gedijt het best in een omgeving waar je kan experimenteren, waar je even niet voorspelbaar bent, en even een stap opzij doet en zo (bij toeval) een nieuw efficiënter pad vindt, waar je de tijd krijgt voor bijvoorbeeld in de vorm van een Proof of Concept een nieuwe techniek uit te proberen. We moeten niet streven naar sec voorspelbaarheid, maar naar de kans op zoveel mogelijk toegevoegde waarde te leveren over een bepaalde periode? Als je dat uitgangspunt neemt, ga je anders om met je backlog (te realiseren functionaliteit) en geef je medewerkers meer tijd om hun creativiteit de ruimte te geven en met nieuwe ideeën te komen. Nuance hierop is dat dit geen doel op zich moet worden en dat je de juiste balans moet vinden in relatie tot het verwachte resultaat. Suggestie: ruim expliciet tijd in voor experimenteren, verbeter ideeën, met als doel het project te versnellen of meer klantwaarde te bieden.Voorspelbaarheid
Allereerst beschouwen we de afweging om al-dan-niet agile te werken vanuit één van de belangrijkste aspecten van goed projectmanagement: het voorspelbaar laten verlopen van verandertrajecten. Binnen agile wordt de voorspelbaarheid geborgd door diverse mechanismen. Zo zijn er de demo’s en reviews per sprint, waarbij kort cyclisch wordt gemonitord wat de voortgang is en in hoeverre het minimum viable product is behaald. Hierbij kan dus expliciet worden bijgestuurd en ge(her)prioriteerd, waarmee de voorspelbaarheid over de korte termijn wordt geborgd. De planning (voorspelling) over het geheel van een verandertraject wordt vormgegeven via Agile at Scale methoden zoals SAFe en LeSS, waarin op basis van een ‘hoog over’ uitwerking van de probleemanalyse en oplossing een grofmazige planning over de komende maanden wordt bepaald. De vraag is of hiermee een agile aanpak even voorspelbaar kan zijn als de klassieke waterval project aanpak. Binnen de klassieke waterval project aanpak wordt de voorspelbaarheid geborgd door een gedetailleerde(re), door de klant geaccordeerde ‘bouwtekening’ als uitgangspunt te nemen en te werken vanuit vooraf gedefinieerde werkpakketten en projectfaseringen. Veranderende inzichten worden dan via het RFC proces afgewikkeld. In de praktijk blijkt daarbij vaak dat RFC’s aan het eind van een fase of project komen en juist dan relatief duur zijn. Dit omdat er dan (veel) meer moet worden verbouwd, wat extra negatieve budgettaire consequenties heeft. Betekent dit laatste aspect dan dat de waterval methode tot minder voorspelbare resultaten leidt dan de bij hantering van de agile aanpak? Dat is maar net vanuit welk perspectief je er naar kijkt. Een belangrijk onderscheid is namelijk dat agile uitgaat van een vast budget: je geeft niet meer uit dan een bepaalde hoeveelheid geld en realiseert binnen een vaste timebox die zaken die de meeste klantwaarde leveren. Daarmee is de scope dus variabel geworden. Bij een waterval project is deze juist ‘fixed’. Hierdoor blijkt in de praktijk het budget vaak aan verandering onderhevig en wil men via het RFC proces voorspelbaar blijven en bijsturen om te voldoen aan de veranderende vraag vanuit ‘de nieuwe werkelijkheid’.
De nieuwe werkelijkheid
Hier zit een tweede fundamenteel verschil tussen agile en waterval. Agile is namelijk gebaseerd op het paradigma ‘embrace change’ en gaat er vanuit dat over het algemeen aan het begin van een project helemaal niet precies bekend is wat het eindresultaat exact zal (moeten) zijn. In een veranderende en dynamische wereld kan namelijk in de loop van het project ook de perceptie over het eindresultaat veranderen. De waterval methode daarentegen gaat er vanuit dat het beeld over het gewenste eindresultaat al in voldoende mate aanwezig is bij aanvang van het project, waardoor wijzigingen tijdens de realisatie minder waarschijnlijk (en wenselijk) zijn en het eindresultaat alleen via een (veelal tijdrovend) change proces kan worden bijgesteld. Al met al is de constatering dat in zowel de traditionele waterval projectaanpak als in de agile aanpak de voorspelbaarheid wordt geborgd, zij het vanuit verschillende uitgangspunten en beheermechanismen. Het belangrijkste voordeel van agile hierbij is dat door de continue (klant)feedbackloop en de mogelijkheid om in een vroeg stadium gebruik te maken van ‘tussenproducten’ de kans groter is dat het eindproduct beter aansluit bij de veranderende klantwens en in ieder geval de klant eerder duidelijkheid heeft over wat hij precies krijgt.Dus.. dan altijd agile?
Op basis van het voorafgaande zou de conclusie kunnen zijn dat er altijd van agile gebruik moet worden gemaakt. Immers, de voorspelbaarheid wordt in beide methoden geborgd, terwijl de agile aanpak het bijkomend voordeel oplevert van continue klant feedback. Tegelijkertijd is dit voordeel niet in elke context even relevant en kunnen andere overwegingen ertoe leiden om toch voor waterval te gaan. Factoren die hierbij een rol spelen zijn onder meer:Autonomie van het team in besluitvorming
De agile aanpak stelt veel eisen aan de organisatie en het team waarbinnen met agile wordt gewerkt. Belangrijke voorwaarde is dat de besluiten door één persoon (product owner) kunnen worden genomen en dat teams direct toegang hebben tot deze product owner. In de praktijk zien we veel gevallen waarin dit onvoldoende is geborgd. De product owner heeft dan onvoldoende mandaat, is veel tijd bezig zijn/haar achterban te managen, waardoor de besluiten die een agile team nodig heeft om efficiënt te werken niet snel genoeg kunnen worden genomen. Voor elk besluit moet de product owner de stuurgroep of de achterban consulteren. Gevolg is dat vertraging optreedt en de agile aanpak niet datgene brengt wat het belooft. In een situatie waarbij de product owner rol onvoldoende wordt ingevuld en hierdoor het team beperkt autonoom beslissingen kan nemen zal de agile aanpak dus niet de best passende projectmethode zijn.
Omgevingsdynamiek & scope en tijd
Agile geeft de mogelijkheid telkens tussentijds te ervaren, evalueren, leren en bij te sturen. Ideaal dus voor een veranderende omgeving. De vraag is waarom je dit zou willen wanneer de projectcontext als vooronderstelde constante kan worden beschouwd? Helemaal in de situatie waarin de scope en opleverdatum onveranderbaar zijn. Bijvoorbeeld in het geval waarbij nieuwe wet –en regelgeving binnen de kaders van een bestaand systeem moeten worden toegepast. Het why en what zijn volkomen helder, de oplossing kan vooraf worden ingeschat en ingeschaald, waarna de realisatie en oplevering als lineair traject kan worden doorlopen. “De nieuwe werkelijkheid” is dus vooraf exact bekend. Het onnodig gebruiken van agile rituelen leidt in die situaties tot een inefficiënt realisatieproces.Ervaring met agile
De ervaring van het team met agile werken is een belangrijke factor in de afweging al dan niet met agile te gaan werken. Zeker in relatie tot de verwachte duur van het project. Wanneer het project een korte verwachte tijdspanne heeft en er binnen het team weinig ervaring met de agile werkwijze is, dan ligt het voor de hand dat de investeringen in agile vaardigheden niet opwegen tegen de te verwachten baten. Vanuit de theorie wordt hierbij vaak een leerproces van een half jaar genoemd alvorens de ‘agile machine ‘ op stoom is. Dit is niet alleen van toepassing op de teams die de verandering realiseren maar geldt evenzeer voor de beheerverantwoordelijken in de lijn. Door met DevOps teams te werken komen deze werelden bij elkaar.“Sliceability” van de oplossing
Deze randvoorwaarde gaat over de vraag in hoeverre de oplossing of het product is op te knippen in opleverbare deelproducten welke demonstreerbaar en ‘potential shippable’ zijn. In feite, hoe goed leent de oplossing zich om door gebruikers te worden getoetst? Dit heeft onder meer met de tastbaarheid van de oplossing te maken, waarbij het voor de hand lijkt te liggen dat vooral front-end oplossingen zich bij uitstek lenen om getoetst en vervolgens (in prototype) te worden gebruikt. Voor back-end functionaliteiten welke minder makkelijk toonbaar zijn lijkt het werken met agile daarentegen een minder voor de hand liggende keuze te zijn.Omvang van het project
Kleinere project lijken meer geschikt voor agile dan grotere projecten omdat er bij een groot project meer afhankelijkheden gemanaged moeten worden en er meer coördinatie nodig is. Er is dan meer de behoefte om de afhankelijkheden vooraf uit te werken en te specificeren. We zien in de praktijk hier een mengvorm tussen waterval en agile ontstaan waarbij het project als geheel waterval wordt aangepakt en er tijdens de realisatie fasen agile methodieken worden toegepast.Model
Bovengenoemde factoren bepalen mede of een agile dan wel een waterval aanpak meer of minder geschikt is bij de realisatie van een verandering. Zodoende kan het volgende model worden geschetst dat kan helpen bij het besluit al-dan-niet een agile aanpak te hanteren.
