Wat is een agile roadmap?

In Agile, Intermediate by PeterLeave a Comment

Leestijd: 9 min.

Een roadmap is een visueel hulpmiddel dat de tijdsplanning weergeeft van het mogelijke groeipad van een product, de innovatie of teamdoelen. Alle verbanden tussen de verschillende deelprocessen staan overzichtelijk in één overzicht.

Een roadmap is vooral bedoeld voor het weergeven van de toekomstvisie in een lange termijn agenda. De roadmap gaat altijd uit van de klantbehoefte en toont met welke nieuwe activiteiten deze klantbehoeften zal worden ingevuld.

Het hanteren van een roadmap draagt mede zorg voor een juiste communicatie met stakeholders en teamleden. Het is immers voor iedereen duidelijk wat het ontwikkelpad is.

Door de langere horizon, wordt het ook duidelijk welke activiteiten op korte termijn dienen plaats te vinden.

In het Nederlands is roadmap ook wel routekaart. Deze Nederlandse term wordt niet tot nauwelijks gebruikt.

De focus van dit artikel is een agile roadmap, deze wordt generiek besproken, want er zijn veel varianten geschikt voor allerlei specifieke toepassingen.

De inhoud en vorm van een agile roadmap verandert continue, omdat de omgeving blijft veranderen.

Roadmaps bestonden al voor het agile tijdperk, dus wanneer is het een agile roadmap?

Wanneer is het een agile roadmap?

Wanneer zeg je nu dat een roadmap agile is? Dat blijkt best lastig te verwoorden. Onderstaand een aantal belangrijke criteria:

  • Als de roadmap het maken van heldere keuzes en het formuleren van concrete doelen ondersteunt.
  • Wanneer de roadmap bestemd is voor het delen van toekomstvisie en/of een positioneringsvraagstuk verhelderd.
  • De samenwerking tussen alle partijen vergemakkelijkt.
  • Bijdraagt aan professioneel prioriteiten te stellen.
  • Het als doel heeft om de klantvraag beter te bedienen.
  • De bedoeling heeft om de concurrentie voor te blijven, te anticiperen op trends en veranderingen van de klantvraag. Kortom, antwoorden geeft op kansen en bedreigingen.
  • Het stellen van heldere (team) doelen mogelijk maakt.
  • Ondersteunt wordt door agile mindset, zoals lean, design thinking, scrum en andere agile frameworks of -methodieken
  • Ondersteunt het maken van de keuzes voor de backlog.
  • Het ook ruimte biedt voor korte termijn denken, maar deze gebaseerd is op het lange termijn denken (visie).

Maar bovenal de innovatie en de inrichting van de innovatie op agile wijze stimuleert.

Wanneer is het geen agile roadmap?

Nu volgen eerst een aantal voorbeelden die absoluut ook in het opstellen van een agile roadmap thuis horen, maar deze niet genoeg zijn om het een agile roadmap te noemen:

  • Een roadmap is bij uitstek geschikt is om aan te tonen dat het voor de organisatie de moeite waard is om in deze (product) roadmap te investeren.
  • Het communiceert hoe de ontwikkeling zal gaan plaatsvinden en zorgt voor een continuïteit van de doelstellingen.
  • Het creëren van inzicht in het ontwikkelportfolio van een organisatie.
  • Als deze eenvoudig, begrijpelijk en een  strategisch hulpmiddel is op hoog niveau.
  • Het onderlinge communicatie verbetert.
  • Wellicht is je het opgevallen dat voorgaande punten allemaal redenen zijn om een roadmap te hanteren. Dus neem je bij het maken van een agile roadmap deze inzichten vanzelfsprekend mee.
  • Zodra er geen aanpassingen mogelijk zijn en de roadmap niet met een agile mindset is gemaakt is het geen agile roadmap.

In agile organisaties biedt een roadmap een leidraad in plaats van een strikt plan.

Roadmap versus Product Backlog

Het verschil tussen een roadmap en product backlog is soms niet geheel duidelijk. Dat zal nu worden toegelicht, het is met name een verschil in het beoogde niveau:

Een roadmap toont de strategische visie. Het ‘waar naartoe’ op de middellange tot lange termijn.

Een Product Backlog toont de kenmerken en initiatieven voor de nabije toekomst. Zie voor een volledige beschrijving: Product Backlog.

In de roadmap heb je het over Epics en thema’s en in de product backlog over de gedetailleerde kenmerken en taken die het increment aan het product gaan opleveren. Stel je eens voor dat je de volledige backlog met tientallen tot honderden taken zou moeten bespreken met stakeholders. Men ziet door de bomen het bos niet meer. Voor de volledigheid, in de backlog zie je gedetailleerde features en taken.

Verschil roadmap en Product Backlog in financiële termen:

Op het niveau van een roadmap heb je het over het toevoegen van klantwaarde met investeringen en opbrengsten op middellange en lange termijn o.b.v. het grote plaatje. Kortom, jouw investeringsaanvraag zou goedgekeurd moeten kunnen worden o.b.v. jouw heldere en duidelijke roadmap.

Bij de product backlog is het niveau: wat de op te pakken taak op korte termijn voor de klant aan waarde toevoegt.  

Het creëren van een roadmap is een uitdagende activiteit, zeker in een agile omgeving. We weten allemaal dat de wereld om ons heen snel verandert, de klantbehoeften van vandaag zijn niet gelijk aan die van morgen of overmorgen.

Deze tegenstelling zie je terug in de roadmap, je probeert een lineair plaatje te maken terwijl je heel goed weet dat de realisatie iteratief tot stand dient te komen.

Er zijn meerdere varianten van een  roadmap, in agile werken is veruit de bekendste de product roadmap.

Wie is de eigenaar van de agile (product) roadmap?

Volgens de agile werkwijze is de Product Owner de eigenaar van de agile roadmap. Feitelijk is de PO-er verantwoordelijk voor het succes van het product, anderen leveren een belangrijke bijdrage. Dit kunnen teamleden en stakeholders zijn.

Vanzelfsprekend is het verstandig om een agile (product) roadmap niet alleen te maken, dit doet de PO-er bij voorkeur samen met teamleden en andere betrokkenen. Het grote voordeel hiervan is dat iedereen heeft bijgedragen, iedereen weet wat er dient te gebeuren. Tevens is de urgentie duidelijk en zijn de onderlinge verbanden en afhankelijkheden helder. Een essentieel onderdeel van een goed team neerzetten.

In sommige organisaties heeft de rol van de PO-er een andere naam, maar in een agile werkwijze is slechts één persoon verantwoordelijk voor de (product) roadmap en product backlog. Vanzelfsprekend, want door de verstrekte bevoegdheden en verantwoordelijkheden kan deze persoon strategische en tactische zaken met elkaar verbinden.

De werkzaamheden van de Product Owner staan uitvoerig beschreven in het artikel: Wat is de rol van de Product Owner?  Dit artikel gaat verder met de beschrijving van de roadmap.

Roadmapping is een uitdaging!

Een roadmap lijkt de toekomst te voorspellen, maar het is echter een visie op de toekomst. Dus hoe vlieg je dit dan aan, hoe leer en verbeter je? En hoe wendbaar kun je zijn?

Voor het gemak wordt nu een product roadmap even als voorbeeld genomen. De inhoud van een product roadmap is een tussenvorm of combinatie van een marketingstrategie, een businessplan, een functiebeschrijving, een lijst met essentiële taken en doelstellingen met prioriteiten. Jawel, in één overzicht.

Wat is de inhoud van een Roadmap?

Wat moet worden meegenomen in een roadmap: een algehele visie, een tijdslijn, taak(omschrijvingen), doelstellingen en resultaten per fase en functie, gecombineerd met data (facts). Niet alles dient echter volledig te worden uitgeschreven, het is bovenal een strategisch middel dat zich richt op de hoofdlijnen.

In dit artikel is de roadmap gekoppeld aan de OKR-methode. De reden hiervoor is dat gebruikers van de roadmap het risico lopen om ‘mooie’ dingen te gaan doen. In het huidige agile werken is het de wens om e.e.a. zuiver meetbaar te maken. De OKR-methode ondersteunt dit in hoge mate.

De eerste stappen voor een roadmap

Elke roadmap dient te passen binnen de purpose van de organisatie, alle betrokkenen dienen te begrijpen welk (deel) de roadmap bijdraagt aan de purpose en vooral welke klantwaarde toevoeging beoogd wordt.

Hoewel eerder in het artikel heel veel zaken zijn genoemd om mee te nemen bij het opstellen van een Agile Roadmap, heb je om het heel simplistisch te stellen slechts 3 zaken te beantwoorden:

  1. De strategische thema’s (wat is de richting voor middellange of lange termijn?)
  2. Doelstellingen, bijvoorbeeld via de OKR-methode in een kwartaal ritmiek
  3. Hypotheses, wat is haalbaar aan innovatie in het komend kwartaal?

Dit ziet er schematisch min of meer als volgt uit:

Agile roadmap - van nu naar visie, van visie naar OKR

Realiseer je terdege dat zodra dit plaatje invult en tot stand komt, deze al achterhaald kan zijn. Elk kwartaal review kan leiden tot een aanpassing van de next step(s).

Voorgaande is wel erg kort door de bocht, dus onderstaand een aantal stappen die je kunt ondernemen om een agile roadmap tot stand te brengen.

Eerst zie je echter een brainstorm mogelijkheid om een roadmap tot stand te brengen samen met je team.

Agile roadmap - brainstorm variant

In bovenstaande afbeelding zie je hoe bijvoorbeeld op een agile wijze een eerste format van een agile roadmap kan ontstaan.

De brainstorm variant past echter op meerdere plekken in onderstaand stappenplan. Je kunt deze vorm bijvoorbeeld gebruiken voor het bespreken van de visie, maar ook een eerste beeld te krijgen van de te ondernemen stappen, tot en met de opgeleverde ideeën in de backlog te plaatsen. E.e.a. is volledig afhankelijk van het beoogde resultaat van de brainstorm.

Stappenplan roadmap

Voorgaand is al heel veel gezegd wat er allemaal wel niet in een roadmap dient te worden meegenomen, maar wat zit er minimaal in? Een Visie, tijdslijn, scope, objectives en product areas, resultaten en facts.

Dat is interessant, maar een stappenplan maakt het wat makkelijker:

  1. Je begint een roadmap met de ontwikkeling van een visie en purpose, je strategie en de strategische thema’s.
  2. Door het bepalen van de huidige en toekomstige klantbehoeften, stel daarbij de prioriteiten op.
  3. Bepaal de strategische thema’s. Hoe past dit binnen de portfolio van de organisatie?
  4. Welke initiatieven dien je te ontplooien, waarom eigenlijk? Heb je al een waarde calculatie gemaakt?
  5. Welke risico’s of belemmeringen zie je op voorhand, welke maatregelen kan je nemen?
  6. Kies uit de enorme hoeveelheid roadmap sjablonen een passende voor jouw situatie of maak er zelf een.
  7. Vul de roadmap in, idealiter doe je dit als Product Owner niet alleen. Het advies is om anderen aan te sluiten voor andere inzichten of zienswijze, voor adviezen, delen van ervaringen, delen van kennis om te leren. Zie de brainstorm variant afbeelding. In veel gevallen is de Product Owner verantwoordelijk, maar dat betekent niet dat deze het helemaal alleen moet doen. De PO-er beslist uiteindelijk wel.
  8. Deel de roadmap, bespreek deze en plaats deze op een centrale plaats. Daardoor kunnen alle betrokken terugvallen op de roadmap en zijn wijzigingen direct voor iedereen zichtbaar. De meeste digitale tools die voor dit soort zaken worden gebouwd, zullen alle deelnemers in een ontwikkelteam automatisch op de hoogte brengen en hen laten weten dat de roadmap is veranderd.
  9. Het tot stand laten komen van een functioneel pad van User Stories, Epics, features en taken. Gebaseerd op de juiste prioriteiten, scope en ontwikkelpad.

Dan heb je de eerste versie. Wat doe je dan? Je zorgt ervoor dat alle betrokkenen aangesloten blijven en samen werken. Dus ook Financiën, marketing, verkoop, testen etc. Maar vooral ook klanten blijven betrekken!

Resultaten meten!

Om de resultaten te meten gebruik je metrics, als je kiest voor de OKR-methode heb je de metrics al gekozen. Essentieel is dat je hier meet of er klantwaarde is toegevoegd. Een veel gemaakte fout is dat men hier aantallen meet: in opgeleverde functionaliteit of taken.

Lees voor het toepassen van metrics eens het artikel: metrics en user stories

Opstarten verbetercycle

Zowel de interne processen en activiteiten, maar focus je op het terugkoppelen van klantervaringen en ideeën van klanten. Alle feedback van klanten is input voor het leerproces voor de komende periode. Dit is een leerproces wat nooit eindigt.

Realiseer je terdege dat elk ontwikkeltraject een vorm van een PDCA-cycle dient te integreren. Ook bij een roadmap dient er voldoende sprake zijn van agile werken om het volledige potentieel van een roadmap te benutten.

Hoe ziet een roadmap eruit?

Onderstaand een aantal voorbeelden van een roadmap. Mijn advies is om een ook eenvoudige google zoekopdracht op ‘agile roadmaps’ te doen. Je kiest voor afbeeldingen en je zult wellicht verrast worden.

Kant-en-klaar roadmap

Van alle mogelijke voorbeelden via de google search is hieronder slechts 1 kant-en-klaar voorbeeld opgenomen:

Agile roadmap - powerpoint variant

Bovenstaande afbeelding is overigens volstrekt willekeurig gekozen, zonder er inhoudelijk naar te kijken. Slechts bedoeld ter inspiratie.

Doelgerichte roadmap

Wellicht is het toch interessant om een basisvariant te tonen. Onderstaand een voorbeeld van een doelgerichte roadmap.

Agile roadmap - doelgerichte methode

Deze doelgerichte roadmap variant is bij uitstek geschikt om mee op te starten. Het toont een eenvoudige benadering om direct duidelijk te maken wat er wordt beoogd per kwartaal.

In bovenstaande afbeelding zal elk vakje worden ingevuld, vanzelfsprekend start je links met de eerste doelen, features en metrics, daarna werk je naar rechts. De vakken zullen door voortschrijdend inzicht aangepast worden.

Het kan zijn dat jouw organisatie afspraken heeft over welke roadmap versie er gebruikt dient te worden. Want sommigen passen gewoonweg beter in een bepaalde context.

Bovenstaande basisvorm van een roadmap is echter zeker te overwegen waard.

Roadmap OKR-methode

Wellicht is het nog interessanter om eens na te denken over een een roadmap die gekoppeld is aan de OKR-methode. Deze ziet er dan bijvoorbeeld als volgt uit:

Agile roadmap - OKR-methode

Ook dit is slechts een voorbeeld, maar je begrijpt de strekking. Je verbindt met een dergelijke methode visie, strategie en operatie naadloos aan elkaar.

Welke fouten worden er regelmatig gemaakt?

Een roadmap is een kijk op de toekomst, met foute aannames! Dus ook in jouw roadmap zitten er fouten! Veelal ‘fouten’ door aannames hoe de toekomst zich zal ontwikkelen.

Hoe beter je voorbereiding, hoe beter de roadmap. Maar de toekomst te voorspellen blijft een aanname. Fouten in aannames horen er bij, maar er zijn ook een aantal strategische fouten die met regelmaat terugkeren.

Een overzicht van vijf regelmatig gemaakte fouten is daarom best handig:

  • Verkeerde focus, je kiest nutteloze functies voor de klant.
  • Beïnvloeding door stakeholders i.p.v. echt te luisteren naar de klant.
  • Vasthouden aan verouderde functies, Vaak waren deze ‘vroeger’ belangrijk voor de organisatie.
  • Focus op de concurrent i.p.v. klant. Jouw team hoeft echt niet te kopiëren.
  • Paniekvoetbal! Het gaat niet volgens plan! Dat gebeurt. Verander niet direct je visie, kijk welk onderdeel pijn doet. Ga dus terug naar de tekentafel en neem een overwogen vervolgstap.

Laten we heel duidelijk zijn over bovenstaande fouten, het kan elk team overkomen. Herken ze, ga in gesprek en kom met een alternatief scenario!

Samenvatting

Het is essentieel om een roadmap te maken en deze op continue basis te veranderen o.b.v. de laatste klantbehoeften. Raak niet in paniek als jouw plan niet overeenkomt met de werkelijkheid. Dat is een absolute zekerheid in een complexe omgeving.

Een roadmap maak je om heel veel redenen, maar de kern van een agile roadmap is dat het richting geeft aan alle betrokkenen. Een roadmap waarbij een verandering mogelijk is en dat dit zelfs wordt aangemoedigd. Nieuwe inzichten worden gewogen en als ze waardevol zijn voor de klant ingepast in de komende werkzaamheden. Volgens de richting van de visie.

Een fantastische roadmap, die de ultieme kracht van een agile roadmap bij uitstek toont is de roadmap van SpaceX. Een volledig andere benadering dan NASA in vorige eeuw. Een agile benadering.

SpaceX heeft een heldere inspirerende visie, het ontwikkelpad kenmerkt zich door voortdurend testen, met reeksen van explosieve mislukkingen en sensationele successen. Ontwikkelen waarbij fouten maken mag, vanuit de volle overtuiging dat leren het snelste gaat door het uit te proberen in de praktijk.

Door de roadmap weet iedereen wat de visie is. Tijdens het ontwikkelen voeren SpaceX teams stevige discussies. Volgens NASA medewerkers zelfs met ‘een te grote mond’. De volledige andere werkwijze resulteerde in het begin van de samenwerking tot een cultuurshock bij NASA. Inmiddels erkent iedereen het bijzondere resultaat van SpaceX tot dusver.

Tot slot

Met een agile roadmap geef je richting aan autonome teams die daardoor transparant met elkaar in gesprek zijn, realistische doelen en doelstellingen hanteren en bovenal hoe ze succes meten.

De OKR-methode sluit uitstekend aan bij een roadmap. In het artikel: Wat is de OKR-methode lees je hier meer over.  

Leave a Comment