Slecht nieuws en Sprint Reviews

Natuurlijk, het liefst toon je tijdens een Sprint Review de coole nieuwe features die jij en je team deze Sprint gebouwd hebben. Maar helaas, niet elke Sprint verloopt even soepel. Obstakels van buitenaf - een defecte laptop, ziekte, een productieverstoring - kunnen het ontwikkelwerk verstoord hebben, of een feature kan groter blijken dan op voorhand werd gedacht.

Wat doe je wanneer je deze Sprint Review geen blijde boodschap hebt om te verkondigen?

Oneerlijk

Dit is een optie: je zou de problemen kunnen verzwijgen. Noem de feature die niet afgekomen is gewoon niet, en concentreer je op het werk dat wel af is. Of: moffel de boel weg. Noem de feature, demo ’m zelfs, maar laat alleen het gedeelte wat zien al werkt en verzwijg de rest.

Er bestaat een woord voor dit soort deze strategie, en dat woord begint met een l en eindigt op iegen. Of nee, dat is te sterk. Het begint met een h en eindigt op alve waarheid verkondigen. O wacht, dat zijn drie woorden. Hoe dan ook, je bent oneerlijk, dat is het punt dat ik probeer te maken.

Mijn voorkeur heeft het niet, maar je zou dus oneerlijk kunnen zijn. Misschien levert dat zelfs wel heel erg leuke Sprint Reviews op met heel erg blije stakeholders, wie weet. Het levert in elk geval een leukere Sprint Review op dan een waarin je het eerlijke verhaal vertelt, toch?

Niet noodzakelijkerwijs.

Voor de gek

Allereerst is het immoreel om je stakeholders voor de gek te houden. Ik houd er in het algemeen niet van om met morele veroordeling te strooien - het slaat discussies doorgaans dood in plaats van dat het ze verder helpt -, maar zo is het wel. Liegen is verkeerd, vraag maar aan Immanuel Kant. En als Kant het zei, dan is het zo.

Maar ook vanuit strategisch oogpunt is verzwijgen of wegmoffelen een verkeerde keus. Eerlijkheid duurt het langs, zegt men ook wel. In elk geval: bedrog duurt betrekkelijk kort. Wat als je stakeholders vragen naar de feature die je verzwijgt, of een muisklik van je verlangen waarvan je weet dat die je applicatie doet crashen?

In dat geval sta je behoorlijk voor paal (of een synoniem daarvan, al naar gelang de grofgebektheid van je team en/of stakeholders). En dat niet alleen, je actie heeft het vertrouwen van je stakeholders geschaad. Hoe moeten ze er vertrouwen in hebben dat je functionele, betrouwbare software oplevert wanneer ze je niet op je woord kunnen geloven wanneer je beweert dat je product functioneel en betrouwbaar is?

Doel

Bovendien gaat zo’n strategie helemaal voorbij aan het doel van een Sprint Review. Zelfs al zou oneerlijk zijn een leukere Sprint Review opleveren, het verzorgen van een toffe demo is niet het doel van die sessie.

Het doel van een Sprint Review is de stakeholders op de hoogte te houden van de ontwikkeling van jullie product. Dat betekent: laten zien wat er gedaan is, daar feedback op krijgen, en vervolgens mede op basis van die informatie beslissen wat er de volgende Sprint moet gebeuren. En het betekent ook: laten zien wat er niet gedaan is, daar feedback op krijgen, en vervolgens mede op basis van die informatie beslissen wat er de volgende Sprint moet gebeuren.

Dit is wat je moet doen bij slecht nieuws: je verkondigt een minder blijde boodschap. Je vertelt dat het team zich deze Sprint voor had genomen om een bepaalde feature op te leveren, maar dat dit helaas niet gelukt is. Je legt uit waarom dat het geval is, en hoe ver jullie desondanks gekomen zijn. Eventueel geef je een schatting af wanneer je de feature wél verwacht op te leveren.

Gevolgen

Bedenk eens wat de gevolgen zijn van eerlijk zijn tegen je stakeholders. Ten eerste breng je hen in de positie om een mening te kunnen vormen over de voortgang van het product. Wellicht ontaardt dat in een tirade, maar misschien volgt juist het tegenovergestelde. Stakeholders zouden zomaar kunnen beslissen: “Als jullie nog twee Sprints nodig hebben voor deze feature, dan is het misschien beter om deze (voorlopig) te laten vallen. Het is de investering niet waard.”

Door eerlijk te zijn kun je empathie kweken bij je stakeholders. Software ontwikkelen is moeilijk, moeilijk op manieren die de meeste stakeholders zich niet voor kunnen stellen. Doorgaans zijn die te ver verwijderd van de code om zich voor te kunnen stellen waar je allemaal tegenaan loopt. Door eerlijk te zijn, kun je je stakeholders duidelijk maken dat de wens die in hun ogen betrekkelijk eenvoudig is, in werkelijkheid een hoos aan problemen oplevert. Alleen door daar eerlijk over te zijn, kunnen jullie samen tot een oplossing komen.

Ten derde win je juist vertrouwen van je stakeholders met je eerlijkheid. Natuurlijk, hoogstwaarschijnlijk vinden ze het niet leuk om te horen dat hun verwachtingen niet worden waargemaakt. Maar ze zullen je ten minste respecteren voor het feit dat je er eerlijk over was.

En nadat jullie uitgehuild zijn en elkaar een (digitale) knuffel hebben gegeven, ga je gewoon weer aan het werk. En je kunt jezelf ’s avonds in de ogen kijken. En dát is goed nieuws, ik bedoel maar.

communicatie · empathie · professionaliteit · scrum · sprint review · stakeholders