Traditioneel waterval of Agile Projectmanagement?

Gaan we ‘Scrummen’ of liever toch lekker ‘traditioneel’ watervallen? Wat past binnen jouw organisatie en wat past bij het project?

Bij het starten van een nieuw project, in ons geval bij creatie van een nieuw online platform of website, is het essentieel om grip en controle te houden over het project en de output. Om een dergelijke projecten in controle te houden zijn er verschillende projectmanagement methodieken. 

Welke methodiek het beste past is sterk afhankelijk van de organisatie en het project. Om de juiste keuze te maken is het belangrijk om te weten welke methodiek het beste past in welke situatie.

Agile vs Waterval? 

Er zijn een tal van projectmanagement methodieken. In onze business zijn er heel platgeslagen 2-tal stromingen te definiëren. De meer traditionele waterval methodieken zoals Prince2 en de agile methoden zoals het Scrum Framework. 

In dit artikel schrijf ik meer over de achtergrond van de verschillende methodieken. 

Beide methoden hebben voor- en nadelen maar verschillen fundamenteel. Wij werken met verschillende soorten projecten en opdrachtgevers. Per keer stemmen we af wat het beste past. Zowel de organisatie, het type en omvang van het project en de werkwijze en cultuur van de opdrachtgever zijn voor ons van invloed op de keuze of er meer traditioneel of Agile/Scrum de juiste aanpak voor uw project is. 

Dus: Agile vs waterval. Maar hoe weet je nou welke methodiek het beste bij jouw project past? En hoe bepalen wij welke methodiek wij inzetten? Van al deze punten, houden wij het meeste rekening met:

• Type project: Eenvoudig of klein project versus groot of complex project
• Cultuur opdrachtgever: Flexibele output versus (nep) zekerheid

1. Type Project: Compact of klein project versus groot of complex project

Groot & complex? 

Alleen bij innovatieve en complexere projecten komen de voordelen van Scrum goed tot zijn recht. Bij Agile methodieken breng je snel een eerste versie van een product naar ‘buiten’ die je vervolgens toetst, doorontwikkelt en uitbreidt.

Compact & klein? 

Het Scrum Framework legt veel nadruk op communicatie en continue afstemming en toetsing. Bij een eenvoudig en goed af te bakenen project, met concrete output en dat binnen een aantal weken en in een klein team kan worden uitgevoerd, levert Scrum dus te veel overhead op. In dat geval kunnen we beter de standaard fasering van waterval methodieken inzetten. 

Omvang

Daarbij kent Scrum en het werken met zelfsturende teams een opstarttijd. Voordat je echt keihard kan knallen in sprints moet het multidisciplinair team met leden van de opdrachtgever en -nemer aan elkaar ‘wennen’. Het is essentieel dat het team de ruimte krijgt om zichzelf te organiseren. Dit betekent dat leden gefocust de tijd moeten hebben om aan het project te kunnen werken, maar het betekent ook dat hiervoor ook in doorlooptijd en budget ruimte voor moet zijn. In de richtlijnen wordt geadviseerd rekening te houden met een minimale omvang van zo’n zo’n 700 uur.  

Bij Level Level hebben we dit ook deels opgelost door de mogelijkheid een vast Scrum team in te richten waardoor dit team als perfect op elkaar is ingespeeld. Dit team werkt dat samen aan meerdere Scrum projecten. De afstemming van de klant in het team houd je altijd in ons geval als opdrachtnemer.  

2. Cultuur opdrachtgever: Flexibele output versus (nep) zekerheid

Het grootste voordeel van Scrum is de intensieve samenwerking tussen opdrachtgever (Product Owner) en het team. Er is een korte feedback-loop en alle betrokken stakeholders zien in korte cycli direct resultaat. Deze intensieve samenwerking zorgt voor kwalitatief betere resultaten en snellere acceptatie bij de doelgroep. Maar dit vergt dus ook inzet en flexibiliteit van de opdrachtgever. Het werkt alleen als dit ook daadwerkelijk past bij de organisatie.

Het is super belangrijk dat alle betrokken, dus ook aan de opdrachtgever kant, de fundamenten van Scrum kennen en ook echt snappen. Scrum is een mindset van het team en dus ook van de klant en opdrachtgever.

Intensieve rol van opdrachtgever

Bij Scrum is de rol van Product Owner cruciaal. Die rol wordt vaak ingevuld door degene die traditioneel de rol van ‘opdrachtgever’ of ‘klant’ invult. De Product Owner moet veel kennis hebben (hij moet namelijk over de specificaties beslissen), moet veel en snel beslissingen kunnen nemen en altijd beschikbaar zijn want het development team mag niet stilvallen. Is de opdrachtgever niet in staat om snel de juiste beslissingen te nemen en de juiste content beschikbaar te hebben dan is het beter niet te werken met Scrum want dan gaat het tijdsvoordeel verloren.

Het liefst werk je ook zoveel mogelijk met het team bij elkaar op locatie. Natuurlijk is het mogelijk om alle tooling online in te richten, maar dan gaat een groot voordeel van Scrum verloren: namelijk het direct met elkaar kunnen schakelen zonder tijdsverlies.

Een zelfsturend team

Bij sommige bedrijven heerst er een hiërarchische cultuur. Het werken met een zelfsturend team werkt dan over het algemeen niet bevorderlijk. Als de opdrachtgever de controle wil houden en het lastig vindt om volledig te vertrouwen op het team dan is Scrum ook geen goed idee. De opdrachtgever hoort bij Scrum volledig in dienst te staan van het productieproces en niet andersom.

Flexibele scope

De term Agile zegt het natuurlijk al. Het kan een kracht zijn om niet blind te staren op een vooraf gedefinieerde output, maar dan moeten wel alle betrokkenen open staan voor flexibiliteit. Is die flexibiliteit er vervolgens niet vanuit de opdrachtgever qua output, doorlooptijd of budget, dan moeten we afvragen of we dan wel moeten Scrummen. Natuurlijk zet je ook in Scrum een aantal factoren vast, maar bij Scrum zit juist de kracht in het deel open laten en de nieuwe inzichten vertalen naar een nog beter resultaat. Hiervoor is vertrouwen essentieel.

Je verkoopt geen nep zekerheid bij Scrum. Je koopt een team met expertise die je als Product Owner moet vertrouwen. Klant is echt verantwoordelijk, daarom kan dat als eng worden ervaren. Past dit niet bij de organisatie? Dan past een traditionele methodiek beter waardoor er vooraf toch zoveel mogelijk moet worden afgebakend. Dit geeft de opdrachtgever het gevoel van meer zekerheid, maar hierdoor kunnen we niet garanderen dat dit het beste resultaat oplevert. Je levert op wat je afspreekt, maar je weet niet van te voren of dat ook daadwerkelijk gaat zorgen voor het bereiken van het gedefinieerde doel.