Agile of Waterfall (Sequentieel) – wat is beter?

Als agile practitioner, trainer, coach en consultant zou je misschien verwachten dat ik zeg: "Agile is de enige manier om te slagen—betaal me veel geld en ik laat je zien waarom!"

Maar hier is de waarheid (spoiler alert): ik kan deze vraag alleen beantwoorden met "het hangt ervan af." Dat klinkt misschien vaag, maar het is vaak het eerlijkste en meest waardevolle antwoord.

Uiteindelijk kun alleen jij beslissen wat het beste is voor jouw project en organisatie, gebaseerd op de drijfveren en beperkingen die jij beter begrijpt dan ik. Ik hoop dat dit artikel je helpt om het zelf uit te zoeken.

Laten we beginnen door te kijken naar de kernideeën achter elke aanpak.

Waterfall projectmanagement volgt een sequentiële, voorspellende aanpak. De omvang is meestal vastgesteld, en de oplossing wordt vaak volledig gespecificeerd voordat de ontwikkeling begint. Oplevering kan plaatsvinden als één grote 'big bang' of in fasen, waarbij elke fase een belangrijk onderdeel van de totaaloplossing oplevert.

Een typische waterval-methode omvat deze stappen:

1. Analyse: Identificeer, documenteer, kom overeen over en keur de vereisten en eventuele kwaliteitsnormen goed. In IT omvat dit niet-functionele vereisten.
2. Ontwerp: Maak en keur een gedetailleerd ontwerp goed dat voldoet aan de overeengekomen vereisten en kwaliteitscriteria.
3. Bouw: Construeer de oplossing volgens het ontwerp, waarbij ervoor wordt gezorgd dat deze voldoet aan alle gespecificeerde vereisten en kwaliteitsnormen.
4. Test: Test de oplossing grondig om te bevestigen dat deze voldoet aan de overeengekomen vereisten, het ontwerp en andere kwaliteitscriteria.
5. Implementatie: Zet de oplossing in gebruik om de beoogde bedrijfswaarde te leveren.

Elke stap moet worden gepland en van middelen worden voorzien, waarbij alle activiteiten duidelijk geïdentificeerd, geschat en toegewezen zijn. In veel gevallen worden activiteiten opgebroken in gedetailleerde taken en vastgelegd in de vorm van een GANTT-grafiek. Voor een gefaseerd project moeten eerst een analyse en ontwerp op hoog niveau plaatsvinden om de context en reikwijdte voor elke fase vast te stellen.

De waterval-aanpak vereist een voorspellende stijl van projectmanagement waarbij elke stap documentatie oplevert die schetst wat de volgende stap moet doen.

Al het werk voor elke stap wordt gepland op basis van de verwachting (op zich een voorspelling) dat de uitkomst zal overeenkomen met wat werd afgesproken. Correct goedgekeurde documentatie is de belangrijkste manier om de intentie van het project te communiceren aan iedereen die betrokken is of erdoor wordt beïnvloed.

Projectbeheersing berust op het aantonen dat het geleverde werk overeenkomt met de documentatie van de vorige stap, evenals het volgen van het goedgekeurde plan voor de huidige stap. Eventuele wijzigingen moeten door een formeel proces waarbij de documentatie wordt herzien en goedgekeurd. Idealiter wordt de documentatie regelmatig geëvalueerd om ervoor te zorgen dat deze nog steeds voldoet aan de evoluerende bedrijfsbehoeften.

Wijzigingen kunnen worden geïdentificeerd uit het werk in de latere stappen van het watervalproces. Bijvoorbeeld wanneer problemen worden ontdekt tijdens de Teststap die een mismatch identificeren tussen gespecificeerde vereisten en de huidige bedrijfsbehoefte. Analyse van die mismatch is vereist waarbij eventuele overeengekomen wijzigingen door de waterval naar beneden cascaderen om uiteindelijk opnieuw getest te worden.

De perceptie van succes bij waterfall heeft daarom de neiging gerelateerd te zijn aan hoe goed de voorspelling overeenkomt met de werkelijke behoefte en hoe nauw de resultaten aansluiten bij de voorspelling wat betreft budget, tijdlijnen en kwaliteit.

Het watervalmethode lijkt in eerste instantie misschien eenvoudig, maar blijkt vaak complexer dan verwacht. Het steunt zwaar op documentatie, gebruikt hiërarchische goedkeuringen en volgt gecentraliseerde planning. Omdat het gedetailleerde vooraf-documentatie en planning vereist, kan het proces ingewikkeld worden, waarbij veel gerelateerde onderdelen met elkaar verbonden moeten worden om het gewenste resultaat te bereiken.

Voordelen:

• Overzichtelijke Structuur: De stapsgewijze aanpak is gemakkelijk te begrijpen voor projectmanagers en uit te leggen aan belanghebbenden.
• Voorspelbare Planning: Uitgebreide analyse en ontwerp aan het begin ondersteunen duidelijke en precieze planning en budgettering.
• Eenvoudige Opvolging: Voortgang kan worden gemonitord door documentatie (die toont hoe mijlpalen worden behaald) en gecontroleerd tegen het plan (om te bevestigen dat taken op tijd en binnen budget worden voltooid).

Nadelen:

• Complex Verandermanagement: Het afhandelen van noodzakelijke veranderingen kan omslachtig zijn, waardoor teams soms het proces volledig omzeilen, wat resulteert in verlies van controle.
• Late Detectie van Problemen: Ontwikkeling in grote stappen met testen die grotendeels aan het eind van het proces plaatsvinden, kan problemen te laat aan het licht brengen, wat onverwachte vertragingen en kostenoverschrijdingen veroorzaakt.
• Verminderde focus op Bedrijfswaarde: De uitgebreide vooraf-analyse en documentatie bieden geen directe bedrijfswaarde; ze bestaan uitsluitend om het proces te begeleiden.

Hoewel het nog steeds een duidelijk proceselement heeft om ontwikkeling vorm te geven, richt een agile benadering van projectmanagement zich meer op mensen dan op processen. Voorbereidend werk is bewust licht gehouden, waarbij alleen de globale oplossing en het plan vorm krijgen terwijl details tot het laatste verantwoorde moment voor ontwikkeling worden uitgesteld. Doorgaans verloopt de ontwikkeling functie voor functie binnen "Sprints" van vaste lengte.

Projectdeelnemers – belangrijk hierbij is dat zakenmensen binnen de ontwikkelteams worden betrokken – werken gedurende het hele project samen. Ze bouwen kleinere incrementen dan bij de traditionele waterval-aanpak, met behulp van een iteratief proces.

Elke iteratie omvat analyse, ontwerp, bouw, testen en idealiter implementatie, in cycli die slechts een paar uur kunnen duren of zich over meerdere dagen of weken kunnen uitstrekken (in plaats van de weken of maanden die vaak bij waterval worden gezien). Het doel is om delen van de oplossing zo snel mogelijk te implementeren zodra ze waarde kunnen leveren.

Ontwikkeling steunt op de gedetailleerde samenwerking van deskundige en bekwame individuen die door de organisatie gemachtigd zijn om een oplossing te ontwikkelen die voldoet aan de zakelijke behoefte.

Deze individuen definiëren de details van de behoefte voordat ze het vereiste ontwikkelingswerk plannen. Vervolgens voeren ze dit plan uit, waarbij ze het voortdurend aanpassen om gefocust te blijven op het leveren van maximale waarde. Voor echte wendbaarheid volgen teams vaak waarden zoals die te vinden zijn in Scrum, wat momenteel de meest toegepaste agile leveringsaanpak is.

De iteratieve aanpak is zeer tolerant voor verandering omdat het gedetailleerde planning uitstelt tot het laatste verantwoordelijke moment, gebruikmakend van real-time data en korte planningscycli. In plaats van volledig voorspeld te worden in een vroeg stadium, ontstaat de oplossing geleidelijk om te voldoen aan behoeften die geschetst waren (maar niet nauwkeurig gedefinieerd) aan het begin van het project.

Door prioriteit te geven aan hoofdvereisten vooraf en de belangrijkste eerst aan te pakken, kunnen agile teams strakke controle behouden over deadlines en budgetten. De ontwikkeling eindigt simpelweg op een gecontroleerde manier zodra tijd- of budgetlimieten bereikt zijn, waarbij alleen de minst waardevolle items uitgesloten worden van de uiteindelijke oplevering.

Omdat ontwikkelingscycli kort zijn (meestal rond de twee weken) en vastgesteld, is het logisch om succes te meten door de incrementele levering van waarde op een voorspelbaar tempo.

De iteratieve en incrementele benadering, met korte cyclustijden gedreven door bevoegde zelforganiserende teams, lijkt vaak chaotisch. Maar bemand met competente, samenwerkende, gedisciplineerde mensen is het zeer efficiënt en effectief. Dat gezegd hebbende, het risico van het gebruik van een agile benadering met individuen die niet competent, samenwerkend en gedisciplineerd zijn, leidt zeer waarschijnlijk tot falen. Dit maakt toezicht (maar niet management) essentieel totdat de teams hun collectieve vermogen om te leveren hebben aangetoond.

Voordelen:

• Iteratieve Ontwikkeling: Snelle ontwikkelingscycli met mogelijkheden voor samenwerking en voortdurende feedback vermindert het risico van het bouwen van een oplossing die niet voldoet aan echte behoeften.
• Incrementele Waardeoplevering: Het leveren van tastbare waarde in korte intervallen verbetert de algehele controle door voortgang makkelijker te volgen en corrigerende actie makkelijker te identificeren.
• Aanpasbaarheid: Details tot het laatste verantwoorde moment overlaten zorgt ervoor dat oplossingen kunnen ontstaan om huidige in plaats van voorspelde behoeften te vervullen.

Nadelen:

• Kan ongestructureerd lijken: Vooral voor degenen die gewend zijn aan procesgebaseerde controles. Het is niet goed geschikt voor managers en leiders met hoge controlebehoeften.
• Hoge competentie en samenwerking van alle betrokkenen: Leiders hebben vertrouwen nodig om te vertrouwen en competentie om hun samenwerkende teams te empoweren.
• Potentieel voor chaos en falen: Teams die geen bewezen competentie en professionaliteit hebben kunnen falen zonder goed toezicht.

Opmerking: de hierboven beschreven nadelen gelden voor teams of organisaties die nieuw zijn in de agile manier van werken. Waar er echte competentie met wendbaarheid is, is het moeilijk om universele nadelen te identificeren, hoewel contextspecifieke nadelen zeer wel kunnen ontstaan.

De belangrijkste verschillen tussen een agile benadering en een waterval benadering kunnen worden samengevat in 5 dimensies:

1. Oplossingsontwikkeling – Emergent vs. Gespecificeerd:

• Agile: De oplossing ontwikkelt zich in de tijd om te voldoen aan veranderende bedrijfsbehoeften. Details evolueren dichter bij de ontwikkeling, waardoor de oplossing flexibel blijft.
• Waterval: De oplossing wordt vooraf gedefinieerd om te voldoen aan een verwachte behoefte. Zorgvuldige change control is nodig om de afstemming met veranderende behoeften te behouden.

2. Projectdeelnemers – Collaboratief en Cross-Functioneel vs. Geïsoleerd & Gespecialiseerd:

• Agile: Teamleden werken samen met brede rollen en doen alles wat nodig is om hun gedeelde doel te bereiken. Het doel is om communicatie via documentatie te vermijden en overdrachten waar mogelijk te minimaliseren.
• Waterval: Hoewel vaak enige mate van samenwerking wordt gezien, is dit vaak gericht op specifieke en gespecialiseerde activiteiten (zoals requirements gathering). Projectdeelnemers neigen naar de geïsoleerde Industrial Engineering benadering die het denken van de 20e eeuw domineerde, typisch met communicatie en controle beheerd via documentatie.

3. Management – Zelforganiserend vs. Beheerd:

• Agile: Teams organiseren en managen zichzelf, beslissen hoe taken te voltooien en passen processen aan terwijl ze leren.
• Waterval: Teams ontvangen doorgaans instructies van managers, die beslissen wat er gedaan moet worden, door wie, en wanneer. Het detailniveau van deze instructies kan echter variëren op basis van het project of de managementstijl.

4. Verandering – Omarmd vs. Weerstand:

• Agile: Omdat teams werken naar brede doelen zonder elk detail vooraf te definiëren, verwelkomen ze veranderingen wanneer nieuwe behoeften of inzichten ontstaan.
• Waterval: Change management is bureaucratisch en kostbaar omdat het grondige analyse, documentatie en goedkeuring vereist. Als gevolg hiervan werkt het vaak als een barrière voor noodzakelijke verandering.

5. Controle gebaseerd op: Professionele Discipline vs. Procesnavolging

• Agile: Vertrouwt sterk op de competentie, discipline en zelforganisatie van het team. Teamleden maken afspraken met elkaar en hebben collectief eigenaarschap van taken en oplossingen.
• Waterval: Gebruikt gedetailleerde planning en duidelijke instructies. Ieders rol wordt vooraf gedefinieerd en de projectmanager coördineert activiteiten. Succes hangt af van het volgen van het plan en de processen zoals ontworpen.

Zoals ik eerder al zei, het hangt ervan af…

In de complexe wereld van vandaag is het onwaarschijnlijk dat je een volledig agile of volledig waterfall project runt. Vaker ontdekken teams dat wat beweeglijkheid waarde kan toevoegen aan een voornamelijk waterfall project, terwijl sommige waterfall elementen zinvol zijn in een verder agile project. Deze mix wordt vaak een hybride aanpak genoemd, die zich bevindt in het grijze gebied tussen de twee uitersten.

Dus, de echte vraag van een projectmanager is niet "Welke zuivere methode moet ik kiezen?" maar eerder "Waar op het spectrum moet mijn project zitten?" Agile methoden gedijen in omgevingen met hoge volatiliteit, onzekerheid, complexiteit en ambiguïteit (VUCA). Daarentegen werken waterfall benaderingen doorgaans het beste waar dingen stabieler, zekerder, eenvoudiger en duidelijker zijn.

Het Cynefin framework kan je helpen om te bepalen waar jouw project op dit spectrum zou kunnen vallen.

Cynefin, uitgesproken als kuh-nev-in, is een Welsh woord dat de meervoudige, verweven factoren in onze omgeving en onze ervaring aanduidt die ons beïnvloeden (hoe we denken, interpreteren en handelen) op manieren die we nooit volledig kunnen begrijpen.

In een erkende oversimplificatie van het Cynefin Framework, kan de omgeving waarin we werken – in dit geval onze projectomgeving – op een spectrum worden geplaatst dat wordt gekenmerkt als duidelijk, ingewikkeld, complex of chaotisch.

In een projectomgeving die:

• Duidelijk is, bestaat er een voor de hand liggend pad tussen probleem en oplossing.
• Ingewikkeld is, is het pad tussen probleem en oplossing misschien niet voor de hand liggend, maar goede analyse zal een pad naar een passende oplossing blootleggen.
• Complex is, is het niet mogelijk om een enkel pad te identificeren, zelfs niet met analyse, omdat voorspellingen alleen gebaseerd kunnen worden op theorie in plaats van ervaring.
• Chaotisch is, bestaat er geen basis voor voorspelling omdat er te veel verschuivende of tegenstrijdige factoren zijn. De enige weg voorwaarts is door middel van experimenteren.

In bovenstaande leent het duidelijke domein zich voor pure waterfall en het chaotische domein vereist wendbaarheid. De andere twee – de meest voorkomende in de werkelijkheid – worden waarschijnlijk het best gediend door een hybride benadering. Vraag jezelf dus af: "welke van bovenstaande beschrijft mijn projectomgeving het best?" en laat dat je selectie van benadering leiden.

Je moet ook rekening houden met andere beperkingen die gedreven worden door de regels en cultuur van je organisatie bij het beslissen over de meest verstandige benadering voor je project. Proberen om een waterfall-benadering te laten werken in een cultuur die gekenmerkt wordt door wendbaarheid, of een agile benadering te laten werken in een cultuur die gekenmerkt wordt door hiërarchische sturing, zal problemen veroorzaken.

Een hybride benadering zal waarschijnlijk beter 'verkopen' en slagen.

Het Agile Manifesto, uitgebreid om de toepasbaarheid buiten software te vergroten, identificeert vier waardestellingen die bedoeld zijn om praktijkbeoefenaars naar agile gedrag te sturen. Iedereen die op een agile manier wil werken, zou waarde moeten hechten aan:

Met de focus op de items aan de linkerkant terwijl je nog steeds waarde erkent in die aan de rechterkant.

Hoewel er discussie is over de vraag of het oorspronkelijke Manifesto volledig van toepassing is in de wereld van vandaag – met name in een softwarecontext – bieden de waardestellingen nog steeds nuttige begeleiding voor projectgovernance. Het is logisch om governance voor een agile project te baseren op de items aan de linkerkant, en governance voor een waterfall project op de items aan de rechterkant.

• Mensen en teamwork: Het monitoren en mogelijk maken van professionele discipline en samenwerking.
• Bedrijfswaarde leveren: Focus op waarde die bedrijfsbehoeften ondersteunt, in plaats van het afvinken van procesvereisten.
• Actieve betrokkenheid van het bedrijf: Bedrijfsvertegenwoordigers laten nauw samenwerken met het team gedurende het hele project.
• Voldoen aan actuele behoeften bij implementatie: Ervoor zorgen dat de oplossing overeenkomt met de werkelijke bedrijfsvereisten bij lancering—zelfs als die vereisten verschillen van het oorspronkelijke plan.

• Het volgen van vooraf gedefinieerde processen: Ervoor zorgen dat iedereen zich houdt aan vastgestelde stappen en goedkeuringen.
• Het produceren van voorspellende documentatie: Het ontwikkelen van duidelijke specificaties en controleren dat de oplossing ermee overeenkomt.
• Het correct goedkeuren van wijzigingen: Het valideren van alle wijzigingen aan de oorspronkelijke documentatie.
• Het naleven van plannen: Ervoor zorgen dat plannen accuraat blijven en responsief zijn op goedgekeurde wijzigingen.

In een hybride opzet moet governance de juiste balans vinden tussen agile en waterfall elementen. Dit houdt in dat wordt afgestemd welke onderdelen van elke benadering het meest zinvol zijn voor de specifieke context van het project.

De meest effectieve projectaanpak zou gestuurd moeten worden door de context – zowel de aard van het werk als de omgeving waarin het project zal leven. Wees op je hoede voor iedereen die ofwel pure agile of pure waterfall promoot als een universeel toepasbaar recept voor succes.

Met een laatste verwijzing naar het Cynefin-framework – dit beschrijft een staat van Aporia (betekent impasse) of Verwarring en is geen goede plek om te zijn. Je zult hoogstwaarschijnlijk jezelf, en je project, hier zien lijden als je niet in staat of niet bereid bent om je projectaanpak af te stemmen op de context en omgeving.

Je moet voor jezelf denken, de context analyseren en dienovereenkomstig handelen. Door dit te doen, heb je de beste kans om van de Aporia/Verwarring naar een van de andere toestanden te gaan waar een aanpak, hoogstwaarschijnlijk een hybride, je kans op projectsucces zal optimaliseren.