In agile ontwikkeling willen we niet alles tot in detail specificeren voordat we met coderen beginnen of tot de laatste euro uitwerken hoeveel het gaat kosten. Dat is een zinloze exercitie omdat je je met complexe software bouwen altijd op onbekend terrein begeeft. Vanuit een verkenningsvlucht zie je niet waar de valkuilen zitten, en totdat je met je voeten in de klei staat kun je lastig zeggen hoe ver het nog is en hoe lang het gaat duren. Dat is nu eenmaal de definitie van een complex domein. Zo zag vanuit ons vakantiehuisje in Crickhowell (Wales) de nabijgelegen Table Mountain eruit als een leuke wandeling. Uiteindelijk was hij toch een stuk steiler dan ik dacht.
Stel dat je je hebt voorgenomen om het komende half jaar vijf kilo af te vallen — we zitten immers nog in januari. Dat is een simpel doel en een duidelijke deadline. Dus laat je de zoetigheid staan en ga je ‘s ochtends een rondje rennen. Maar weet je van tevoren of dat doel haalbaar, zinvol of zelfs verstandig is? Op de agile manier pin je je niet vast op kilo’s en een datum. Het doel is immers om je lichamelijk en geestelijk welzijn te verbeteren door meetbare veranderingen in je leefstijl aan te brengen, beetje bij beetje, week na week, zonder verbeten naar de weegschaal te kijken. Als je je er structureel beter bij voelt moet het wel waardevol zijn.
Zo werkt het ook met software. We kunnen ontelbaar veel applicaties verzinnen en die op verschillende manieren bouwen, maar het algemene doel zou voor elk agile team hetzelfde horen te zijn: regelmatig waardevolle software opleveren. Ik noem dat de definition of what, naar analogie van de definition of ready en definition of done.
Regelmatige opleveringen zorgen voor een voorspelbare groei. Het product wordt steeds nuttiger, ook al gebeurt dat beetje bij beetje. De visie op het eindresultaat is immers niet in steen gebeiteld, en dat kunnen we ook niet. We geloven niet in first time right. De software groeit temidden van een veranderende wereld en dat geldt ook voor onze inzichten. Daaruit ontstaan ideeën voor nieuwe, gewijzigde en geschrapte functionaliteit. Wat je mag verstaan onder ‘regelmatig’ is onderwerp voor discussie, maar als je moeite hebt met een maandelijkse release heb je duidelijk nog een weg te gaan. Niettemin gaat regelmatig meer over cadans dan over het aantal opleveringen per jaar.
Wat we opleveren moet waardevol zijn. Dat is heel bewust een subjectief begrip. Het nodigt uit tot meer vragen en aannames, maar dat is juist goed. Waarde gaat verder dan winstgevendheid. Het is lastig om functionaliteit op waarde te beoordelen voordat het gebouwd is, zolang het product nog theoretisch is. Je kunt proberen het te voorspellen met een formule, maar dat is een onbetrouwbaar alternatief voor de praktijk. Daarom zijn gedetailleerde up-front ontwerpen onmogelijk goed te krijgen. Je waarde-oordelen over het nut van de functionaliteit zijn niet beter dan een verzameling inschattingen en die kun je onmogelijk allemaal goed hebben gehad. Met een werkende oplevering ben je veel beter toegerust om dat nut te toetsen.
Onder waardevol vallen wel meer positieve eigenschappen, zoals gebruiksvriendelijk, vrij van bugs en passend bij behoefte. Denk maar aan alle kwaliteitsaspecten van software (de ‘*-ilities) en hoe die uiteindelijk de waarde van de software onderuit kunnen halen als je ze niet op orde hebt. Hoeveel waarde heeft software die een crime is in het gebruik of onnodig moeilijk onder de knie te krijgen? Hoeveel waarde als het voortdurend crasht? En hoe cool de ontwikkelaars het ook vinden, als functionaliteit de eindgebruiker niet dient heeft het geen waarde.
Ik ben er niet op gebrand om de output van ontwikkelaars te kwantificeren zoals dat in Scrum doorgaans gebeurt met velocity, het aantal verwerkte story points per sprint. Waarde is een subjectief begrip terwijl story points de relatieve inspanning per iteratie proberen weer te geven. Je hebt geen burndown chart nodig om te zien wanneer je productie terugloopt; dat laat de klant je wel weten. En zelfs als het niet onmiddellijk zichtbaar is in het product dan zullen disfuncties in het team, technische schuld en verborgen gebreken zich echt op den duur gaan wreken. Het team is niet langer in staat de cadans van oplevering vol te houden en dat betekent ofwel minder opleveringen of minder waarde. Alles wat mis kan gaan in het proces zal zich uiten in kwantiteit of kwaliteit. Daarom is een regelmatige oplevering de beste gelegenheid om de vinger aan de pols te houden voordat het uit de hand loopt.
Een laatste opmerking tenslotte over de definition of what gaat over de veranderlijke en kneedbare aard van software die besloten zit in het woord regelmatig. Ja, je hebt software die op een ROM chip gebrand wordt en nooit een firmware upgrade krijgt. Maar de gemiddelde belasting-app is nooit af en zo hoort het ook. Om waardevol te blijven in een veranderende wereld moet ons doel niet een stuk software zijn, maar een stroom van software. Toch mooi om in zo’n bedrijfsmodel te mogen werken.