Vandaag wil ik het hebben over de wijdverbreide gewoonte binnen Scrum teams om na elke sprint een demo te geven van nieuwe functionaliteit voor de eindgebruiker. Ik vind dat een twijfelachtige gewoonte omdat het een kwaliteitscultuur kan tegenhouden en schaden. Noch de Scrum Guide noch gezond verstand verlangt dat je met vaste regelmaat zo’n demo houdt. De Agile 2 beweging begrijpt dat het dodelijk is voor rustige reflectie en uiteindelijk echte agility als je team verandert in een “featurefabriek”.

Veel mensen denken dat de Scrum Guide meer dicteert dan er daadwerkelijk instaat. Zo rept hij nergens over story points, planning poker of Fibonacci-reeksen. Net als aan religies allerlei geloofsartikelen kleven die in geen enkel heilig boek staan, zo heeft Scrum ook geleid tot een aantal geaccepteerde gebruiken gebaseerd op verkeerde aannames. Een van zulke is dat je aan het eind van elke sprint een demo behoort te geven. Dat staat nergens. Ja, we hebben een review, waarin we de resultaten van de Sprint evalueren en aanpassingen bepalen voor de toekomst. De Sprint Review is een actieve sessie en het Scrum Team moet voorkomen dat het slechts een presentatie wordt [mijn vertaling]. Het staat er echt .

Door te sturen op regelmatige demo’s loop je het risico op een mentaliteit van rapid prototyping. Die is schadelijk voor de kwaliteit en werkt technische schuld in de hand. Dit zal ik verder argumenteren. Scrum voorkomt namelijk niet dat in het verkeerde team zo’n vaste cadans van nieuwe functionaliteit uitbrengen een prikkel voor haastwerk wordt. Tegen dit argument – en trouwens tegen elke andere waarschuwing voor de keerzijde van Agile gebruiken – kun je in stelling brengen dat er helemaal geen probleem is zolang je je aan de regels houdt. Het klopt ook dat geen enkele extreme sport gevaarlijk is zolang je weet wat je doet. Maar dat vind ik te simplistisch. Het probleem is juist dat we wél weten hoe je hoogwaardige software bouwt maar dat onze foutieve interpretatie van het framework ons weerhoudt om die regels goed uit te voeren.

Het is zinvol om regelmatig op te leveren en voortdurend feedback te verzamelen van je belangrijkste stakeholders op nieuwe functionaliteit. Zodra je iets nuttigs en interessants te tonen hebt moet je het delen. Maar alleen als het ook goed gedaan is. Vereis niet dat je elke brok werk omschrijft als een klassieke user story: “Als eindgebruiker wil ik…”. De techneuten hebben ook hun behoeftes. Een software feature is niet altijd iets tastbaars dat je makkelijk kunt presenteren. Waardevol en zichtbaar zijn verschillende dimensies. Gebruikers zien het topje van de ijsberg, maar het zijn de delen die ze niet zien en niet boeiend vinden die de ijsberg laten drijven. Van een hoogwaardig product kun je niet bij elke oplevering bruikbare functionaliteit opleveren. Vanuit gebruikersperspectief lijkt het misschien soms alsof je geen voortgang boekt. Dan gebruik je de review om je stakeholders op te voeden dat dit erbij hoort en dat je wel degelijk nuttig werk hebt verzet.

Ondanks alle praat over een duurzaam tempo (sustainable pace) moet je een team niet opleggen elke twee weken op dinsdag om twee uur de nieuwe toeters en bellen te etaleren. Dat is vragen om haastwerk. Een zodanig resultaatgericht team dat met de regelmaat van de klok iets tastbaars moet opleveren klust het ene prototype na het andere in elkaar. Het publiek van je demo kan niet bepalen of je hebt beknibbeld op cruciale niet-functionele vereisten. Dat is ook niet hun taak. Maar als er een knop mist of scheef staat zullen ze je dat meteen zeggen. Daar is zo’n demo ook voor. Prima om de feedback loop met je gebruikers kort te houden, maar pas als je ook echt iets goeds hebt om te laten zien. Tijdens zulke sessies bepaal je of de vereisten juist zijn geïnterpreteerd en geïmplementeerd. Maar een demo is geen publieke rigoureuze testsessie. De ernstige bugs die je hebt veroorzaakt door je te haasten komen tijdens die sessies niet bovendrijven.

Al het werk dat je had moeten doen maar niet aan toekwam vergroot je technische schuld. Het is het verschil tussen de gewenste en de opgeleverde kwaliteit. Scrum spoort je natuurlijk niet aan om half werk op te leveren. Als een feature niet gedaan is volgens het boekje ga je hem niet presenteren en al helemaal niet opleveren. Tot zover de theorie. Gemeente Amsterdam promoot ook geen ladderzatte stag nights het hele jaar door – ze scheppen alleen maar de gelegenheid. Als jouw team geacht wordt elke twee tot drie weken iets smakelijks voor te schotelen wil je je publiek niet teleurstellen. Dan ben je dus een featurefabriek geworden. Als iemand een kwaliteitsverbetering suggereert die de demo-deadline in gevaar brengt roep je die irritante dooddoener “You ain’t gonna need it”, terwijl je weet dat je het straks wel degelijk nodig hebt. Twee voorbodes dat je verkeerd bezig bent: de hardening sprint en de definition of done-done.

De kwaliteitslacune die je met elk nieuw stukje technical debt creëert wordt een ravijn. Sommige bedrijven laten het maar gebeuren. Ze schrappen de hele boel en beginnen opnieuw. Andere teams introduceren een hardening sprint. Ze zetten twee weken hun schouders exclusief onder de schuld en het achterstallig onderhoud aan de bestaande functionaliteit. Dat voelt als twee weken in januari met tegenzin vasten en niet drinken na de feestdagen. Gênant, omdat je je nooit zo had willen laten gaan. Net zo goed vinden software teams dat ze de hardening sprint eigenlijk niet nodig zouden moeten hebben. Dat is hun eigenlijk te min. Maar als je hem nodig hebt kun je hem maar beter wel houden. Het laat zien dat je tenminste je zwakheden onderkent.

Ben je klaar of klaar-klaar? Stel je voor dat een piloot telkens aan de luchtverkeersleiding moet vragen of ze wel echt cleared for take-off zijn. Dat zou wat zijn. Regels om het luchtruim veilig te houden zijn niet flexibel – dat hoop ik tenminste! Regels om software te bouwen zijn boterzacht of worden glashard genegeerd. Daarom hebben we die malle definition of done-done. Klaar betekent dat iets de demo net op tijd heeft gehaald, zonder fatsoenlijke unit tests en documentatie.  Daarom stomen we door naar de volgende feature. Klaar-klaar blijft een Platonisch ideaal van perfectie dat we zo nooit bereiken.

In mijn vorige post over de artistieke mentaliteit illustreerde ik mijn punt aan de hand van de meester Stanley Kubrick. Zijn opleveringsritme van nieuwe films werd trager naarmate hijzelf steeds perfectionistischer werd. Tussen Full Metal Jacket en Eyes Wide Shut zaten meer dan tien jaar. Dit was nog eens iemand die volstrekt compromisloos was ten aanzien van het woord ‘klaar’. We zouden wat meer zoals hij moeten zijn, al is het maar omdat genoegen moeten nemen met slechte kwaliteit om maar regelmatig features op te leveren je krenkt in je trots als vakman. Maar bedenk dat povere kwaliteit ook doodleuk een bedrijfsstrategie kan zijn. Sommige clubs met Unicorn aspiraties willen zo snel mogelijk meer dan een miljard dollar waard zijn en dan hun krakkemikkige digitale kroonjuwelen doorverkopen aan de eerste goedgelovige investeerder. Maak je daar maar snel uit de voeten.