De vergeten stakeholder

Het lijkt zo mooi die Scrum familie: de Scrum Master, Product Owner en ontwikkelaars die samen aan 'onze zaak' werken. Gebonden door de omerta van Scrum, de Scrum Guide, gaan ze voor elkaar door het vuur. Waarin de belangen van verschillende stakeholders worden afgewogen voor het beste product. Met als doel dat de business zoveel mogelijk waarde krijgt. Maar in de praktijk 'slaapt de theorie te vaak bij de vissen.' Met als gevolg dat ontwikkelaars vaak onderspit delven en uiteindelijk niemand blij is. Daarom vijf valkuilen voor Product Owners (en opdrachtgevers) in The Godfather stijl.

I'm gonna make him an offer he can't refuse.

Vito Corleone

Regelmatig heb ik Product Owners zien zwichten onder de druk vanuit de business. Het is geen aanbod dat onder schot wordt gedaan. Maar om gebruikers, klanten of projectleiders tevreden te houden, accepteren Product Owners regelmatig een 'niet te weigeren aanbod.’ Onder druk worden stappen overgeslagen. Er wordt niet gekeken of het idee binnen de visie of productdoel past en ontwikkelaars hebben geen mogelijkheid om input te leveren over (technische) haalbaarheid. Achteraf blijkt dan ook vaak dat ‘het spoedje’ toch niet zo belangrijk was, dat de feature op de plank blijft liggen, niet in het werkproces past of zelfs onverwachte negatieve bijwerkingen heeft.

This is the business we’ve chosen

Hyman Roth

Softwareontwikkelaars zitten minimaal één keer per maand samen om de aankomende taken en werkzaamheden te plannen: de Sprint Planning. Maar het komt regelmatig voor dat de Product Owner opdraagt wat er moet gebeuren en er geen planning is. Dat de Product Owner zegt: “de business geeft prioriteit aan deze taken, dus hoeveel van het lijstje kunnen we realiseren?” Als dit gebeurt, dan hebben ontwikkelaars geen inbreng meer en wordt het ontwikkelteam een featurefabriek. Het uitspuwen van nieuwe functionaliteiten is belangrijker dan kwaliteit, het verbeteren van bestaande processen en een toekomstbestendig softwareproduct. Uiteindelijk levert dat software op waar niemand blij van wordt. Gebruikers mopperen dat het programma ‘niet werkt’. Opdrachtgevers mopperen dat aanpassingen te veel tijd kosten. En ontwikkelaars mopperen dat er geen overzicht is en dat de applicatie op sterven na dood is. Het is een keuze, maar je moet wel de gevolgen leren leven.

“I knew Moe, I knew he was head-strong, talking loud, saying stupid things. So when he turned up dead, I let it go. And I said to myself, this is the business we’ve chosen.”

Forgive. Forget. Life is full of misfortunes.

Mario Puzo

Zeker bij opdrachtgevers die van deadlines houden, hebben Product Owners soms angst om ‘slecht nieuws’ te vertellen. Dat kan al vooraf zijn, wanneer ontwikkelaars denken dat de deadline onrealistisch is. Of tijdens de bouw wanneer onvoorziene gebeurtenissen, of zelfs lijken in de kast, voor vertraging zorgen. Alleen is dat niet te voorkomen. Het leven zit nu eenmaal vol ongelukjes. Besef dat ontwikkelteams hun stinkende best doen. Als er een tegenvaller is, dan is de uitdaging om te vergeven en te vergeten. Verwijten lossen niets op. Sterker, boos worden of zelfs straffen werkt ontzettend demotiverend voor ontwikkelaars. Het enige dat je kan doen is leren en verbeteren. Daarvoor zijn transparantie en vooral luisteren essentieel voor zowel opdrachtgevers en ontwikkelaars. Zodat uitdagingen en gevaren geadresseerd worden en snel kansen benut worden.

It’s not personal, Sonny. It’s strictly business

- Michael Corleone

De beroemdste mythe is dat degene die betaalt bepaalt. Klant is koning. Keizer misschien zelfs. Maar de keuzes die een klant, gebruiker of opdrachtgever maakt zijn anders dan die een ontwikkelaar zou maken. Dat is logisch: het is niet persoonlijk, het is enkel zakelijk. Business op de korte termijn. Wat wordt vergeten is dat het succes van goede software zich op de lange(re) termijn pas echt uitbetaalt. “Strictly business” gaat voorbij aan de kennis, kunde en vakmanschap van ontwikkelaars. Sterker, het is een mentaliteit waar uiteindelijk een harde waarheid achter zit:

I respect those who tell me the truth, no matter how hard it is

- Michael Corleone

Als de Product Owner alleen naar de business en niet naar de ontwikkelaars luistert, kan er snel veel gedaan worden. Management legt simpelweg op wat er moet gebeuren. Maar dat wil niet zeggen dat het op de juiste of beste manier gebeurt. JA-knikkers zijn op langere termijn een bedreiging voor de business. Hoe effectief is de Noord-Koreaanse applausmachine? Hoeveel waarde levert de featurefabriek van de “Grote Leider?”

De harde waarheid is wanneer je vergeet dat ontwikkelaars ook een stakeholder zijn, je eindigt met een scenario waar niemand blij wordt:

• Om snel en onder druk te bouwen leveren ontwikkelaars kwaliteit in
• Het (on)bewust inleveren van kwaliteit noemen we technische schuld
• Technische schuld zorgt voor groeiende overhead
• Waardoor de ontwikkelsnelheid lager wordt
• En er meer kans op fouten en bugs is
• Dit wordt versterkt door gebrek aan kwaliteitsborging
• Waardoor ontwikkelaars bang zijn om oude code verbeteren
• Een vicieuze cirkel is het gevolg
• Bugs voorkomen en repareren wordt steeds kostbaarder in tijd en geld
• Met als eindresultaat dat ALLES, inclusief nieuwe features, ideeën en verbeteringen, langer duren