«

»

Mar 03

Waterfall falen

Scrum is vrij nieuw. Het Agile manifesto bestaat pas 10 jaar en als je dat afweegt naar het aantal jaren dat er software ontwikkeling is dan is het vrij jong. Scrum is een van de modellen die is voortgekomen uit die Agile gedachten en kwam tot leven omdat er een helder antwoord nodig was op het waterfall model. Nu lees ik veel en besloot me eens wat te verdiepen in die waterfall manier van werken. De rede, het werkt namelijk niet. Eerlijk gezegd ben ik nog geen enkel project tegengekomen dat succesvol eindigde met deze methode.

Perfecte wereld

In de perfecte wereld zou het waterfall model werken. Eerst zou er aan het concept worden gewerkt en alle wensen worden verzameld. Hier is iedereen heel blij mee en men zet er een handtekening onder om vervolgens door te gaan naar design. Ook die fase wordt perfect opgeleverd en in beton gegoten en dan door naar ontwikkeling van de software en vervolgens via test naar deploiment. En alle fases worden pas afgerond als alles 100% is en er geen twijfels zijn. Maar helaas leven en werken we niet in de perfecte wereld. Klanten weten vaak niet zeker wat ze van te voren willen. Designers twijfelen altijd aan hun creaties. En Developers willen het altijd anders dan in eerste instantie is bedacht. Daarbij gaat het vaak om vrij grote en lang lopende processen waarbij je halverwege nieuwe bevindingen kan aantreffen waardoor je het proces wil bij sturen. Maar ja. Alles is vastgelegd en in beton gegoten. En dan spreek ik nog niet van de ellende van meerwerk, alles wat komt bovendrijven tijdens het testen. En het koppelen met andere software of netwerken. De oeverloze discussies over hoe het beter moet gaan, plannen schrijven en documentatie stromen laat ik zelfs maar even buiten beschouwing.

Dus waarom houden we dan zo vast aan de schijnveiligheid van waterfall. Het werkt niet. Het is te omslachtig. En net als een waterval stromen de fouten van het ene bakje over in het volgende.  Vreemd genoeg houden we ons vast aan een model waarover in een ver verleden een slimme man heeft gezegd dat we het niet moeten gebruiken. En toch doen we het. Veel projectmanagers kennen de oorsprong niet. Ik ook niet tot ik me eens ging verdiepen. En als je met scrum bezig bent, vallen de schellen vaak van de ogen.

Winston Royce

De eerste melding van het waterfall model was tijdens een symposium voor advanced programming voor digitale computers op 29 juni 1956. Het ging nog om een presentatie voor software ontwikkeling voor SAGE en het model was vooral voor het werken met een prototype. Later werd het model besproken in een artikel van Winston W.Royce in 1970. Hij noemde het niet waterfall maar het model was gelijk aan wat we nu gebruiken. De grap is dat hij in zijn waterfall artikel concludeerde dat het model niet werkt. Het was volgens hem een zwak model vol fouten en risico’s.

De grap is dat sindsdien zijn naam verbonden is aan het model en we het met zijn allen zijn gaan gebruiken. Het Amerikaanse leger begon met het gebruik ervan en vervolgens volgde europa.  Aangezien Internet en computerontwikkeling in de eerste instantie een defensie ontwikkeling is. Is het begrijpelijk waar het allemaal vandaan komt. Die verdomde Amerikaanse defensie lui. En helaas gebruikte ze ook nog eens de verkeerde gedeeltes.

En tja, wat uit Amerika komt is per definitie goed. Toch? Helaas niet. Winston W.Royce heeft zijn conclusies nooit goed kunnen verdedigen en zijn model is verguist. Alleen vreemd genoeg gebruiken we het nog steeds en was het ook niet echt zijn model. Hij was er juist op tegen. Gelukkig waren er andere slimme mensen die met betere modellen kwamen en dit wel goed wisten in te zetten. Denk aan RUP, XP en Scrum.

Dus laten we een stoppen met dat verkeerde model dat waterfall heet en verder kijken naar betere en vooral ook eenvoudige modellen. Ik zeg niet dat scrum, RUP en XP zo perfect zijn maar er zit wel meer logica in en vooral een factor mens. We maken allemaal fouten, weten het vaak niet, bedenken ons, en communiceren wel eens langs elkaar. Dus zorg dan ook dat je met een model werkt wat hier op in kan spelen in plaats van iets wat daar juist niet mee om kan gaan.

Sjor alles vast

Ik maak wel eens de grap dat waterfall net is als alles vastsjorren op een vlot. Je hoopt dat je alles hebt en overal aan gedacht hebt. Vervolgens duw je af en laat je je met de stroom meevoeren. Halverwege kom je erachter dat alles toch niet goed vast zit en dat je dingen bent vergeten. Maar ja. De stroom dendert verder. De waterval komt in zicht, dus hoop je dat je onderaan nog alles hebt en alles heel is. Ik ben er meer voor om de oever die agile is te bewandelen. Je kunt onderweg struikelen. Over rotsblokken klimmen. En iets vergeten of achterlaten. Je kunt altijd weer terug om het te halen. En hoe vaker je het pad bewandeld des te makkelijke het gaat.

Moet ik nog doorgaan met vergelijkingen. Dacht het niet toch..

Permanente koppeling naar dit artikel: http://agilethings.nl/waterfall-falen/