Voorspellende of adaptieve aanpak: watervalmethode, agile en wat agile oorspronkelijk wilde zijn

Waterval of agile: die vraag komt op zodra u software laat ontwikkelen. Ze wordt gepresenteerd als een keuze tussen twee projectmanagementmethoden. De echte scheidslijn ligt ergens anders. Die loopt tussen twee manieren van omgaan met wat je nog niet weet: het voorspellen, of je eraan aanpassen.

Een voorspellende aanpak beslist vooraf wat er gebouwd wordt, en wanneer. Een adaptieve aanpak beslist gaandeweg, op basis van wat er geleerd wordt. En veel werkwijzen die tegenwoordig agile heten, voorspellen nog steeds, alleen met andere middelen.

De voorspellende aanpak: eerst het plan

De watervalmethode en het V-model delen één principe. De fasen volgen elkaar op, van de eisen tot en met het beheer, en elke fase bouwt voort op het resultaat van de vorige. Het plan ligt aan het begin vast. Testen komt na het bouwen.

Dit model heeft een geschiedenis, en die begint met een waarschuwing. In 1970 publiceert Winston Royce, ingenieur bij TRW, een artikel waarin hij deze opeenvolging van fasen tekent. Direct daaronder schrijft hij: “I believe in this concept, but the implementation described above is risky and invites failure.” (Ik geloof in dit concept, maar de hierboven beschreven uitvoering is riskant en lokt mislukking uit.)

Hij legt uit waarom. De testfase, helemaal aan het eind, is het eerste moment waarop je het werkelijke gedrag van het systeem ziet. Voldoet dat gedrag niet aan de eisen, dan moet het ontwerp opnieuw. De ontwikkeling gaat dan terug naar af, en je kunt volgens hem een overschrijding verwachten van tot wel 100% van de planning of de kosten.

Toch vindt Royce de aanpak deugdelijk, op één voorwaarde: er vijf stappen aan toevoegen. Onder meer: het werk twee keer doen, waarbij de eerste versie dient als simulatie van de tweede. En de klant erbij betrekken, formeel en doorlopend.

Craig Larman en Victor Basili hebben beschreven hoe het verderging. De norm DOD-STD-2167 van het Amerikaanse ministerie van Defensie schreef een strikt watervalmodel voor, gestuurd door documenten, in één doorgang. Eind jaren tachtig loopt het ministerie bij de aanschaf van software tegen grote mislukkingen aan. Bijna tien jaar later zegt de hoofdauteur van de norm dat hij spijt heeft dat hij hem heeft geschreven: hij kende iteratieve ontwikkeling toen niet, en anders had hij die sterk aanbevolen. In december 1994 vervangt MIL-STD-498 de herziene versie, DOD-STD-2167A. Die beschrijft ontwikkeling in meerdere opeenvolgende versies, die elk een deel van de geplande functionaliteit realiseren.

Een voorspellende aanpak blijft geschikt voor een behoefte die niet zal veranderen. Werk dat telkens precies hetzelfde terugkomt, wordt voorspelbaar. Software daarentegen wordt altijd voor het eerst ontwikkeld.

Wat agile oorspronkelijk wilde zijn

In februari 2001 komen zeventien specialisten in iteratieve methoden bijeen in Utah. Daaruit komt het Manifest voor Agile Software Ontwikkeling voort. De titel zegt waar het over gaat: softwareontwikkeling, geen projectmanagement.

De vier waarden passen in vier regels. Een ervan: “Inspelen op verandering boven het volgen van een plan”. Twee van de principes wijzen dezelfde kant op: “Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces” en “Werkende software is de belangrijkste maat voor voortgang”.

In die tekst is agile geen methode. Het is een aanpak: software opleveren die werkt, kijken wat het effect ervan is, en van koers veranderen als wat je leert daarom vraagt.

Als agile toch voorspelt

Een groot deel van wat tegenwoordig onder die naam gebeurt, brengt het voorspellen weer terug.

Story points. Ron Jeffries, een van de grondleggers van Extreme Programming, vertelt hoe ze zijn ontstaan. Zijn team schatte in “ideale dagen”, die de stakeholders lazen als kalenderdagen. Om die verwarring weg te nemen, noemde het team ze voortaan “points”. In 2019 schrijft hij: “I like to say that I may have invented story points, and if I did, I’m sorry now.” (Ik zeg graag dat ik story points misschien heb uitgevonden, en als dat zo is, heb ik er nu spijt van.)

Velocity. Veel teams schatten elk item in story points, meten hoeveel punten ze per iteratie afronden en leiden daar een datum uit af. Vasco Duarte wijst op de zwakke plek van dat mechanisme: naarmate het team het werk beter begrijpt, schat het opnieuw wat er overblijft, en het gemiddelde waarmee wordt voorspeld, blijft verschuiven.

Frameworks om agile op te schalen. Bij SAFe komen de teams elke 8 tot 12 weken samen om de volgende periode gezamenlijk te plannen. Tot de resultaten van die sessie rekent de documentatie van SAFe een bord waarop de opleverdata van de features en hun afhankelijkheden staan.

Martin Fowler, een van de ondertekenaars van het Manifest, gaf die verschuiving in 2018 een naam: “faux-agile: agile that’s just the name, but none of the practices and values in place” (nep-agile: agile in naam, zonder de werkwijzen en waarden). In hetzelfde jaar sprak ook Jeffries van “Faux Agile”.

Tellen in plaats van schatten: eerlijker, nog steeds voorspellend

Sommige teams zijn gestopt met schatten. Duarte stelt voor het werk zo klein op te delen dat de items op elkaar lijken, te tellen hoeveel er per week klaar zijn, en dat tempo door te trekken om de rest te voorspellen. Allen Holub, die dezelfde methode bepleit, spreekt van projecties op basis van echte metingen. Het woord hoort bij deze school.

Dat is eerlijker dan een gok. Maar het blijft een voorspelling. Een gok over de toekomst is ingeruild voor een extrapolatie van het verleden.

De vraag is dezelfde gebleven: in welk tempo gaan we, en wanneer zijn we klaar?

De adaptieve aanpak: niet langer afhankelijk van voorspellingen

Een adaptieve aanpak stelt die vraag niet. Hij stelt een andere: wat is nu het nuttigste om te doen? En hij beantwoordt die met wat we op dat moment weten. Niet met wat we ons voorstelden op de dag van de offerte.

Dave Farley is stelliger in zijn video “How To Estimate Software Development Time”: hij gelooft niet in schattingen, en zegt dat wij dat ook niet zouden moeten doen.

Frédéric Leguédois wijdt een module van zijn training “Un retour à l’essence de l’Agilité” (in het Frans) aan die overstap: “Passer de Scrum à un fonctionnement sans projection” (van Scrum naar werken zonder projectie; eigen vertaling). Hij behandelt daarin modellen die uitgaan van flow, aanpassingsvermogen en het ontbreken van voorspellende planning.

Adaptief betekent niet dat er niets wordt voorspeld. De aanpak voorspelt wat voorspelbaar is: het maandbudget en de ontwikkeldagen per maand. Hij probeert niet het onvoorspelbare te voorspellen: wat uw gebruikers met een functionaliteit zullen doen voordat ze die in handen hebben.

Daar is een reden voor. Wanneer Microsoft het effect van zijn ideeën met een gecontroleerd experiment meet, verbetert slechts één op de drie de beoogde indicator. Een derde heeft geen effect, een derde verslechtert hem (Kohavi en Thomke, Harvard Business Review, 2017). Niemand weet van tevoren welke. Dat blijkt pas bij het gebruik. Een idee kun je overigens al testen voordat er iets gebouwd wordt: daarvoor dient een MVP.

Wat dit betekent voor software op maat

Bij een voorspellende aanpak ligt de lijst met functionaliteiten aan het begin vast, samen met de prijs en de datum. Maar die lijst wordt geschreven voordat de software bestaat, op het moment dat u het minst weet over hoe uw teams haar zullen gebruiken. Elke ontdekking onderweg wordt meerwerk. Elk stuk meerwerk vergroot het verschil met de offerte. Dave Farley legt het uit in zijn video “Fighting User Requirements That CONSTANTLY Change”: software ontwikkelen is gaandeweg leren wat ze moet doen. Betere eisen opschrijven is niet genoeg.

Onze agile ontwikkelaanpak begint aan de andere kant. Wat vastligt, is het budget en het op te lossen probleem. Wat flexibel blijft, is de scope, met andere woorden de functionaliteiten die dat probleem oplossen.

Wij ontwikkelen uw applicatie op maat tegen een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk. Ze is binnen een maand bruikbaar. Bruikbaar betekent niet af: uw teams gebruiken haar vanaf de eerste maand, en dat gebruik bepaalt wat we de maand erna ontwikkelen.

Het is een vaste prijs, maar geen vaste prijs met vaste scope. Wie het risico draagt als de behoefte verandert, per model: dat is het onderwerp van ons artikel over vaste prijs en regie. En waarom een prijs uit opgetelde schattingen zo vaak wordt overschreden: dat is het onderwerp van ons artikel over budgetoverschrijdingen.

Verder lezen

Onze gids beschrijft uitgebreid de geschiedenis van de watervalmethode, en wat de grondleggers van agile zeggen over wat ervan geworden is.

Wilt u software laten ontwikkelen, of hebt u een tool die niet meer met uw bedrijf meegroeit? Zullen we kennismaken?

Bronnen

• W. W. Royce, “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, augustus 1970, p. 1-9: figuur 2 en de alinea erna (aanpak die “risky and invites failure” is, testen aan het eind van de cyclus, overschrijding tot 100%); stap 3 (“Do it twice”) en 5 (“Involve the customer”); samenvatting. Kopie van het artikel.
• C. Larman en V. R. Basili, “Iterative and Incremental Development: A Brief History”, IEEE Computer, 36(6), juni 2003, p. 47-56: delen “The Eighties” (DOD-STD-2167, mislukkingen eind jaren tachtig, spijt van de hoofdauteur) en “1990 to the present” (MIL-STD-498, december 1994); bijeenkomst van februari 2001 in Utah.
• Manifest voor Agile Software Ontwikkeling en de twaalf principes, 2001.
• R. Jeffries, “Story Points Revisited”, ronjeffries.com, 23 mei 2019.
• R. Jeffries, “Developers Should Abandon Agile”, ronjeffries.com, 10 mei 2018.
• M. Fowler, “The State of Agile Software in 2018”, martinfowler.com, 25 augustus 2018.
• Scaled Agile, “PI Planning”, SAFe Framework (ritme van 8 tot 12 weken; bord met de opleverdata van de features en de afhankelijkheden).
• V. Duarte, NoEstimates: How to Measure Project Progress Without Estimating, v1.21, Oikosofy, 2015: hfst. 2 (velocity en opnieuw schatten), hfst. 5 (afgeronde items tellen).
• A. Holub, “NoEstimates, An Introduction”, holub.com (“use projections based on real measurements”).
• F. Leguédois, training “Un retour à l’essence de l’Agilité”, Moovence, in het Frans: programma, module 4 “Passer de Scrum à un fonctionnement sans projection”.
• D. Farley, “How To Estimate Software Development Time”, video (“I don’t really believe in estimates and neither should you”).
• D. Farley, “Fighting User Requirements That CONSTANTLY Change”, video.
• R. Kohavi en S. Thomke, “The Surprising Power of Online Experiments”, Harvard Business Review, september-oktober 2017.