Het alternatief voor Roadmaps

Het volgende citaat van Generaal George Patton vond ik altijd al geweldig:

„Vertel mensen niet hoe ze iets moeten doen. Vertel ze wat er gedaan moet worden, en ze zullen je verrassen met hun vindingrijkheid".

Helaas doen roadmaps precies datgene waarvoor de generaal waarschuwt

Roadmaps vertellen teams wat ze moeten doen en hoe ze het moeten doen. Normaal gesproken gebeurt dat in de vorm van geprioriteerde lijsten met features of projecten, waarvan iemand daadwerkelijk gelooft dat ze het probleem zullen oplossen (ook als het probleem vaak nog helemaal niet duidelijk is of nog niet echt begrepen wordt).

Als er op jouw roadmap bijvoorbeeld iets staat als „PayPal als extra betaalmogelijkheid toevoegen", is de reden daarvoor dan dat je denkt dat er klanten zijn die niet met je andere betaalmethoden kunnen betalen? Of heeft het iets te maken met internationaal betalingsverkeer? Of denkt iemand misschien dat het een concurrentienadeel zou zijn om deze optie niet aan te bieden?

Ik heb al in meerdere artikelen aangegeven dat ik klassieke Product Roadmaps beschouw als de bron van heel veel verspilling (waste) bij productteams. Het artikel Mislukte producten gaat over dit onderwerp en in [Ongemakkelijke waarheden over productontwikkeling]/nl/product-owner/onaangename-waarheden-van-productontwikkeling/ "Unangenehme Wahrheiten der Produktentwicklung") ga ik dieper in op dit concept.

Omdat het probleem met roadmaps steeds meer aandacht krijgt, werd mij de laatste tijd vaker gevraagd om meer te vertellen over het alternatief voor roadmaps.

Een veelomvattend thema

In dit artikel wil ik dat proberen. Het is een groot onderwerp dat ook te maken heeft met thema's als productcultuur, empowerment en autonomie. Meestal heb ik minstens een uur nodig om dit allemaal persoonlijk aan iemand uit te leggen, maar ik hoop dat ik de essentie hier kan samenvatten.

Voordat we ons op het alternatief voor roadmaps storten, moeten we ons realiseren dat roadmaps zo lang gebruikt zijn omdat ze twee heel specifieke behoeften vervullen – en die behoeften verdwijnen niet zomaar.

1) Het management wil er zeker van zijn dat de teams als eerste werken aan de items met de grootste waarde voor het bedrijf.

2) Aangezien ze een bedrijf te leiden hebben, zijn er situaties waarin ze concrete deadlines en commitments nodig hebben – en met roadmaps kunnen ze die commitments vastleggen en bijhouden.

Wil een alternatief voor klassieke roadmaps in bedrijven geaccepteerd worden, dan moeten deze twee punten minstens net zo goed worden geadresseerd als voorheen.

Roadmaps hebben hun wortels in het oude gecentraliseerde Command-and-Control-model. Een aantal stakeholders houdt een meeting – meestal per kwartaal – om na te denken over de prioriteiten en projecten van de teams voor het volgende kwartaal.

In het productteam-model daarentegen moeten teams zelf kunnen uitvinden hoe ze de betreffende bedrijfsproblemen gaan oplossen waar ze zich mee bezig moeten houden.

Maar daarvoor is het niet voldoende om simpelweg goede medewerkers te hebben. Het team heeft de nodige context nodig. De teamleden moeten hebben verinnerlijkt waar het bedrijf precies naartoe wil, en ze moeten hebben begrepen wat hun eigen team aan dat overkoepelende doel moet bijdragen.

Om terug te komen op General Patton:

Zoals je misschien al weet, werkt ook het leger met het concept van autonome teams. Deze teams (Squads) worden bewust klein gehouden en zijn grotendeels autonoom. Ze houden altijd de gemeenschappelijke intenties in het oog, maar mogen zelf beslissen wat volgens hen de beste manier is om een bepaald probleem op te lossen.

Deze gemeenschappelijke intenties vormen de context die ik zojuist noemde. „Door middel van intenties worden de overkoepelende doelen en bedoelingen nauwkeurig geformuleerd… Duidelijke intenties leiden tot doelgerichte activiteiten bij de strijdkrachten. Ze geven weer wat de commandant wil bereiken en waarom, en ze zorgen bij de strijdkrachten voor een gevoel van verbondenheid. Normaal gesproken worden ze uitgedrukt door mogelijke effecten, doelen en gewenste resultaten… Echt goed geformuleerde intenties zijn ook zonder een grote hoeveelheid aanvullende details te begrijpen voor ondergeschikten."

Technologiebedrijven hebben de meest uiteenlopende mogelijkheden om deze context of intenties beschikbaar te stellen. Ik pleit echter voor twee heel specifieke componenten:

De productvisie: deze beschrijft het overkoepelende beeld van wat de organisatie als geheel probeert te bereiken.

De bedrijfsdoelen: deze beschrijven de specifieke, geprioriteerde bedrijfsdoelen voor elk afzonderlijk productteam.

Er zijn verschillende systemen en methodologieën om deze bedrijfsdoelen te managen. Mijn favoriet is momenteel echter het OKR-systeem (Objectives and Key Results).

Het idee op zich is vrij eenvoudig: vertel de teamleden wat ze moeten bereiken en hoe de resultaten worden gemeten. Laat het team vervolgens zelf beslissen wat volgens hen de beste manier is om de betreffende problemen op te lossen.

Stel je bijvoorbeeld voor dat je product momenteel 30 dagen nodig heeft voor het onboardingproces van nieuwe klanten. Om echter effectief te kunnen schalen, moet dat worden teruggebracht tot 3 uur of minder. Dat zou dus een goed voorbeeld zijn van een doel voor een of meerdere productteams: „De tijd totdat een klant live is, sterk verkorten." Een van de belangrijkste resultaten daarvan zou kunnen zijn: „Gemiddelde onboardingtijd minder dan 3 uur."

Ook al klinkt het concept van teamdoelen vrij eenvoudig, er zijn veel manieren om het in productteams en organisaties te institutionaliseren, en het kan enkele kwartalen duren voordat de organisatie de vruchten plukt van dit concept.

Er zijn een aantal inzichten over de productvisie en vooral over de goede toepassing van het OKR-systeem, die ik in de volgende artikelen centraal zal stellen. In de tussentijd kun je alvast het materiaal van Christina Wodtke bekijken.

Deze context is dus heel belangrijk – namelijk de productvisie en de teamdoelen.

In het begin heb ik erop gewezen dat we de twee belangrijkste redenen voor de goeie ouwe roadmaps in overweging moeten nemen. De eerste daarvan was de wens om eerst te werken aan de items met de grootste waarde voor het bedrijf. Het is hopelijk duidelijk dat het management voor deze behoefte zorgt door de specifieke doelen voor de organisatie en de prioritering daarvan aan te leveren. Het verschil is echter dat ze nu het belang van bedrijfsresultaten prioriteren in plaats van de subjectieve waarde van features.

De tweede reden was de noodzaak van commitments, waarop we ingaan met het concept van commitments met hoge integriteit. Dit heeft betrekking op situaties waarin we daadwerkelijk een commitment nodig hebben voor een datum of een bepaald resultaat.

Deze aanpak heeft een aantal voordelen:

Ten eerste zijn teams veel gemotiveerder wanneer ze zelf mogen bedenken wat volgens hen de beste oplossing voor het probleem is.

Ten tweede komt het team er niet zomaar mee weg om een gewenst feature of project op te leveren; het feature moet ook daadwerkelijk werken (wat gemeten wordt aan de hand van de Key Results). Zo niet, dan moet het team een andere aanpak uitproberen om het probleem op te lossen.

Ten derde – ongeacht waar het idee voor een oplossing vandaan komt – werkt de eerste aanpak heel vaak niet, en in plaats van dat te ontkennen, is men zich daar bij dit model zeer bewust van.

Het draait allemaal meer om Outcome in plaats van Output – dus het behalen van een zinvol resultaat, in plaats van alleen maar een of ander doel te vervullen.

Ik daag teams vaak uit om terug te kijken op het afgelopen jaar en zichzelf te beoordelen op basis van het slagingspercentage van hun roadmap, en wel met betrekking tot hoeveel items daadwerkelijk bijdroegen aan de bedrijfsdoelen. Als je dit doet en niet trots bent op wat je ontdekt, dan hoop ik dat je dit alternatief in overweging neemt. Zorg ervoor dat je productorganisatie beschikt over een overtuigende productvisie. Zorg ervoor dat elk productteam duidelijk gedefinieerde en geprioriteerde bedrijfsdoelen heeft. Zorg ervoor dat alle commitments die aangegaan moeten worden, commitments met hoge integriteit zijn.
En machtig nu je productteams, zodat ze zelf kunnen beslissen welke oplossingen zij het meest geschikt vinden voor bepaalde bedrijfsproblemen, en kijk hoeveel van je teams je zullen verrassen met hun resultaten.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.

Product Owner Seminar

=> Bezoek nu een Product Owner Seminar van de Agile Academy.

De Product Backlog

=> Lees meer over de Product Backlog in het agile lexicon.

De Product Owner rol

=> Leer meer over de rol van de Product Owner.