Agile versus de traditionele Waterval aanpak

Eén van de vragen waar je mee te maken krijgt bij de start van een nieuw project is de keuze welke aanpak je gaat gebruiken. Sommige opdrachtgevers en projectmanagers willen vasthouden aan een traditionele Waterval aanpak, terwijl anderen voorstander zijn van een Agile-aanpak. In de praktijk belanden veel projecten ergens in het midden; met een aanpak die niet extreem wendbaar of extreem stijf is. In vergelijking met de Waterval benadering, kunnen deze ‘polderaanpakken’ flexibel lijken, omdat ze ervoor zorgen dat veranderingen/wijzigingen kunnen plaatsvinden in de verschillende iteraties. In vergelijking met Agile zijn ze waarschijnlijk te rigide[i]Hoe maak je de juiste keuze tussen Agile en de traditionele Waterval aanpak voor jouw project? 

Bij de keuze voor een projectaanpak moet je nadenken over de hoeveelheid flexibiliteit die het project nodig heeft en welke aspecten je kunt toepassen van verschillende projectmanagement aanpakken die het best bij de specifieke behoeften passen. Onderzoek de omvang van het project, de teamsamenstelling, de organisatiecultuur en de projectdoelstellingen. Vervolgens voeg je de verschillende puzzelstukjes samen, zodat er een maatwerkaanpak ontstaat die aansluit op de behoeften van het project.

Om een goede keuze te maken welke aanpak het meest geschikt is voor het project kunnen onderstaande 8 vragen behulpzaam zijn. Ze helpen bij de beantwoording hoe flexibel de methodologie moet zijn van zeer flexibel (Agile) aan de ene kant, en zeer rigide (Waterval) aan de andere kant.

Onderstaand plaatje geeft de verschillen tussen een Atern/Agile en traditionele waterval aanpak aan.

Agile versus Traditional

Agile versus Traditional

8 vragen: Agile versus Waterval

  1. Hoe duidelijk zijn de projectdoelstellingen en requirements?
    Voor sommige projecten weet de opdrachtgever precies waarnaar hij/zij op zoek is en wat de succescriteria zijn. Voor andere projecten, kan het lastig zijn om vanaf de start aan te geven wat er bereikt moet worden en wat de requirements zijn. Wanneer de requirements lastig te bepalen zijn en de eisen zich moeilijk laten definiëren of kunnen veranderen, heb je een flexibele en experimentele aanpak nodig. Voor deze projecten is de Agile aanpak effectiever dan de traditionele Waterval aanpak.
  2. Hoe duidelijk is de oplossing en is de weg ernaartoe vastgelegd?
    Het komt vaak voor dat het gewenste projectresultaat duidelijk is, maar de weg ernaartoe nog niet. Het team wordt geconfronteerd met lastige keuzes rond technologie, ontwerp en implementatie. De gekozen projectaanpak moet dan flexibel genoeg zijn aan tegemoet te komen aan al deze onzekerheden. Hier kan de iteratieve, flexibele Agile aanpak een uitkomst bieden.
  3. Hoe makkelijk of hoe moeilijk is het om beslag te leggen op de tijd van de eindgebruikers?
    Zijn de (eind)gebruikers, beheer en andere experts op korte termijn beschikbaar om feedback te geven en het opgeleverde eindproduct te testen (acceptatietesten)? Of verwacht men dat het lastig zal zijn deze groepen op korte termijn te betrekken, waardoor de deadline in gevaar kan komen? Zou het niet gemakkelijker zijn om hen vooraf te betrekken en om input te vragen per opgeleverd work-item (stukje functionaliteit) en deze input mee te nemen in de volgende iteratie. Hoe meer beperkingen er zijn rond de beschikbaarheid van de gebruikers, de meer traditioneler de aanpak (eenmaal het gehele eindproduct testen versus na elke iteratie de opgeleverde functionaliteiten testen en in gebruik nemen). Het voordeel van de Agile-aanpak is dat na elke iteratie de opgeleverde functionaliteit (na acceptatietest) in gebruik genomen wordt, de gebruikers kunnen wennen aan het op te leveren eindproduct en deze stap voor stap (functionaliteit voor functionaliteit) leren gebruiken. Input kan worden meegenomen in de opvolgende iteraties. Binnen een traditionele aanpak krijgen de gebruikers vaak in één keer het complete eindproduct gepresenteerd en kan naar gelang hun ervaringen de nazorgperiode flink wat tijd in beslag nemen.
  4. Wat is de omvang van het project(team)?
    Hoe groter het projectteam, hoe lastiger het kan zijn om op korte termijn veel veranderingen door te voeren en het team te heroriënteren in een andere richting. Kleine teams die nauw samenwerken met de opdrachtgever en de eindgebruikers zijn flexibeler en beter uitgerust om snel wijzigingen te verwerken.
  5. Hoe verspreid is het projectteam?
    Zijn er meerdere projectteams verspreid over diverse geografische locaties of is het team samengebracht op één locatie? Bij een geografisch verspreid team kan het lastig zijn om snel te coördineren en de werkzaamheden aan te passen aan veranderende prioriteiten vanuit de opdrachtgever. Teams die samen zitten zijn beter uitgerust om in een Agile-omgeving met veranderende prioriteiten te werken.
  6. Hoe ervaren zijn het team en de stakeholders met het gebruik van deze projectmanagement methodieken?
    Hebben het team en de stakeholders al ervaring met het werken volgens een bepaalde projectmanagement methodiek? Zo ja, houd dan in gedachten dat het tijd kost om een team te laten veranderen van werkmethode. Als het project een kritisch tijdpad heeft wees dan voorzichtig met het doorvoeren van te drastische aanpassingen aan de gebruikte methodiek.
  7. Wat zijn de succescriteria voor het project?
    Wat is belangrijk voor je sponsor en opdrachtgever? Het hebben van een relatief starre en stevige raming en planning die gehaald moeten worden, of ervoor te zorgen dat het eindproduct waarde toevoegt en overeenkomt met de behoeften en verwachtingen van de gebruikers? Is de opdrachtgever klaar om een meer flexibele en kwaliteitsbewuste aanpak te omarmen?
  8. Hoeveel waarde zou incrementele op features/functionaliteiten gebaseerde ontwikkeling toevoegen?
    Leent het project zich ervoor om iteraties toe te passen en zou deze manier echte waarde toevoegen voor de stakeholders? Moeten de producten en functionaliteiten in één keer worden opgeleverd om tastbare voordelen te bieden, of zou het een groot voordeel zijn om de functionaliteiten stapsgewijs op te leveren?

 

 


[i] Dit artikel is vrij vertaald naar Susanne Madsen

Comments

  1. Paul van Haren zegt

    Een bijzonder artikel. Na het lezen ervan, blijven er toch een paar vragen hangen. Het zou aardig zijn op de voor- en nadelen van de Waterval methode en Agile voor ieder van de 8 onderwerpen eens op rij te zetten. Ik ben dan benieuwd wanneer er voordelen te behalen valt met de Waterval methode.

    Uit mijn eigen ervaring ken ik alleen maar voordelen van een Waterval methode boven Agile methodieken wanneer er sprake is van een groot event in het midden van een project. Bijvoorbeeld wanneer het project een maan-missie betreft, is het minder aantrekkelijk om heel flexibel om de zoveel tijd een stukje op weg te gaan en dan de gebruikers om feedback te vragen.

  2. dionne zegt

    Interessant artikel. Maar een punt die ik mis is hoe je om moet gaan met verschillende projecten. Vanuit Scrum geredeneerd moet je je focussen op één project. In praktijk is het natuurlijk vaak zo dat er verschillende projecten tegelijk lopen. Elk project zou een eigen team moeten hebben, maar kleinere bedrijven hebben maar een klein team, waardoor er een continue resource strijd is tussen de projecten (ze zijn overal nodig). Denk je niet dat dit ook speelt bij de keuze voor welke aanpak je moet kiezen.

    @ Paul van Haren
    Zou je je voorbeeld kunnen uitleggen waarom je denkt dat Waterval methode in dat geval voordeliger is dan Agile.

Speak Your Mind

*

Deze site gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.