Fingerspitzengefühlclubs

5 aug 2022 -

Het maken van de juiste keuzes op gebied van productontwikkeling kan moeilijk zijn, vooral wanneer je nieuw bent in een organisatie, een domein of wanneer je gewoonweg veel experts om je heen hebt die de waardevolle informatie bezitten.

Wanneer je te maken krijgt met al die collega’s uit verschillende teams en disciplines, raken verschillende krachten en belangen met elkaar verstrengeld en blijf je soms zitten met een breed scala aan meningen en gedachten over de juiste volgende stap voor een product.

Hoe kom je af van meningen, onderbuikgevoelens en het redeneren op basis van fingerspitzengefühl? Door te democratiseren en te rationaliseren. Hoe je dat doet lichten we toe in deze blog.

Product Ownership

Een Product Owner heeft de prachtige taak om focus te leggen op de meest waardevolle verbeteringen die aan een product gedaan kunnen worden. Als Product Owner ben je een groot deel van de tijd bezig met Stakeholder management: iedere Stakeholder heeft eigen ideeën over verbeteringen aan het product en legt op verschillende creatieve manieren uit waarom hetgeen zij in gedachten hebben direct gerealiseerd moet worden. Een hele belangrijke skill die een Product Owner moet hebben is dan ook ‘nee’ zeggen en die ‘nee’ kunnen onderbouwen helpt daarbij aanzienlijk.

Figuur 1 Product Owner en haar stakeholders

Soms kunnen de verschillende verantwoordelijkheden, die doorgaans van een Product Owner zijn, niet bij 1 persoon belegd worden of worden de gewenste kwaliteiten niet bij 1 persoon gevonden. Misschien niet de meest optimale situatie, maar een die je niet ontslaat voor het maken van de juiste keuzes. Dat er niet 1 persoon kan worden aangewezen die de stakeholders voldoende kan managen om zelfstandig keuzes te maken met betrekking tot de implementatie van de productvisie kan verschillende redenen hebben. Het kan bijvoorbeeld zo zijn dat de juiste persoon niet geworven kan worden, maar in sommige gevallen heb je ook te maken met een omgeving met meerdere seniore en/of dominante stakeholders binnen de organisatie, zoals een Project Manager met veel mandaat en controle.

De afgelopen jaren zie ik steeds vaker, binnen organisaties met een uitdaging op dit gebied, een club ontstaan om productontwikkeling te organiseren. Product Ownership is nooit een gedeelde verantwoordelijkheid, maar kan voor een gedeelte heel goed democratisch ingericht worden, er blijft wel iemand die de knopen doorhakt. Wanneer je die persoon niet benoemd hebt tot de Product Owner; weet dat die persoon dat wel is.

Ik noem het expres een club, terwijl het doorgaans een een ‘Product team’ of ‘Multi-disciplinair team’ wordt genoemd. Ik probeer niet te muggenziften op semantiek. In The Five Dysfunctions of a Team van Patrick Lencioni wordt de term “First Team” gebruikt om te illustreren dat leden van leiderschapsteams vaak een ander team als belangrijker zien of hogere prioriteit geven dan het leiderschapsteam.

Figuur 2 Product Ownership democratiseren met stakeholders in een ‘Team’

Voor de club die verantwoordelijk is voor het maken van de juiste keuzes geldt dit vaak ook. De meest voorkomende samenstelling van dit groepje is namelijk een combinatie van collega’s die in een ander team een vooraanstaande rol hebben, zoals een de Project Manager van een belangrijk klantproject, Scrum masters, managers van de Ontwikkelafdeling. Doorgaans hebben de leden dus een ander ‘First Team’ en is het een uitdaging de verschillende belangen elkaar niet te laten bijten. Wat weerhoud je ervan om belangen van, bewust of onbewust, jouw specifieke team te behartigen in dit team?

Formalisering

Organisaties die een dergelijke structuur introduceren raad ik vooral aan om afstand te nemen van het fingerspitzengefühl. Het koffiedik kijken, het speculeren op basis van een gevoel en jezelf laten leiden door arbitraire uitspraken als “het kan toch niet zo zijn dat” introduceren verschillende, potentieel gevaarlijke, typen van Cognitive Bias waardoor de verkeerde beslissingen worden genomen. Vaker dan eens heb ik programma’s en ontwikkelingen meegemaakt die onvoldoende onderbouwd werden opgepakt, veel ontwikkeltijd en geld kostten en uiteindelijk door minder dan een handvol gebruikers werd gewaardeerd.

Om objectiever te kijken naar wat het beste is voor het product kun je de waarde uitdrukken in cijfers. Het formaliseren van die waarde neemt subjectiviteit en interpretatie niet weg, maar brengt wel voldoende structuur, wat helpt om als team op een uniforme manier naar waarde te kijken.

Om waarde te formaliseren adviseer ik deze op te knippen in verschillende factoren. Over 1 as kijken naar de waarde van ontwikkelingen is namelijk erg ingewikkeld. Bij enkele stories op een backlog is het 1 ding, maar wanneer je op een hoger niveau kijkt naar productontwikkeling wordt het complexer. Wanneer je waarde over een enkele as bepaalt, is de afstand naar waarde bepalen over 2 assen eigenlijk best dichtbij.

Value x Customers matrix

Ik ben groot fan van een goede Triage meeting. Op vaste momenten kijken naar gemelde issues met een aantal personen is een geweldige manier om kennis te delen. Het liefst gebruik ik voor deze meetings (en triage van issues in het algemeen) een 5×5 risk matrix om samen prioriteiten te bepalen.

Dit model komt uit Risk Management en vind ik bijzonder waardevol voor het doen van een eerste inventarisatie van prioriteit. Het idee is dat de prioriteit over 2 assen wordt bepaald. Je geeft de impact een score van 1 tot 5. Deze score geeft aan hoe groot iets eigenlijk is. Bij de boordeling van een bug beschouw je 1 als een verwaarloosbaar bijvoorbeeld iets puur esthetisch. Een 5 daarentegen, houdt in dat een gebruiker volledig geblokkeerd wordt in het doen van werk bij het tegenkomen van een issue.

De andere as, likelihood, beschrijft hoeveel gebruikers last kunnen hebben van een issue. Hierbij kun je een 1 beschouwen als een probleem dat enkel in bepaalde Edge Cases voorkomt voor een enkele gebruiker terwijl een 5 betekent dat bijna iedereen er voortdurend last van heeft.

Figuur 3 Impact x Likelihood Risk Matrix

De waarden vermenigvuldig je met elkaar en verschillende doorsnedes in de matrix kunnen verschillende prioriteitsaanduidingen met zich meebrengen. De belangrijkste reden om een matrix als deze te gebruiken, is dat je over twee assen de discussie voert in plaats van enkel over prioriteit. Zo kun je na een discussie besluiten om de (geschatte) impact van 2 naar 3 te verhogen, dat wil niet zeggen dat daarmee automatisch de prioriteit naar een hoger niveau gaat.

Zoals gezegd wordt dit model vooral gebruikt in risicomanagement, maar het model is snel gedraaid en je zult zien dat het gemakkelijk voor betere gesprekken zorgt in jullie ‘Product Team’.

Figuur 4 Formaliseren van waarde over 2 assen

Deze waardes kun je op verschillende manieren met elkaar bepalen. Schrijf bijvoorbeeld voorbeelden op die vallen in de verschillende Value categorieën om vergelijkingsmateriaal te hebben (zoals de baseline in Scrum, if that makes sense) en op dezelfde manier kun je ook ‘pokeren’ om Value, zoals dat ook bij Planning Poker in Scrum gaat.

Het belangrijkste effect van het gebruik van de matrix is dat je prioriteit over meerdere assen beoordeelt en daarmee subjectiviteit creëert.

WTF is WSJF

Hoewel het ogenschijnlijk arbitraire getallen zijn, ben je wel degelijk aan het werken met cijfers. En dit maakt het onderbouwen van keuzes gewoonweg een stuk eenvoudiger.

WSJF, Weighted Shortest Job First, is een term die ik heb opgepikt toen ik voor het eerst bij organisaties kwam waar SAFe geïmplementeerd was. Even los van het gebruik van SAFe, heb ik de WSJF en de bijbehorende Cost of Delay op veel momenten kunnen inzetten.

De Cost of Delay bepaal je door 3 cijfers te bepalen, in plaats van 2. En de Cost of Delay is toekenbaar aan initiatives, epics, stories, technische verbeteringen of gehele waardeproposities.

Figuur 5: Cost of Delay bron: ScaledAgileFramework.com

De korte uitleg die ik hierover geef aan klanten is dat je Cost of Delay moet zien als een representatie van het geld dat je iedere dag misloopt zolang je iets niet ontwikkeld hebt. Afhankelijk van de situatie kan geld vervangen worden voor klantwaarde of kosten, het principe blijft hetzelfde.

De Cost of Delay is een benadering die door 3 getallen wordt bepaald;

• De User-Business Value is een relatief getal voor klantwaarde. Wat loopt de klant nu mis? Bespaart het klanten veel tijd? Maakt het zaken makkelijker? Of is dit zelfs een waarde die we als life-changing kunnen categoriseren?
• Time Criticality geeft aan hoe belangrijk iets nu is. Een stukje IT Governance in 1 getal. Deze is laag wanneer een verandering ook volgende jaar pas geimplementeerd kan worden en hoog wanneer je deze feature gisteren al nodig had.
• Tot slot nog de “Risk reduction-opportunity enablement value”. Ook wel ‘bijvangst’ genoemd. Een samenvattende waarde voor alles dat niet direct klantwaarde oplevert, zoals security.

Deze 3 waarden om de Cost of Delay te bepalen zijn relatief overzichtelijk en kunnen wederom bepaald worden door een planning poker tactiek. Wanneer je als team een gemeenschappelijk beeld hebt bij de betekenis van deze assen komen uit inschattingen getallen voort waarmee je verschillende opties relatief tot elkaar kunt vergelijken

Een vergelijkbare waarde als die van de Value x Customer matrix is dat de Cost of Delay wordt gedeeld door de relatieve Job Size.

Figuur 6 Weighted Shortest Job First formule bron: ScaledAgileFramework.com

Voor de Job Size kunnen verschillende eenheden gebruikt worden: ‘aantal sprints’, ‘Story Points’, keiharde euro’s, ‘Functiepunten’, enzovoorts. Mits je altijd dezelfde eenheid gebruikt wanneer je gaat vergelijken. Door de waarde, Cost of Delay, te delen door de Job Size krijg je een mooie genormaliseerde waarde die we de Weighted Shortest Job First (WSJF) noemen. Bijvoorbeeld 12/4=3 of 18/6=3 of 10/2=5.

De Weighted Shortest Job First methodiek is bedoeld om aan de hand van een genormaliseerde waarde te kiezen welke activiteiten te ondernemen omdat ze de meeste bang for your buck geven. Een hogere WSJF is beter.

Samenvattend

Door het beleggen van sommige verantwoordelijkheden van de Product Owner bij een club mensen, kan voor die personen een scheve verhouding of belangenverstrengeling ontstaan met hun ‘First team’.

Door het formaliseren van waardebepaling krijg je minder fingerspitzengefühl in de club die prioriteiten en waardebepaling doet, omdat je werkt met harde cijfers. Het bepalen van waarde met verschillende assen maakt dit nog duidelijker. Je kunt een discussie voeren over 1 of meerdere assen die de prioriteit bepalen, maar niet direct over de prioriteit zelf. Hiermee los je problemen met mandaat niet op, maar kun je wel goed uitleggen waarom en hoe een besluit over de prioriteiten in productontwikkeling tot stand is gekomen. Deze methodiek is zowel intern als extern te gebruiken. Doe er je voordeel mee en gebruik dit om betere, goed onderbouwde besluiten te nemen!