Van ‘waterfall’ tot ‘agile’; een stukje geschiedenis

In de jaren 60 begon software ontwikkeling een steeds belangrijkere rol te spelen in de wereld en zeker bij het Amerikaanse minsterie van defensie ofwel de DoD, (Department Of Defense). Software ontwikkeling voor grote systemen stond nog in de kinderschoenen en ook toen al vond men software ontwikkeling moeilijk te controleren en chaotisch. De software community moest gedisciplineerd worden!

De DoD startte dan ook het initiatief om tot een standaard te komen waarmee ze controleerbare software projecten konden uitvoeren en waarmee ze ook eisen aan leveranciers konden stellen. De DoD wees iemand aan om deze standaard manier van software ontwikkeling op te stellen. Deze persoon had weinig kennis van software ontwikkeling en begon dan ook met een literatuur studie. Al snel liep hij tegen een paper aan van de beroemde computer wetenschapper Winston Royce. Deze paper uit 1970 genaamd Managing The Development Of Large Software Systems wordt gezien als de originele ‘waterfall’ paper.

In deze paper beschrijft Winston Royce in de eerste pagina’s inderdaad een proces waarbij in fasen van idee tot oplevering wordt gewerkt. Hij vervolgt met de constatering dat deze lineaire aanpak zeer risicovol is en dat je het gehele process van analyse tot het in productie nemen tenminste TWEE keer moet doorlopen.

De DoD heeft ondanks het advies in de paper gekozen om het ontwikkelen in EEN keer goed te willen doen. Om ervoor te zorgen dat het ook in een keer goed kan gaan, is gekozen om na elke fase een formele acceptatie stap in te bouwen, waarin de vragende partij moet tekenen voor akkoord. De bekendste standaard die de DoD hieruit heeft geproduceerd is de zogenaamde MIL-STD (Military Standard) standaard die bestaat uit een grote verzameling boekwerken. De waterfall aanpak werd de standaard in software development en is vandaag de dag nog veelvuldig in gebruik.

Gevolgen van de Waterfall aanpak

De waterfall aanpak heeft als gevolg dat risico’s van een project zeer hoog blijven tot in de latere fasen. We hebben de volgende risico’s om rekening mee te houden;

• Kosten risico: kunnen we het project realiseren tegen acceptabele kosten en binnen een acceptabele tijdsduur?
• Business risico: is het inderdaad de oplossing voor ons probleem?
• Technologie risico: kunnen we het technisch realiseren?
• Kennis risico: Kunnen de huidige mensen die eraan werken het realiseren?

Deze risico’s blijven lange tijd hoog omdat pas bij de implementatie fase voor het eerst duidelijk wordt wat de voortgang is. Als eenmaal de test fase aanbreekt worden de risico’s pas echt een probleem. In alle voorgaande fasen wordt voortgang gemeten door documenten en andere abstracties. Alle rapportages staan meestal op groen totdat er getest wordt. Dan blijkt vaak dat zaken niet goed werken, functionaliteit toch anders bedoeld is of nieuwe inzichten zijn verkregen waardoor de oplossing van een tijd geleden niet meer de juiste is.

Als dan uiteindelijk het systeem in productie wordt genomen is het nog maar de vraag of de klanten het inderdaad gaan gebruiken en kopen. En dat terwijl inmiddels 100% van de investering is gedaan!

Niet iedereen loopt deze risico’s

De geschetste risico’s zijn vooral voor de vragende partij; de klant. Voor de leverende partij kan dit een goed model zijn! Elke fase wordt afgesloten met een ondertekend document. Voor elke fase worden kosten in rekening gebracht. In het geval de klant veranderingen wil aanbrengen dan is dat uiteraard mogelijk. Elke verandering gaat via een Change Control Board waarin goedkeuring plaatsvindt.  Een verandering is echter meestal niet zonder kosten. Het komt zelfs voor dat de meeste omzet binnen een waterfall project wordt gehaald uit de ‘change requests’.

Agile ontwikkeling 

De absolute kern van agile ontwikkeling is het verkleinen van risico’s. Alles wat om agile heen is ontstaan, is allemaal gericht om de risico’s van ontwikkeling en innovatie zo vroeg en zo goed mogelijk te verkleinen.

In agile ontwikkeling kan bijvoorbeeld bij een project van 12 maanden, elke maand een oplevering gedaan worden naar productie. Hierdoor is niet een gehele investering nodig maar een investering risico van 1/12 deel van het totaal. Na 1 maand weet je echt waar je staat als project. Je hebt immers een echt product opgeleverd dat productie gereed is. De oplevering naar productie stelt je in staat om feedback te ontvangen van je klanten. Is wat je hebt opgeleverd inderdaad wat de klant verwacht? Lost het inderdaad het probleem op dat de klant heeft? Kloppen de schattingen van het aantal geïnteresseerde klanten?

Antwoord op deze vragen geeft je in een vroeg stadium relevante informatie. Hiermee kun je betere beslissingen nemen op een moment waarop er nog maximaal tijd voorhanden is. Als er bijvoorbeeld meer klanten geïnteresseerd zijn dan verwacht, kun je besluiten om meer te investeren en het product sneller naar de markt te brengen. Als de klant niet helemaal tevreden is met het resultaat, kun je direct ontdekken wat wel een goede oplossing zou zijn. Als de voortgang beneden verwachting is, kun je bijvoorbeeld besluiten om meer mensen in te zetten of de scope te verkleinen.

Agile manifesto

De thought leaders op het gebied van software product ontwikkeling kwamen aan het begin van deze eeuw bij elkaar om een reactie op het waterfall process te construeren. Alle aanwezigen waren succesvol met een iteratieve manier van werken zoals bijvoorbeeld Scrum, DSDM of Feature Driven Development. Hoewel de details van deze aanpakken verschillen hebben ze besloten om de kern van al deze aanpakken, waarover ze het allemaal eens waren, vast te leggen. Het resultaat is het Agile Manifesto. 

Het agile manifesto zegt dat ze betere manieren van software ontwikkeling aan het ontdekken zijn door het in de praktijk toe te passen en door anderen te helpen om het toe te passen. Het mag niet meer voorkomen dat de theoretici bepalen hoe zaken in de praktijk moeten worden aangepakt. In de praktijk vinden we uit wat werkt en de academische wereld is er om ons te bestuderen en te verklaren waarom het werkt. We luisteren vooral naar mensen die ook daadwerkelijk software ontwikkeling doen in de praktijk! Hieronder volgt een korte toelichting van het Manifesto.

Individuals & interactions over processes and tools

Software wordt het meest succesvol gemaakt door mensen die het gehele proces meemaken. Mensen die in een omgeving werken van vertrouwen en respect. Een omgeving waarin mensen excellente interacties hebben en relevante informatie vrij en transparant is. Processen en gereedschappen zijn minder belangrijk voor succes dan goede mensen en excellente interactie.

Working software over comprehensive documentation

Het creëren van waarde kan pas gebeuren nadat er software is opgeleverd. De focus hoort dan ook te liggen op werkende software. Alhoewel documentatie waardevol is voor succes, is werkende software voorwaardelijk. Werkende software is dan ook de manier om voortgang te meten en aannames te valideren.

Customer collaboration over contract negotiation

Het doel is om waarde te creëren voor de klant. Dit doen we door zeer nauw met de klant samen te werken tijdens ontwikkeling. In het geval de klant nieuwe inzichten krijgt verwerken we deze inzichten zo snel en effectief mogelijk. Het formele contractuele proces is belangrijk maar voor succes is het veel belangrijker dat je effectief kunt samenwerken met je klant om het meest waardevolle te realiseren.

Responding to change over following a plan

Gedurende een project ga je heel veel leren. Aan het begin van een project weet je immers het minste. Vroegtijdige en frequente validatie van aannames geeft nieuwe kennis die we verwelkomen en gebruiken. Het plan is belangrijk om gemeenschappelijke richting te creëren maar voor succes is het veel belangrijker dat je effectief om kunt gaan met veranderingen en nieuwe inzichten.