Agile/Scrum: het bewijs. Voor *mijn* vak.

Wetenschappelijk bewijs. Ik ben per ongeluk een discussie ingezogen over de bewezen effectiviteit van agile methodieken, en dan Scrum in het bijzonder. Ik heb mezelf altijd als criticus gezien van dit soort managementhypes, maar ik weet uit ervaring dat de uitgangspunten van deze methodieken in mijn eigen vakgebied veel hebben bijgedragen aan het succesvol uitvoeren van complexe en onzekere projecten. Laat ik starten met een kleine vergelijking.

Mijn stelling: Jezelf door je hoofd schieten met een vuurwapen is een effectievere methode om je leven te beëindigen dan dezelfde handeling te verrichten met een waterpistool.

De tegenstander: Waar is uw bewijs voor deze stelling? En kom nu niet aan met een incidentje, nee, ik wil grote groepen zien die deze handeling hebben verricht met statistische onderbouwing of de door jouw geschetste stelling wel waar is. Anders doe ik het af als hobbyisme of leuk tijdverdrijf.

Een vrij kolderiek voorbeeld, he? Ik vermoed dat de meeste mensen het toch wel met mijn stelling eens zijn. Ik haal het op deze manier aan omdat ik dezelfde redenatiestijl om mijn oren heb gekregen door Richard Engelfriet - iets over een tenniswedstrijd. Op zich haalt Engelfriet een valide punt aan; ik ben alleen de mening toegedaan dat statisch onderzoek weliswaar een krachtig middel is om wetenschappelijk bewijs te leveren, het is echter niet het enige dat we tot onze beschikking hebben. Zo hebben we ook logische deductie, bewijs uit het ongerijmde, et cetera. Ik zal de eerste gebruiken om mijn punt te maken.

Om op een goeie manier te kunnen discussiëren met elkaar is het wel van belang dat we de uitganspunten helder uiteenzetten. De stelling die ik wil verdedigen is:

Een agile werkwijze op basis van Scrum is een methode die voor software ontwikkeltrajecten tot betere resultaten leidt dan de voorheen gebruikelijke klassieke watervalachtige methoden.

Stap één in de bewijsvoering. Wat zijn 'betere resultaten'? Ik hanteer een (vereenvoudigd) model voor succesvolle uitkomsten: (I) Is het project afgerond binnen het gestelde budget (of een door de klant acceptabele overschrijding daarvan), en (II) Voldoet het geleverde (eind)product aan de verwachtingen van de klant?

Stap twee. Welke twee zaken vergelijken we nu eigenlijk met elkaar. Ik spreek in mijn stelling van 'voorheen gebruikelijke klassieke watervalachtige methoden'. Da's een mond vol, he. Ik refereer hier verder aan als 'Waterval'. Deze methoden vergelijk ik met 'een agile werkwijze op basis van Scrum'. Alweer zo'n volzin. Ik noem het voortaan gewoon 'Agile'. Laat ik beide definiëren in drie hoofdpunten:

Waterval

1. Alle eisen en wensen van de klant aan het te bouwen systeem worden vooraf in groot detail op papier uitgewerkt.
2. Alvorens we het systeem gaan bouwen gaan we alle onderdelen tot op detail specificeren en ontwerpen, wederom op papier.
3. We maken een gedetailleerde planning voor doorlooptijd en resources, en gieten dit in een (vast) budget. Ook dit doen we weer voor de start van de bouw van de software.

Pas na deze papieren excercities gaan we daadwerkelijk aan het bouwen.

Agile

1. We onderzoeken op grof niveau de eisen en wensen van de klant en gieten dat in een 'product backlog' dat gaandeweg aangepast kan (en moet) worden.
2.  We selecteren vanaf het begin een overzichtelijke hoeveelheid werk en (proberen) dit in een vaste periode (bijvoorbeeld 2 of 3 weken), sprint genaamd, om te vormen in werkende onderdelen van het product.
3. Elke twee weken stemmen we het geleverde af met de klant, bepalen of de klant het 'goed' vindt en zo niet dan sturen we bij in de volgende sprint.

Dit blijven we uitvoeren totdat we het product op een zodanig niveau hebben gebracht dat de klant tevreden is met de uitkomst in relatie tot het bestede budget.

Dit is allemaal erg summier en kort door de bocht maar vat volgens mij wel de kern van de verschillen samen. Hoe is uit deze eigenschappen nu logisch te bewijzen dat de één tot betere resultaten leidt dan de ander? Pas op, de conclusies kunnen als 'flauw' ervaren worden!

Allereerst zien we bij Waterval dat we een vrij lang traject afgelegd hebben alvorens we de software gaan bouwen. Dit is een beproefde methode voor bijvoorbeeld het bouwen van een huis - waar veel dingen vaststaan (natuurwetten, omgeving, anderssoortige wettelijke vereisten) die we in de software helaas vaak niet zo vast kunnen gieten. Veel van dit soort vereisten zijn in de softwareontwikkeling ook nogal aan verandering onderhevig. Erg vervelend op moment dat je gaat bouwen, je bezig gaat met het wensenpakket van je klant dat soms al een jaar oud is. Na de bouw (misschien zijn we wel 2 jaar verder dan) blijkt dat de klant dan toch niet krijgt wat hij of zij verwachtte. Daarnaast blijkt het extreem lastig te zijn om vooraf alle eisen aan een te bouwen systeem goed op papier te krijgen (juist door het ontbreken van de in de bouw gebruikelijke fysieke constraints). We kunnen rustig stellen dat Waterval per definitie in de context van software engineering slecht scoort op succesfactor (II).

Hoe gaat Agile dan om met succesfactor (II)? Zoals gezegd wordt in een agile traject periodiek (iedere paar weken) afgestemd met de klant of het reeds geleverde voldoet aan de verwachtingen, gecombineerd met het eventueel bijstellen van de werkzaamheden die dan nog uitgevoerd gaan worden. Deze veel flexibelere opstelling maakt dat we - mits natuurlijk goed uitgevoerd - per definitie zo goed mogelijk aan de klantverwachtingen voldoen. Kortom, een logische gevolgtrekking dat Agile beter scoort op (II) is triviaal in mijn optiek.

Maar ik vergeet succesfactor (I): zijn we binnen budget (of een acceptabele overschrijding daarvan) gebleven? Ik maak hier toch stiekem wat gebruik van statistiek, namelijk de falende overheidstrajecten. Deze vallen per definitie in de watervalcategorie, want de overheid werkt met aanbestedingen. Je kunt slechts aanbesteden als je van tevoren denkt te weten wat je gaat doen. Is dat een garantie voor het binnen budget blijven? Ik zou zeggen, doe een klein internetonderzoek 'falende IT projecten overheid'. Budgetoverschrijdingen zijn eerder regel dan uitzondering. Dat is overigens niet alleen bij IT projecten zo, kijk ook maar eens naar complexe infrastructurele werken. Vaste budgetten bij zeer hoog complexe projecten zijn eigenlijk een wassen neus.

Hoe gaat Agile dan om met het budget? Eigenlijk gewoon niet. Tuurlijk, je kunt een budget reserveren en aan de slag gaan, maar dan weet je dus per definitie niet zeker wat je krijgt. Dat was al zo natuurlijk, maar in de Agile werkwijze is dat gewoon expliciet benoemd. Kortom, je blijft per definitie binnen budget! Overschrijding kan je ook gaandeweg bepalen: is het mij waard om verder te gaan om een bepaald onderdeel nog te realiseren? Eigenlijk knip je het op.

"Ja maar dat is flauw! Je verandert de spelregels!". Ja. Klopt. Dat is ook waarom ik geen statistisch onderzoek nodig heb om te onderbouwen waarom dit beter werkt. Het is gewoon een logische gevolgtrekking: als je niet kunt winnen met de bestaande spelregels moet je de regels aanpassen. Het heeft dus ook bijzonder weinig zin om hier onderzoek naar te doen: common sense en daarmee logica zegt dat deze uitgangspunten tot betere resultaten leiden.

Slaagt dan opeens alles als we agile gaan werken? Nee, natuurlijk niet. Als ik teruggrijp naar mijn vergelijking aan het begin van dit stuk is het ook niet zo dat elke keer als ik pistool aan mijn hoofd zet en ik vuur dat ik zal overlijden. De kans op succes wordt echter wel een stuk groter doordat je bepaalde valkuilen en spelregels hebt aangepast aan veel beter werkende, logische alternatieven.

Is dit dan op alles toepasbaar? Nee, ook niet. Mijn redenatie hierboven kan ik alleen maken voor mijn eigen vak. De managementhype van de afgelopen jaren rondom Agile erger ik me ook kapot aan. Ik kan inmiddels ook uit ervaring zeggen dat nadat we dit nu zo'n 10 jaar als steeds breder gedragen 'standaard' manier van werken hanteren in het vak dat het voor ons werkt. Maar wij opereren in een enerzijds vaak erg complexe projectomgeving gecombineerd met veel onzekerheid en verandering. Daar heb je naast je methodiek ook nog heel veel andere gereedschappen voor nodig!

Disclaimer: Ik heb dit stuk geschreven naar aanleiding van een stuk door Japke-d. Bouma over het ontbreken van bewijs van effectiviteit van Agile methodieken. Vervolgens raakte ik verzeild in een discussie met Richard Engelfriet door een snelle en onzorgvuldige tweet met een bron mijnerzijds, die er vervolgens een stuk op LinkedIn aan wijdde. Dit is een antwoord op dat laatste stuk. Hetgeen mij persoonlijk vooral stoorde was dat Agile werken in de volle breedte vooral als 'leuke hobby' gezien wordt en dat ik dat zou moeten toegeven. Dat is voor mij als professional geenszins het geval, ik vind Agile werken ook helemaal niet leuker dan anders werken - het enige dat mij persoonlijk drijft is dat ik dicht bij mijn klant optimaal lever wat hij of zij verwacht.

Overigens verder alle lof en respect voor de professionele schrijvers die ik noem, ik lees hun werk met veel plezier, maar ik word niet graag in het hokje 'hobbyist' gestopt ;).