scrummaster.nl

Een belangrijk gegeven in Agile is het verzamelen en reageren op feedback. Hoe meer en hoe eerder hoe liever, en “fail fast”. Maar je kan ook teveel en te vroeg feedback krijgen.

Op het moment dat ik dit schrijf is mijn vrouw onderweg naar de andere kant van het land. Ik kan precies zien waar ze rijdt door middel van de EnRoute applicatie op haar smartphone. Ik zie precies wanneer ze van snelweg wisselt of in een file terecht komt, waarbij ik gelijk maar even de informatie over de file stuur.

Maar het komt ook wel eens voor dat er geen informatie verstuurd wordt. Als dat iets langer duurt dan een paar minuten merk ik dat er toch een ongerustheid ontstaat. Zou er wat gebeurd zijn? Voor de zekerheid bel ik maar even… Gelukkig, een nieuwe update! Gefascineerd blijf ik kijken hoe de reis verder gaat.

Eigenlijk krijg ik teveel informatie. Ik weet hoelang de reis gaat duren en ik hoef helemaal niet van minuut tot minuut te zien hoever deze gevorderd is. Eigenlijk zorgt de hoeveelheid informatie voor meer onrust zodra deze me niet meer brengt wat ik zou willen.

In het pre-agile tijdperk werd er nauwelijks vanuit de feedback gedachte gewerkt. Je maakte een plan en voerde het uit. En als de werkelijkheid niet overeenkwam met het plan dan was de werkelijkheid fout en diende je maar harder te gaan werken zodat het wel weer met elkaar in overeenstemming kwam. Of in ieder geval totdat het verschil dusdanig groot was dat het niet meer te ontkennen noch te repareren was. Met de introductie van Scrum kwam daar verandering in. Hier werd expliciet gesteld dat je een software project beter kan sturen door middel van meten en voorspellen.

Die boodschap is wel aangekomen en deze wordt doorgetrokken tot het extreme. Als feedback en het reageren daarop goed is dan is continue feedback en continue aanpassing nog beter. En dus moeten sprints korter. Vier weken? Veel te lang om een sprint stabiel te houden! Twee weken? Hoe hou je het vol, laat het idee van sprints toch los! Elke negen maanden een release? Dan gaan we failliet! We moeten na elke build vrijgeven, dan verdienen we onze investering tenminste gelijk terug en krijgen we snel feedback uit de markt!

Echter, om de analogie uit mijn vorige artikel door te trekken, een goede zeiler is iemand die niet op alle golven en windvlagen reageert, slechts op de belangrijke. Te snel reageren haalt de snelheid uit de boot en maakt dat het schip zich veel onrustiger gedraagt, wat weer invloed heeft om de opvarenden.

Je kunt wel zodra je een item af hebt gelijk een soort mini review houden, maar het risico dat je hier mee loopt is dat je gaat reageren op alle opmerkingen die dan gemaakt worden. Ik heb tenminste nog nooit meegemaakt dat er iemand was die niet iets wist op te noemen waarvan hij dacht dat het beter was dan hij voor zich zag.

Als persoon moet de ontwikkelaar al sterk in je schoenen staan om daar positief op te blijven reageren (“het is geen kritiek, maar constructieve verbetervoorstellen…). Ook de Product Owner moet wel heel goed kunnen balanceren wat nou nog wel en niet belangrijk is. De verleiding om dan toch nog net wat van de opmerkingen mee te nemen is moeilijk te weerstaan. De meeste mensen zijn nou eenmaal genegen om een ander een plezier te doen en we willen graag horen dat we het goed gedaan hebben.

En dus wordt er langer gesleuteld aan functionaliteit dan nodig. En zo vertraagt het project weer een beetje, bijna onmerkbaar maar opgestapeld genoeg. Net als vroeger, voordat we Agile deden. Behalve dat we het nu niet meer ‘te laat’ noemen, maar ‘we passen de op te leveren inhoud aan’.

Bij feedback uit de markt onstaat het risico voor handelen naar de waan van de dag. Een dergelijke reactieve houding zorgt ervoor dat de originele visie uit het oog verloren wordt, de visie die het bedrijf een voorsprong zou moeten geven op de concurrentie. Die het gat tussen ”hun” en “ons” dusdanig zou moeten maken dat ze het er warm van zouden krijgen. Het blijkt dat die zeer urgente features in praktijk helemaal niet zo urgent waren. Als we even gewacht hadden dan hadden we dat best kunnen inzien en hadden we beter aan belangrijke dingen kunnen werken in plaats van steeds te blijven rennen.

En je gebruikers? Zitten die echt te wachten op elke week weer een andere versie? Voor je gebruikers is je software slechts een hulpmiddel in het leven wat ze hebben. Niets anders dan hun stoel, bureau of bril. De meesten willen best af en toe een betere stoel, een hippere bril. Maar niemand zit te wachten op een monteur die elke dag een beetje aan je stoel komt sleutelen, of aan de opticien die steeds aan de pootjes van je bril zit te morrelen. Ondertussen willen ze doorgaan met wat ze willen of moeten doen, hun werk of hobby. Jouw software moet daar inpassen, het liefst zonder dat ze eigenlijk doorhebben dat ze het überhaubt gebruiken.

Als je nieuwe versie van software krijgt moet het verschil groot genoeg zijn om een klein beetje spanning op te bouwen. Om enthousiast te worden van de leuke dingen die nieuw zijn. Bij te veel, te vaak en te kleine wijzigingen ontstaat irritatie. Weer een update? Van mij hoeft het niet.

Natuurlijk is het niet goed om vast te blijven houden aan verwachtingen en plannen die verouderd zijn en niet meer realistisch, maar schiet niet door naar de andere kant en laat je niet gek maken door alle adviezen die beweren dat nog meer feedback nog sneller moet. Fail fast is geen houdbare strategie.