Agile vs. Waterval - The final showdown?

| Peter Logtenberg en zijn review van de webinar

Review van het webinar van Ingo Philipp (pro Waterval) en Georg Thurner (pro Agile)

Op 26 januari volgde ik een webinar over de Waterval aanpak versus Agile, dat live werd uitgezonden op internet. Interessant aan de opzet van dit webinar was dat de ene presentator, Ingo Philipp, de Waterval methode verdedigde en de ander, Georg Thurner, de Agile methode.

Voorafgaand aan de uitzending was er de gelegenheid om via mail vragen te stellen die in het webinar meegenomen zouden worden. En kennelijk leefde het onderwerp bij de kijkers, want het aantal reacties was hoog, enkele honderden! Nu moet ik eerlijk zeggen dat ik mij zelf soms ook  afvraag of Agile altijd beter is dan Waterval. Met alle publiciteit die er is voor Agile, lijkt het alsof Waterval compleet heeft afgedaan. Maar is dat wel zo?

Ter verdediging van Waterval werd door Ingo Philipp de gedachte naar voren gebracht dat Agile voornamelijk bruikbaar is voor snel veranderende sites en apps, waarbij er weinig risico of schade optreedt als het niet helemaal goed werkt. Voor complexe interne processen met veel wetgeving en formaliteiten waaraan men zich moet houden, zou Agile volgens hem minder geschikt zijn. Ook vroeg Philipp zich af of de verplichting om uitgebreide documentatie op te stellen wel goed past binnen de Agile aanpak. Stelt Agile (programma) code niet boven documentatie?

Dat laatste was een misvatting, zo stelde Georg Thurner, want documentatie is binnen Agile niet heilig, maar moet wel degelijk afdoende zijn. Door het vereiste documentatieniveau binnen de “Definition of Done” op te nemen, wordt het zelfs een integraal onderdeel van het takenpakket van het Agile-team. En daarmee  zou Agile dus ook toepasbaar daar waar uitgebreide documentatie vereist is. Sterker nog, Agile zou juist ook een oplossing kunnen zijn voor onzekerheden over het ontwerp dat aan de programmeur wordt meegegeven.

Volgens Thurner kost het reviewen en verbeteren van het ontwerp om deze onzekerheid te verminderen, onevenredig veel tijd en energie met de Waterval methode. Nu moet ik eerlijk bekennen dat ik het zelf regelmatig meemaak dat ontwerpen aangepast moeten worden naar aanleiding van bevindingen. Met allerlei hertesten en tijdrovende aanpassingen van de software tot gevolg. Zeker lijkt wel dat je in de Agile methode sneller weet of een ontwerp klopt of niet, omdat je het veel eerder kunt testen dan in de Waterval methode.

Maar betekende dit nu dat de business case definitief positief uitviel in de richting van Agile, of niet? Het webinar van Philipp en Thurner bleef spannend om naar te kijken. Neem nu het uitbesteden van software delivery. Kon dat alleen via de Waterval-methode, of was Agile ook toepasbaar?

Een argument van Philipp tegen Agile was dat er wel erg veel communicatie nodig is tussen de leverancier en de opdrachtgever. Communicatie is immers een kerneigenschap van Agile. Thurner kwam sterk terug door te stellen dat in Waterval-projecten ook heel veel communicatie nodig is om geleverde ontwerpen toe te lichten. Om maar niet te spreken van de energie die wordt gestoken in het dichttimmeren van het ontwerp.

Onbelicht in deze webinar, maar contractueel wel interessant wat mij betreft, is hoe een Agile project in een aanbesteding gegoten kan worden. Hoe vergelijk je aanbiedingen en hoe weet je zeker dat je krijgt wat je wilt en waar je voor betaalt als vooraf nog zo weinig bekend is over de loop en duur van een proces?

Mijn conclusie na het bekijken van dit webinar is dat de strijd tussen Agile en Waterval nog zeker niet is gestreden. Beide methoden lijken bestaansrecht te hebben, afhankelijk van de setting waarin software-ontwikkeling vorm krijgt. Het webinar van Philipp en Thurner is wat mij betreft een goed begin van een interessante discussie.

De link naar het Tricentis webinar kan je vinden op de Tricentis website.