Wat is het verschil tussen iteratieve en incrementele ontwikkeling?
In mijn trainingslessen merk ik vaak dat studenten incrementele en iteratieve ontwikkeling (IID) door elkaar halen. Het doel van dit artikel is inzicht te geven in de relatie tussen incrementele en iteratieve ontwikkeling.
Ik begin met een vergelijking van een waterval- en een agile aanpak, aan de hand van het voorbeeld van de oplevering van een betaalapp. Er is ook een bijbehorend kort webinar over deze aanpakken opgenomen. In het tweede deel van dit artikel plaats ik waterval en agile in een matrix die het snijpunt van incrementele en iteratieve ontwikkeling laat zien, waarbij ik alle vier de kwadranten in de matrix toelicht.
Agile versus waterval: de ontwikkeling van een betaalapp
De watervalaanpak
Als deze voorbeeldapp volgens een traditioneel watervalmodel wordt ontwikkeld, zijn in figuur 1 de volgende stappen te zien.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Figuur 1: Dit diagram toont een typische watervallevenscyclus aan de hand van het voorbeeld van de oplevering van een app.
Projectinitiatie
Alles begint met een projectsponsor van de marketingafdeling, die de benodigde middelen voor deze app wist vrij te maken. Hij ging ervan uit dat de app het behoud van klanten en de instroom van nieuwe klanten zou verbeteren. Hij had drie functiegroepen op hoog niveau voor ogen.
Zodra het project is goedgekeurd, wordt een projectmanager aangesteld en wordt een projectteam samengesteld. Na veel discussies en workshops voor het verzamelen van vereisten was er overeenstemming over de oplevering van een betaalapp met 250 functionaliteiten. Al deze functies worden vastgelegd in een uitgebreid en zeer gedetailleerd softwarevereistendocument, dat wordt ondertekend door de projectsponsor en de vertegenwoordiger van de klant (evenals andere belangrijke belanghebbenden).
Ontwerpfase van het project
In de volgende stap vertaalt het projectteam de vereisten naar een ontwerp voor de app. De architect controleert het ontwerp aan de hand van de ontwerpprincipes. Hij controleert ook of alle vereiste gegevensattributen beschikbaar zijn in het backend-systeem.
We zijn nu twee maanden bezig en de klant heeft nog niets werkends gezien, alleen enkele voortgangsrapporten. En deze voortgangsrapporten bevatten waarschijnlijk een vorm van ‘watermeloenrapportage’, waardoor de klant geen idee heeft of het project op schema ligt of niet.
Ontwikkelfase van het project
Het duurt zes maanden om de app te ontwikkelen en wanneer dat is gebeurd, wordt de vertegenwoordiger van de klant gevraagd enkele mensen aan te leveren die kunnen helpen met een gebruikersacceptatietest. Tijdens de test wordt duidelijk dat verschillende functies niet werken.
Het projectteam begrijpt niet waarom. Het is precies wat in het vereistendocument is beschreven. Dit leidt tot veel discussies, herstelwerk en vertragingen, en de klanten zijn niet blij met de resultaten. Bovendien kunnen we, als we naar het eindresultaat kijken, vaststellen dat veel van de ontwikkelde vereisten niet of slechts zelden door de klant worden gebruikt.
Het kan zelfs nog erger. Stel dat de ontwikkeling van de app 1,5 jaar duurde en een andere bank een betaalapp oplevert wanneer je halverwege bent. Wat zou je op dat moment doen? Zou je dan nog steeds een haalbare businesscase hebben om door te gaan en je eigen app af te maken?
Als we naar figuur 1 kijken, wordt duidelijk dat bij een watervalaanpak de scope en de onderliggende kwaliteitscriteria bij één oplevering worden vastgelegd. Alle stappen worden één keer uitgevoerd voor het hele project en de beheersing richt zich op kosten en tijd. Waarde voor de klant wordt pas geleverd na de implementatie van de volledige app.
De agile aanpak
Als we de app ontwikkelen met een agile projectmanagementaanpak, zien we het volgende patroon:
- Het ontwikkelingsteam geeft aan dat het de eerste twee functies die door de producteigenaar zijn geprioriteerd, in de eerste iteratie kan opleveren.
- Het projectteam levert elke drie weken (sprint, iteratie of timebox) een increment van het product op.
- Na de eerste opleveringen of increments zien we een klant die erop vertrouwt dat het project zal worden opgeleverd. De klant beschikt al over een werkende app en begrijpt dat nog niet alle functies aanwezig zijn, maar dat de aanwezige functies wel werken.
Bij het bekijken van de nieuwste release en de aangeboden functies noemen ze een volledig nieuwe functie. Een functie waar bij de start van het project niemand aan had gedacht, maar die het leven van de klant productiever zou kunnen maken.
Na elke increment leidt feedback van de klant tot nieuwe functionele mogelijkheden (die niet op de oorspronkelijke lijst stonden) of aanpassingen van mogelijke functies. Het product wordt steeds volwassener. Bij elke increment ontvangt de klant een nieuwe versie en is hij tevredener.
Afbeelding 2: Het diagram toont de agile ontwikkelcyclus, aan de hand van hetzelfde voorbeeld van de oplevering van een app.
Als we naar afbeelding 2 kijken, zien we een gestage opleveringsstroom binnen een vaste looptijd en met permanente agile teams (dit zijn vaste kosten). De scope en onderliggende kwaliteitscriteria zijn flexibel (dynamisch), met regelmatige kleine opleveringen (dit zijn de incrementen).
Alle stappen die bedoeld zijn om een functie of user story op te leveren, worden herhaaldelijk uitgevoerd (waardoor het iteratief wordt) totdat de vereiste kwaliteit is bereikt. De managementcontrole is gericht op het leveren van klantwaarde. Waarde leveren aan de klant vindt plaats na elke implementatie van een increment.
Waterval versus agile: opleveringsresultaten
Als we de twee producten van zowel de waterval- als de agile softwareontwikkelingsaanpak nader bekijken, zien we een product met 250 functies en een niet zo tevreden klant, en een product met slechts 150 functies en een zeer tevreden klant (zie afbeelding 3).
Afbeelding 3: Dit diagram vergelijkt de verschillen in tijd, het aantal functies en klanttevredenheid voor waterval- en agile benaderingen.
En als we het product dat met de agile aanpak is opgeleverd nog gedetailleerder bekijken, zien we slechts een subset van 100 functies uit de oorspronkelijke lijst en 50 functies die nieuw of aangepast zijn. Dit sluit aan bij enkele belangrijke principes van het Agile Manifest, waaronder:
- Eenvoud, de kunst om de hoeveelheid niet-uitgevoerd werk te maximaliseren: slechts 150 functies in plaats van 250 functies
- Verwelkom veranderende vereisten, zelfs laat in de ontwikkeling: aanpassen aan feedback van de klant na elke iteratie en elk increment
Agile ontwikkelprocessen benutten verandering ten voordele van het concurrentievoordeel van de klant (er werden 50 nieuwe of aangepaste functies opgeleverd). En daardoor is de klant zeer tevreden. De hoogste prioriteit van het team is de klant tevreden te stellen door waardevolle softwaresystemen vroegtijdig en continu op te leveren.
Mini-webinar: oplevering volgens waterval versus agile
Hier is een kort webinar met meer informatie over de verschillen tussen oplevering volgens waterval en agile.
Verschillen tussen iteratieve en incrementele ontwikkeling
Nu ik de verschillen tussen een waterval- en een agile aanpak heb behandeld aan de hand van het voorbeeld van het maken van een betaalapp, plaats ik waterval en agile in een matrix waarin iteratieve en incrementele ontwikkeling worden vergeleken.
Als laatste stap zal ik het minimaal levensvatbare product (MVP) en het minimaal verkoopbare product (MMP) verder toelichten en laten zien waar deze in de verschillende benaderingen en een storymap passen. Ik heb ook een bijbehorend mini-webinar opgenomen.
Matrix voor iteratieve en incrementele ontwikkeling
Zoals gezegd merkte ik dat studenten iteratief en incrementeel vaak door elkaar halen. In afbeelding 4 vind je vier kwadranten, die ontstaan door een horizontale lijn die incrementeel of niet-incrementeel weergeeft en een kruisende verticale lijn die iteratief of niet-iteratief vertegenwoordigt. Bekijk deze YouTube-video voor een zeer eenvoudige versie van deze afbeelding.
Afbeelding 4: Deze matrix toont verschillende ontwikkelbenaderingen en of teamleden die deze benaderingen volgen moeten itereren en/of in incrementen moeten werken.
Kwadrant linksonder
In de linkerbenedenhoek zien we de aanpak waarbij er geen iteraties en geen incrementen zijn. Dit is de watervalaanpak. Alle activiteiten (ontwerp, analyse, bouw, testen en implementatie) worden één keer uitgevoerd voor het hele project.
In dit geval zien we één oplevering van het eindproduct op basis van een vaste scope. Klantwaarde kan pas worden gerealiseerd na de oplevering van het eindproduct. Een van de belangrijkste doelen van deze aanpak is het beheersen van de kosten.
Kwadrant rechtsonder
In het kwadrant rechtsonder zien we een incrementele aanpak zonder iteraties. Dit is een gefaseerde of incrementele levering van kleinere onderdelen van het product. Alle activiteiten voor een bepaalde fase (ontwerp, analyse, ontwikkeling, testen en implementatie) worden één keer uitgevoerd.
Binnen een bepaalde fase ligt de scope vast, maar het totale product is gebaseerd op een meer dynamische of flexibele scope. Na elke levering van het product kan klantwaarde worden gerealiseerd. Een van de belangrijkste doelen van deze aanpak is snelheid van levering.
Kwadrant linksboven
In het kwadrant linksboven zien we een spiraalvormige of iteratieve aanpak zonder incrementele leveringen. Dit is één levering waarbij het uiteindelijke product door middel van verschillende iteraties wordt gecreëerd. Een goed voorbeeld van deze aanpak is ontwerpend denken. In de grafiek zie je een opeenvolging van de activiteiten kaderstelling, analyse, ideeontwikkeling, realisatie en reflectie.
Deze opeenvolging wordt herhaaldelijk of iteratief uitgevoerd, waarbij je in elke iteratie dichter bij het uiteindelijke, correcte of vereiste product komt. In veel gevallen is dit uiteindelijke product een prototype of model. In deze spiraalvormige aanpak hebben we een dynamische of flexibele scope. Klantwaarde kan pas worden gerealiseerd na de levering van het uiteindelijke product. Een van de belangrijkste doelen van deze aanpak is de juistheid van de oplossing.
Kwadrant rechtsboven
In het kwadrant rechtsboven zien we de wendbare aanpak die gebruikmaakt van incrementele leveringen en een iteratieve methode. Scrum is een goed voorbeeld van deze aanpak.
Aan het einde van elke incrementele levering, die vaak een sprint of tijdsvenster wordt genoemd, wordt een productincrement geleverd. Dit increment is het resultaat van vele iteraties om kleine maar correcte onderdelen van het product te ontwikkelen, die vaak gebruikersverhalen of achterstandsitems worden genoemd. Het uiteindelijke iteratieve project wordt stap voor stap geleverd.
In deze wendbare aanpak hebben we een dynamische of flexibele scope. Klantwaarde kan na elke levering van het product worden gerealiseerd. Een van de belangrijkste doelen van deze aanpak is klantwaarde door frequente leveringen en feedback van gebruikers.
MVP of MMP?
In figuur 4 vind je ook de acroniemen MVP en MMP. MVP staat voor minimaal levensvatbaar product en is een versie van een nieuw product of een nieuwe dienst waarmee een team met de minste inspanning zoveel mogelijk over klanten kan leren en validatie kan verkrijgen. De MVP voor de dienst Dropbox was een eenvoudige film. Dit betekent dat de P in MVP een volledig ander product kan zijn dan het uiteindelijke product.
Een voorbeeld ter illustratie van MVP en MMP
Ik gebruik vaak het volgende voorbeeld van een nieuw financieel product. Een enthousiaste verkoopmanager heeft een geweldig idee voor een nieuw financieel product. Hij denkt dat ze minstens 100.000 exemplaren van deze producten kunnen verkopen.
Samen met enkele financiële experts ontwerpen ze het product in een paar maanden. Er wordt een ontwikkelteam aangewezen en het kost hen 4 maanden om het product te ontwikkelen. Tegelijkertijd worden commerciële brochures ontwikkeld en wordt het product tijdens een groot evenement gelanceerd.
Helaas kopen slechts enkele mensen het product. Als we de MVP-aanpak volgen, kunnen we aannemen dat 10% van hun webgebruikers geïnteresseerd is in dit product. Vervolgens zouden we een MVP ontwikkelen om deze hypothese te testen.
In dit geval zou de MVP een eenvoudige knop op de startpagina kunnen zijn. Als je erop klikt, krijg je een scherm met een bericht over dit nieuwe product en de mogelijkheid om je e-mailadres in te vullen als je geïnteresseerd bent. Stel dat minder dan 1% van de bezoekers op de knop drukte — het product zou niet worden ontwikkeld en het bedrijf bespaarde veel schaarse middelen.
Als we figuur 4 nader bekijken, zien we dat MVP's in alle kwadranten kunnen worden gebruikt. Bij een watervalaanpak zou je in de eerste softwareontwerpfase een MVP kunnen creëren om te controleren of er een zakelijke rechtvaardiging voor het project is.
Hetzelfde kan worden gedaan in de eerste fase van de eerste incrementele levering wanneer je een gefaseerde levering volgt. In sommige gevallen kan het resultaat van je aanpak van ontwerpend denken een MVP zijn. De MVP kan ook aan het begin van een wendbare aanpak nuttig zijn.
Veel mensen beschouwen het eerste product dat aan het einde van je gefaseerde levering wordt geleverd als de MVP. Dat kan het geval zijn, maar meestal is dit geen MVP maar een MMP. MMP, oftewel minimaal verkoopbaar product, is het kleinste product dat waarde kan leveren aan je klant.
Hoe ziet wendbare levering eruit?
Nu duidelijk is dat incrementele modellen en iteratieve modellen niet hetzelfde zijn en we het gebruik van MVP en MMP begrijpen, kunnen we nader bekijken hoe incrementele en iteratieve levering eruitzien.
Je hebt waarschijnlijk Jeff Pattons beroemde voorbeeld van de Mona Lisa gezien, waarin het schilderij stukje voor stukje wordt gemaakt (gefaseerde levering). Een andere manier om dit aan te pakken is om te beginnen met het eerste increment, waarin alleen een ruwe schets wordt gemaakt, en bij elke nieuwe iteratie meer details aan de schets toe te voegen, totdat je uiteindelijk het volledige schilderij hebt (incrementele en iteratieve of wendbare levering).
In de eerste situatie moet je al een gedetailleerd idee van het uiteindelijke product hebben, terwijl je in de tweede situatie alleen een schets op hoofdlijnen nodig hebt, omdat veranderingen veel eenvoudiger zijn aan te brengen. Als we naar figuur 5 kijken, zien we een verhaalkaart voor een nieuw product met de naam ABC.
Afbeelding 5: Een voorbeeld van een storymap voor een specifiek product.
De producteigenaar had zeven functies voor dit product voor ogen. De eerste vier functies zijn noodzakelijk. Functie 5 en 6 zijn wenselijk en de laatste functie is optioneel. Velen zouden dit MoSCoW-prioritering noemen (noodzakelijke, wenselijke, optionele functies en functies die niet zullen worden gerealiseerd).
Elke functie afzonderlijk kan worden opgesplitst in kleinere onderdelen. In de afbeelding zie je functies of gebruikersverhalen met noodzakelijke, wenselijke en optionele onderdelen. Een functie kan noodzakelijk zijn, maar dat betekent niet dat alle onderliggende gebruikersverhalen dat ook zijn. Of een functie kan wenselijk zijn, maar als je die functie implementeert, zijn sommige gebruikersverhalen noodzakelijk en andere wenselijk of optioneel.
Om dit ABC-product te implementeren, zie je vijf incrementen of releases. De eerste is het minimaal verkoopbare product. Dit MMP bestaat uit de eerste twee noodzakelijke gebruikersverhalen van functie 1 en de eerste noodzakelijke gebruikersverhalen van functie 2 en 3.
Release 2 bevat de volgende twee noodzakelijke gebruikersverhalen van functie 1, 2 en 3 (iteratieve ontwikkeling). De productontwikkeling gaat verder door de volgende releases te implementeren. Bij elke release neemt de klantwaarde toe.
Na release 5 stopt de producteigenaar met het implementeren van gebruikersverhalen. Uit feedback van de klant bleek dat het ABC-product ‘geschikt voor het doel’ was en hij houdt rekening met het principe van eenvoud uit het Agile-manifest en stopt met verdere ontwikkeling.
Miniwebinar: iteratieve en incrementele ontwikkeling
Hier vind je een uitgebreid webinar over iteratieve en incrementele softwareontwikkeling.
Tot slot
Is jouw softwareontwikkelingsteam bekend met iteratieve en incrementele ontwikkeling? Hoe pas je dit toe binnen je agile- of watervalmethodologieën?
Laat het ons weten in de reacties, of word lid van ons DPM-lidmaatschapsprogramma en bespreek het met andere leden in ons exclusieve forum!
