Iteratieve implementatie: in kleine stappen naar een werkend eindresultaat
Stel je voor dat een bakker een nieuw broodrecept wil ontwikkelen. Hij kan twee dingen doen: een maand lang in zijn hoofd het perfecte recept uitdenken en dan in één keer honderd broden bakken, of al na de eerste poging een brood proeven, iets aanpassen, opnieuw bakken, weer proeven, en zo stap voor stap verbeteren. Die tweede aanpak heet in de technologiewereld iteratieve implementatie: een werkwijze waarbij je een product, dienst of systeem niet in één grote klap afmaakt, maar in kleine, herhaalde stappen bouwt, test en bijstuurt.
Deze aanpak is inmiddels de standaardmanier waarop het grootste deel van alle software wordt gemaakt, van apps op je telefoon tot de taalmodellen achter chatbots. Maar het idee reikt verder dan software: ook raketten, zelfrijdende auto's en overheidswebsites worden steeds vaker op deze manier ontwikkeld. In dit artikel leggen we uit wat iteratieve implementatie precies inhoudt, waarom bedrijven en overheden er zo aan hechten, en waar de grenzen van deze aanpak liggen.
Wat is het precies?
Bij iteratieve implementatie splits je een groot project op in kleine, behapbare stukjes die elk een werkend (maar nog onvolledig) resultaat opleveren. Zo'n stukje werk heet vaak een iteratie of, in de populaire werkmethode Scrum, een sprint: een vaste periode, meestal één tot vier weken, waarin een team aan een afgebakend doel werkt.
Na elke iteratie staat er iets dat echt gebruikt of getest kan worden, ook al mist het nog allerlei functies. Dat eerste, minimale maar werkende resultaat wordt in jargon een MVP genoemd, een afkorting van minimum viable product (minimaal levensvatbaar product): de simpelste versie van iets die al nuttig genoeg is om feedback op te verzamelen.
Die feedback, van gebruikers, klanten of testdata, wordt vervolgens gebruikt om de volgende iteratie te plannen. Dit terugkoppelingsproces heet een feedback-loop: je bouwt iets, je kijkt wat er in de praktijk gebeurt, en die observatie bepaalt mee wat je daarna bouwt. Deze cyclus van bouwen-testen-leren-aanpassen herhaalt zich net zo lang tot het product klaar of goed genoeg is.
De overkoepelende filosofie achter deze manier van werken heet Agile (Engels voor 'wendbaar'). Agile is geen vaste methode maar een verzameling waarden en principes die stellen dat je beter kunt reageren op verandering dan star vasthouden aan een vooraf gemaakt plan. Scrum is de bekendste concrete uitwerking van die Agile-filosofie.
Wat wil men ermee bereiken?
De belangrijkste drijfveer achter iteratieve implementatie is risicospreiding. Bij de traditionele tegenhanger, de zogeheten watervalmethode, wordt een heel project vooraf in detail uitgedacht en pas aan het einde in één keer opgeleverd. Gaat er dan iets mis, dan merk je dat vaak laat, als er al veel tijd en geld in is gestoken.
Door in kleine stappen te werken, ontdek je fouten en verkeerde aannames eerder en goedkoper. Je leert daarnaast sneller wat gebruikers daadwerkelijk nodig hebben, in plaats van wat je bij de start dacht dat ze nodig zouden hebben. Dat voorkomt verspilling: je bouwt geen maanden aan functies waar uiteindelijk niemand gebruik van maakt.
Een derde doel is flexibiliteit. Technologie, markten en gebruikerswensen veranderen voortdurend. Iteratief werken maakt het mogelijk om tussentijds van koers te veranderen zonder dat een heel project overboord moet, omdat er nooit meer dan één iteratie aan ongeteste aannames vastzit.
Voorbeelden uit de praktijk
- Het Agile Manifesto (2001, Snowbird, Utah): zeventien softwareontwikkelaars kwamen bijeen in een skiresort in Utah en formuleerden vier waarden en twaalf principes die nog altijd de basis vormen van de moderne iteratieve softwarebeweging.
- OpenAI's gefaseerde uitrol van taalmodellen: OpenAI noemt zijn eigen aanpak expliciet 'iterative deployment'. GPT-2 werd in 2019 in stappen uitgebracht uit voorzorg, GPT-3 volgde in 2020 via een beperkte API, ChatGPT kwam in november 2022 beschikbaar voor het grote publiek en GPT-4 verscheen in 2023, telkens met lessen uit de vorige fase verwerkt in de volgende.
- SpaceX en de Starship-raket (2023-2024): SpaceX hanteert een 'build-test-fly-fail-rebuild'-aanpak, waarbij testvluchten (van IFT-1 in april 2023 tot IFT-5 in oktober 2024) bewust risico op mislukking accepteren omdat elke storing direct wordt verwerkt in een verbeterd volgend prototype.
- Tesla's Autopilot en Full Self-Driving: via software-updates die draadloos ('over-the-air') naar auto's worden gestuurd, verbetert Tesla zijn rijhulpsystemen voortdurend op basis van data die het wagenpark verzamelt.
- De UK Government Digital Service (opgericht in 2011): deze Britse overheidsdienst ontwikkelde gov.uk en andere digitale overheidsdiensten volgens een vaste, iteratieve 'Service Standard', met gebruikersonderzoek tussen elke ontwikkelstap.
Hoe ver is de techniek?
Iteratieve implementatie is geen technologie met meetbare ontwikkelingsniveaus zoals een nieuwe batterij of chip; het is een werkwijze, en de volwassenheid daarvan verschilt sterk per sector. In de softwarewereld is het inmiddels de norm: sinds het begin van de jaren 2000 werkt een groot deel van de branche volgens Agile- of Scrum-achtige principes.
In andere domeinen ligt dat anders. Bij fysieke producten zoals raketten is iteratief, 'falend' testen zoals SpaceX dat doet nog relatief nieuw en niet overal geaccepteerd; traditionele ruimtevaartorganisaties werken vaak liever met uitgebreide vooraf-simulaties om dure mislukkingen te vermijden.
Bij kunstmatige intelligentie is iteratieve uitrol onderwerp van serieus debat. Voorstanders, waaronder OpenAI zelf, beargumenteren dat de wereld geleidelijk moet wennen aan steeds krachtigere AI-systemen en dat je risico's het beste leert kennen door voorzichtig echte gebruikers toegang te geven. Critici binnen de AI-veiligheidsgemeenschap stellen daarentegen dat juist bij krachtige, moeilijk te doorgronden AI-modellen uitgebreider vooraf testen nodig is, omdat fouten pas zichtbaar worden nadat miljoenen mensen het systeem al gebruiken. Een eenduidig antwoord op wie gelijk heeft, is er nog niet.
Ook in gereguleerde sectoren zoals de luchtvaart en de medische technologie botst iteratief werken met wetten die juist uitgebreide goedkeuring vooraf eisen, voordat iets de praktijk in mag. Daarnaast kent iteratief werken praktische valkuilen: kleine, snelle aanpassingen kunnen zich opstapelen tot wat in de softwarewereld technische schuld heet, rommelige code die steeds moeilijker te onderhouden wordt. Ook bestaat het risico dat teams zich blindstaren op kleine verbeterstapjes en een noodzakelijke, grotere herontwerp-vraag uit de weg gaan. En in traditionele organisaties met sterke hiërarchie en lange goedkeuringstrajecten stuit de iteratieve, uitprobeer-cultuur nog regelmatig op weerstand.
Wie werken eraan?
Grote techbedrijven als OpenAI, Google DeepMind, Microsoft en Meta passen iteratieve uitrol toe bij het ontwikkelen en beschikbaar maken van AI-modellen. SpaceX en Tesla zijn de bekendste voorbeelden van iteratief werken buiten de softwarewereld, bij respectievelijk raketten en voertuigsoftware.
Op het vlak van methodologie zijn organisaties als Scrum.org en de Agile Alliance verantwoordelijk voor het verder ontwikkelen, documenteren en trainen van Agile- en Scrum-praktijken binnen bedrijven wereldwijd.
Overheden experimenteren eveneens met iteratieve dienstverlening. De Britse Government Digital Service is daarin een veelgenoemd voorbeeld, net als Estland, dat met zijn digitale overheidsdiensten (bekend als e-Estonia) geldt als voorloper in iteratieve beleidsontwikkeling. Ook in Nederland werken overheidsorganisaties zoals Logius, verantwoordelijk voor digitale overheidsdiensten zoals DigiD, met Agile-achtige werkwijzen bij de doorontwikkeling van hun systemen.
Op onderzoeksgebied bestudeert onder meer het Software Engineering Institute aan Carnegie Mellon University al decennialang hoe software het best ontwikkeld kan worden, inclusief de voor- en nadelen van iteratieve methoden.