November 2019 – Tony Koeleman werkt sinds eind jaren ’80 aan softwareprojecten en automatiseringssystemen. De toegepaste werkwijze was toen Waterval en is nu Agile, met sprints van twee weken volgens de Scrum-methode. Hij heeft goede redenen om te twijfelen aan de houdbaarheidsdatum van een strikte werkwijze volgens Agile en denkt regelmatig terug aan de voordelen van de Watervalmethode. Een korte uitleg van zijn overweging.“Bouwprojecten, zoals een brug over een rivier, gaan volgens Waterfall of Watervalmethode. Werkzaamheden binnen het project worden in verschillende fasen opgedeeld. Eerst wordt een doel gesteld, bijvoorbeeld door een Provincie die wil dat mensen van de ene kant naar een andere kant kunnen komen. Dan volgt de functionele wens, bijvoorbeeld dat aan beide zijden de economie verbetert. De volgende fase gaat over de mogelijke oplossingen zoals een pontje, een tunnel of een brug, en daarna de ontwerpfase die na goedkeuring in bouw wordt uitgevoerd. Na een testperiode volgt de oplevering, en tenslotte het gebruik en onderhoud.
Voordelen en nadelen
Wat daar Waterval aan is, is allereerst het definiëren van je behoefte, dan volgt de business case met budgettering en afschrijving, een ontwerp volgens de in de briefing gestelde criteria, bouw, testen en onderhoud. Het resultaat van de vorige fase is de input voor de volgende fase. Resultaat van je eisen en wensen is de input voor je ontwerp. Resultaat van je ontwerp is de input voor je bouw, et cetera. Het voordeel is dat je van tevoren precies uitdenkt wat je wilt hebben. Het nadeel is dat het lang duurt voordat je überhaupt iets hebt.
Volgens deze methodiek bouwen we al duizenden jaren bruggen, gebouwen, kerken, steden en dorpen. Sinds een jaar of zestig passen we de werkwijze ook toe op softwareprojecten en automatiseringssystemen: eisen en wensen formuleren, business case maken, ontwerpen en uitvoeren, een testfase, in gebruik nemen en onderhoud.”
Precies hetzelfde als bij die brug…
“Wat het verschil is, is dat wat misgaat of anders loopt dan de inschatting, bij een brug nog is bij te sturen. Bij software gaat dat toch anders want het is abstracter, gaat veel minder lang mee en is vaak onderdeel van een geheel zoals een bestaand systeem, dienst of organisatie.
Verandering
Het resultaat van de vorige fase is de input voor de volgende fase. Zo’n brug duurt jaren voordat je weet of het goed is en het bouwen van software duurt ook jaren voordat je weet of het precies doet wat je initieel voor ogen had. Je vertrouwt er op dat het goed komt en daarnaast hoop je dat de eisen, wensen en de werkelijkheid niet tussentijds veranderen. Er blijkt concurrentie te zijn of de opdrachtgever heeft andere inzichten. Kortom, er zijn voldoende redenen waarom werken volgens de Watervalmethode voor een softwareproject niet ideaal is.
Een project bestaat wat mij betreft uit drie dimensies: functionaliteit, beperkte doorlooptijd en beperkte middelen. Je doet een goed project als je in-time en in-budget de gewenste functionaliteit levert.”
Waterfall, Scrum en Agile
“Bij een project volgens Waterval staat de functionaliteit vast en is er een idee van de tijdsduur en wat het project ongeveer gaat kosten. De onzekerheid rond kosten en doorlooptijd leg je bij de opdrachtgever, of opdrachtnemer: nacalculatie, of fixed price. Als het mis gaat, heeft een van de projectpartijen wat uit te leggen over de planning of mag de knip trekken.
Die variabele kosten en doorlooptijd wil je binnen een bandbreedte krijgen omdat een project waar je budgettair geen grip op hebt, onhandelbaar en eigenlijk onverkoopbaar is. Zeker als het om grote bedragen gaat, wil je weten waar je aan toe bent. Bij software is dat aan de hand en eind vorige eeuw kwam er een nieuwe en bij de werkzaamheden beter passende werkmethode tot stand. Zo goed, dat alle partijen er beter mee uit de voeten kunnen en op een prettigere manier inzicht kunnen houden op de lopende zaken. In 1986 werd Scrum (werken volgens korte sprints), in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi, in de Harvard Business Review gepubliceerd. In februari 2001 werd in Utah USA het Manifesto for Agile Software Development opgesteld tijdens een informele bijeenkomst van zeventien softwareontwikkelaars.
Agile werken lijkt logisch…
Met een Scrum/Agile werkwijze brengen we de doorlooptijd van, zeg, twee jaar terug naar twee weken, de lengte van een gemiddelde sprint, en dat telkens herhaald totdat de oplevering akkoord is. Een Agile-werkwijze is prima, en zeker bij een operationeel systeem. Bij een operationeel systeem bouw je elke sprint wat aan en elke twee weken zet je iets in productie waar je van kan genieten. In de volgende sprint neem je het goede over en ontwikkel je twee weken verder naar een volgend tussendoel. Het klinkt logisch. Als het mis gaat, gaat het maximaal voor twee weken mis.
Ga je terug naar die brug: die kun je niet volgens Agile bouwen. Er wordt een paal geheid, er is een profieldeel van de overspanning geklonken, er is asfalt gelegd… Een halve brug is geen brug. Software kan prima werken met ontbrekende delen functionaliteit. Denk aan je browser: pech gehad als je geen bookmarks kan maken of alleen in de Helvetica websites kunt lezen. Het werkt prima, al is het niet wat je uiteindelijk wilt.”
Wat is nu het grote verschil tussen Waterfall- en Agile werken?
“Bij Waterfall staat de functionaliteit vast. Bij Agile staan de kosten en doorlooptijd vast – vijf ontwikkelaars gaan twee weken lang in gecontroleerde omstandigheden hun uiterste best doen – en is de op te leveren functionaliteit een onzekere factor geworden. Je wilt eigenlijk alle drie de factoren borgen.
Met Agile kun je afspreken dat je aan zes brokken functionaliteit gaat werken en slechts vier delen opleveren. De resterende twee schuiven door naar de volgende sprint of gaan zelfs terug naar de backlog. Dit geeft de illusie dat je meer grip op je project hebt, maar in feite heb je andere variabelen vastgezet. Ik zie voor de manier waarop wij projecten doen een combinatie van Waterfall met Agile beter passen, zowel voor ons als voor de opdrachtgever en toeleveranciers.”
Voordelen van een andere werkwijze
“Bij MetaFactory maken we best gecompliceerde systemen die flexibel worden ingezet in omgevingen die niet constant zijn. De eisen aan de AM-i tool voor Mulder-Mazda, het EMS-systeem voor GP Elite en de FourC-software (Connect, Communicate, Control, Comfort) voor Verosol zijn dusdanig dat we na bijna 100 sprints (sinds zomer 2015) wel kunnen zeggen dat we een eigen methode hebben gevonden om binnen de randvoorwaarden van de projecten optimaal resultaat te leveren. Ik zie nog een verbeteringsslag en daarmee kijk ik terug naar de ‘good old’ Waterfall.
Je moet eigenlijk altijd eerst veel functionaliteit opleveren voordat je een applicatie kunt gaan gebruiken. De klant gaat er in eerste instantie toch nog niet mee aan de slag want dat heeft geen zin. Het eerste stuk, of eerste stukken, minimale functionaliteit zou je in feite Waterfall kunnen bouwen en na een basis deeloplevering verrijken via de Scrum/Agile methodiek. Waterfall kan ook prima voor overzichtelijke onderdelen van het project die sowieso nodig zijn, waarvan de planning duidelijk of juist onbelangrijk is en waarvan de kosten te overzien zijn.
Om in de analogie van de bruggenbouw te blijven: als je weet dat er acht pilaren nodig zijn en je weet hoe en waar je die wilt hebben dan kun je daar Waterfall aan werken.
Zolang je het eindplaatje maar voor ogen houdt…
“Ja, en juist dat is met Agile lastig. Door te werken in korte sprints ben je zo enorm gericht op die korte termijn, terwijl je toch in functionele zin als in technische zin moet voldoen aan de langetermijnvisie van het einddoel. Bij projecten die twee, drie, vier jaar duren is dat echt een uitdaging. Ik doe dit werk nu zo’n dertig jaar en ben begonnen met projecten in Waterfall, en daarnaast prototyping en dergelijke. Sinds MetaFactory doe ik de projecten Agile. Dat bevalt maar ik kijk toch ook nog wel eens terug naar de goede dingen van Waterfall. Ik waak ervoor dat we het goede van de Waterfall niet weggooien en de stip op de horizon blijven zien: functionaliteit en systeemarchitectuur.”
Tenslotte
“Agile past perfect in strak gebudgetteerde projecten. Je weet waar je aan toe bent en degenen waar je verantwoording aan aflegt ook. Qua budget en planning zit je safe. Dat is echt van deze tijd en ik betwijfel of dat optimaal ten goede komt aan projecten die over meerdere jaren lopen. Met systemen die al volop in productie zijn hoef je op voorhand niet precies te weten waar je aan het eind van het jaar staat. Als het goed is renderen constant geoptimaliseerde en ‘on the fly’ geoptimaliseerde systemen met de tijd steeds beter. En dat is al een doel op zich.”
Uiteraard heeft Tony nog veel meer te vertellen over Waterfall versus Agile.
Meer weten?
Neem contact op via de contactpagina.
