Projectaanpak: waterval of Scrum?

Er zijn grofweg twee manieren van aanpak voor realisatie van een nieuwe website: waterval en Scrum. Waterval wordt al een lange tijd gebruikt, Scrum is relatief nieuw. De voor- en nadelen van de beide methodes worden vooral duidelijk in de volgende afbeeldingen.

Visualisatie waterval vs. Scrum methode

 

De bovenstaande afbeeldingen laten zien dat de kans op een mismatch in de verwachtingen van de opdrachtgever en het eindproduct bij de watervalmethode aanzienlijk groter zijn dan bij de Scrum aanpak. Daarnaast krijgt de opdrachtgever elke (bijvoorbeeld 2) weken concreet resultaat in handen wat gedeeld kan worden met de stakeholders en waar direct op gereageerd kan worden. Hierdoor kan sneller bijgestuurd worden en wordt er efficiënter gewerkt.

Korte termijn vs. lange termijn

Op de korte termijn lijkt waterval voor de opdrachtgever interessanter, maar niets is minder waar. Regeren is vooruitzien en dat is precies waar IT-bedrijven goed in zijn: relatief snel verbeteren op basis van ervaringen uit het verleden.

De website is na realisatie vaak een kernonderdeel van de dienstverlening. Omdat een website vaak als bedrijfskritisch aangemerkt kan worden, technieken zich snel ontwikkelen en er altijd sprake is van voortschrijdend inzicht, adviseren we een stapsgewijze aanpak voor het proces. De beste aanpak in de ICT is Scrum, waarbij elke X weken een overleg plaatsvindt en de bakens worden bepaald voor de komende periode. Dit geeft maximale grip op het eindresultaat voor de website.

De werkwijze is ook Agile

Zowel voor hoe we werk wordt uitgevoerd als voor de werkwijze zelf geldt dat deze beide Agile zouden moeten zijn. Agile staat voor wendbaar. Na afloop van elke sprint adviseren we een evaluatie te doen, wat in Scrum termen ‘Retrospective’ heet. In deze Retrospective kijk je samen naar wat goed ging en wat beter kan. Als een aanpassing van de werkwijze beter is, dan pas je die samen aan. We adviseren elkaar aan te moedigen om alles uit te spreken wat de samenwerking ten goede komt. Dit betekent dat zowel opdrachtgever als samenwerkingspartner elkaar aanspreken op wat beter kan. We’re in this together.

Wat Scrum uniek maakt

Elke bijvoorbeeld 2 weken wordt gestart met een planningssessie, samen met de opdrachtgever: wat gaan we maken, wat krijg jij opgeleverd aan het einde van deze ‘sprint’ en hoe gaan we het ontwikkelen. Tijdens deze sessie schatten de teamleden alle functionaliteiten in met sprintpoker. Je mag zelf meedoen en leert op deze manier hoe uren worden ingeschat. Vindt je dat het team hoog schat? Dan leggen ze uit waarom ze op dit getal komen en kun jij uitleggen dat het mogelijk minder uitgebreid ontwikkeld mag worden. Dit heeft de Scrum sprintplanning.

  • Elke 2 weken is er dan ook een demo. Het team levert aan jou op wat ze met je hebben afgesproken. Stakeholders zijn van harte welkom en mogen feedback geven. Jij beslist wat daarmee gebeurd. In deze sessie doen we ook de ‘retrospective’: feedback geven aan elkaar. Het team geeft ook feedback aan zichzelf. Dit noemen we de sprintdemo.
  • De teams zijn dedicated beschikbaar en werken tussendoor niet voor andere opdrachtgevers: maximale focus en een kortere doorlooptijd.
  • Je mag de scope van het project gedurende de ontwikkeling wijzigen. Scrum zegt ‘embrace change’.

Fixed bestaat niet bij webontwikkeling

Het is belangrijk te realiseren dat het beste resultaat nooit uit een watervalproject voort kan komen. Hoe komt dat? Bij een watervalproject wordt vooraf aan de hand van een offerte-aanvraag een voorstel geschreven. Meestal bevat een dergelijk voorstel de wensen die tot dat moment bekend zijn (fixed-scope), een prijs (fixed-price) en een planning (fixed-date). De praktijk laat na afloop van een project zien, dat geen van deze drie items behaald worden:

Fixed scope: hoe duidelijk de kaders vooraf ook leken, er zijn altijd veranderingen gedurende de ontwikkeling. Dit kan gaan om voortschrijdend inzicht bij de opdrachtgever of samenwerkingspartner, een tegenvaller in de techniek (die er altijd zijn) en strategische wijzigingen of verwachtingsverschillen.

  • Fixed price: met het aanpassen van wat er moet gebeuren, wijzigt logischerwijs de tijd die nodig is voor realisatie. Het is niet realistisch te verwachten dat het gehele project vooraf betrouwbaar ingeschat kan worden. Gevolg is zoals de afbeeldingen op de voorgaande pagina laten zien, dat bij de watervalmethode ingeleverd wordt op kwaliteit omdat het budget op een zeker moment op is. Dit is waar de mismatch ontstaat.
  • Fixed date: met het aanpassen van een aspect binnen het project wijzigt de opleverdatum. Vooraf afgegeven planningen worden zelden gehaald omdat deze geen rekening kunnen houden met alle aspecten die gedurende het proces naar voren komen.

Terugkijkend op vele jaren webontwikkeling kunnen we stellen dat bovenstaand de praktijk is. Het is voor een samenwerkingspartner ondoenlijk om vooraf alle aspecten van een project volledig te overzien en in kaart te brengen. Dit komt omdat het maatwerk is, maar ook omdat in een offertefase het niet zonder meer logisch is om veel tijd te investeren voor eigen rekening en risico. Conclusie: alles ‘fixed’ bestaat niet en kan beter vermeden worden.

Het beste advies

Bij een vastgesteld budget is het logisch dat de samenwerkingspartner vanuit dat budget adviseert. Dat is niet per se het beste advies, maar wel wat binnen het budget past. Doorgaans is dat niet de aanpak die het beste resultaat geeft. Vanaf de start ontstaat er met waterval zodoende al een kloof tussen de opdrachtgever en de samenwerkingspartner.

De Scrum aanpak is ontwikkeld om de opdrachtgever een beter eindresultaat te bieden, in een kortere tijd, volgens een efficiëntere projectaanpak, met een groter behoud van motivatie voor het ontwikkelteam en een hogere kwaliteit eindproduct.

Kies voor Scrum

Advies: kies alleen voor Scrum als de samenwerkingspartner daar ervaring mee heeft en gecertificeerde Scrum-masters in dienst heeft voor begeleiding van het proces. Kijk naar het totale budget en reserveer daar bijvoorbeeld 70% van voor het realisatieproces. Reserveer de rest van het budget om voortschrijdend inzicht een plaats te geven en discussie te voorkomen. Het is belangrijk om dit op de juiste manier met stakeholders te communiceren.