Is Agile efficiënter dan Waterval?

Een van de Scrum Masters die we regelmatig coachen, belt ons geregeld over problemen waar hij mee worstelt. Hij grapte dat we het beste "Agile Hotline, waarmee kunnen we u helpen?" konden zeggen als we de telefoon opnemen. We vonden dat een heel goed idee en daarom beginnen we nu met een reeks blogposts onder de naam Agile Hotline. Hier vind je onze antwoorden op de vragen die we van anderen krijgen over Agile of Scrum. We hopen dat ook jij er iets van kunt leren.

Onlangs werd mij om advies gevraagd over een discussie die iemand met een collega had. Het ging erover of Agile en Scrum in elk scenario waarin software wordt ontwikkeld, kunnen werken. De collega beweerde van niet.

Het scenario

Laten we ervan uitgaan dat er een softwareproduct gebouwd moet worden waarmee gebruikers beoordelingen kunnen geven terwijl ze een e-book lezen. Er moeten minstens twee verschillende soorten beoordelingen zijn.

Bij Agile of Scrum zou je proberen zo vroeg mogelijk een werkend en waardevol product op te leveren – het doel is dus om slechts één van de beoordelingsmogelijkheden te leveren, die al vroeg door de gebruikers gebruikt kan worden. Dat zou dan v1.0 zijn. Een paar Sprints later probeer je dan de tweede beoordelingsmogelijkheid als v2.0 te implementeren.

Bij het watervalmethode zou je zo lang de tijd nemen als nodig is om beide beoordelingen in de eerste versie te leveren.

De collega beargumenteerde in dit geval dat waterval logischer zou zijn, omdat het risico anders erg hoog zou zijn om de volledige code te moeten refactoren om de tweede beoordelingsmogelijkheid v2.0 te kunnen ondersteunen. Met waterval zouden beide beoordelingstypen echter samen ontwikkeld worden. Hoewel het langer zou duren om de eerste werkende versie te leveren, zou er minder nawerk nodig zijn.

Hij is van mening dat de watervalmethode tijd bespaart en efficiënter is, omdat je minder hoeft te refactoren als je met huidige en toekomstige requirements tegelijkertijd begint met de ontwikkeling. Bij Agile ligt onze focus echter op het "nu" en op slechts één beoordelingstype.

Wat denk jij hierover? Hoe zou jij omgaan met een groep ontwikkelaars die denken dat ze bij Agile later veel moeten herwerken, omdat ze "niet te ver vooruit mochten plannen"?

Wat wij geloven

Er zijn drie hoofdpunten die je moet begrijpen om deze vraag te beantwoorden:

• Ten eerste: Agile en Waterval hebben allebei hun eigen toepassingsgebied. Agile is ontworpen voor gecompliceerde/complexe systemen, bijvoorbeeld wanneer er een zekere mate van onzekerheid is bij de requirements en/of de technologie. Waterval is het meest geschikt voor eenvoudige projecten, bijvoorbeeld wanneer er een goed begrip is van requirements en technologie en deze zaken niet veranderen. We gebruiken de Stacey Matrix om te verduidelijken wanneer je wat moet inzetten. Het punt is dat Waterval in een complexe omgeving volledig faalt, terwijl Agile in een simpele omgeving weliswaar meer inspanning vergt, maar toch werkt. Ons favoriete voorbeeld hiervoor is het organiseren van een conferentie. Je kunt Agile gebruiken, ook al lijkt het misschien op onnodige inspanning.

• Ten tweede: Agile is NIET efficiënter dan Waterval. Het is effectiever. Dat betekent dat je misschien meer personeelsuren nodig hebt om iets met Agile op te leveren, maar het product zeer waarschijnlijk eerder op de markt gebracht kan worden (omdat er aan het einde van elke Sprint een release zou moeten zijn en niet pas aan het einde van het project). Bovendien zijn de totale eigendomskosten waarschijnlijk lager (omdat kwaliteit en design beter zijn en kennis wordt gedeeld, waardoor onderhoud eenvoudiger is).

• Ten derde: Bij Agile gaat het er niet om iets specifieks sneller te ontwikkelen. Het gaat om de kunst om de hoeveelheid niet-gedaan werk te maximaliseren. De Chaos-studie stelt dat 65 % van software nooit of zelden wordt gebruikt. Met Agile probeer je de overige 35 %, die het meest waarschijnlijk worden gebruikt, te identificeren en te ontwikkelen; daarna stop je. Dus ook al duurt het misschien iets langer om de eerste 35 % te ontwikkelen, we hebben onszelf bespaard om de andere 65 % te ontwikkelen die niemand zal gebruiken.

Hoe ziet dat er nu uit met ons voorbeeld? Nou, allereerst zou je niet eerst de volledige eerste beoordeling afmaken en daarna pas de tweede. Je zou het meest waardevolle deel van de beoordeling identificeren. Dat kan een bepaald type vraag zijn (bijvoorbeeld een meerkeuzevraag). Je zou dus slechts één vraag in de beoordeling opnemen, deze door gebruikers laten testen en uitzoeken of het werkt. Je zou zelfs de eerste beoordelingsmogelijkheid alleen met meerkeuzevragen kunnen opleveren. Daarna zou je het op één na belangrijkste vraagtype toevoegen. Of je besluit dat het goed genoeg is en begint aan een nieuw project.
Als de omvang van de beoordelingen echt vaststaat, je bovendien weet dat het daadwerkelijk werkt voor de gebruikers, en er geen onzekerheid is over de technologie, dan kan Waterfall de betere keuze zijn voor dit project. Agile zou ook werken, maar niet per se tijd besparen. Uit ervaring kan ik zeggen dat de meeste mensen denken dat ze alle eisen kennen en begrepen hebben – maar dat klopt meestal niet. De extra inspanning bij Agile betaalt zich dus meestal uit.

Deze tekst komt uit de blog van Growing Agile en is door ons naar het Nederlands vertaald.