De mooie fictie
Iemand besteedt drie weken aan het bouwen van een roadmap. Met kleurcodes. Afhankelijkheden in kaart gebracht. Doorlooptijden op elkaar afgestemd. Elk team heeft zijn eigen baan. De leiding geeft akkoord. Hij wordt gepresenteerd op de personeelsbijeenkomst. Iedereen knikt.
Dan verschuift er één prioriteit. Eén.
En die roadmap is fictie. Iedereen in de zaal weet het. Niemand zegt het hardop, want opnieuw bouwen betekent weer drie weken onderhandelen tussen teams, spreadsheetacrobatiek en afstemmingsoverleggen die eindigen met "laten we dit buiten de vergadering oppakken".
Dus blijft de roadmap bevroren. Teams werken er stilletjes omheen. De leiding neemt beslissingen op basis van een plan dat de werkelijkheid niet meer weergeeft. En de kloof tussen wat de organisatie denkt dat er gebeurt en wat er werkelijk gebeurt, wordt elke week groter.
Als uw roadmap niet één prioriteitswijziging overleeft zonder handmatig opnieuw te worden opgebouwd, is het geen plan. Het is een momentopname van een moment dat al voorbij is.
Zo herkent u een verlanglijst
De symptomen zijn makkelijk te zien als u weet waarop u moet letten.
Features hebben een opleverdatum, maar niemand kan uitleggen hoe die datums zijn berekend. Ze zijn in een vergadering gekozen, niet afgeleid van capaciteit, afhankelijkheden en de snelheid van het team. Verander één gegeven en de datums zouden moeten verschuiven. Doen ze dat niet, dan waren ze nooit echt.
Iedereen weet dat feature B afhangt van feature A, maar de roadmap legt die relatie niet vast. Loopt feature A uit, dan blijft de planning van feature B onaangeroerd tot iemand het conflict handmatig ontdekt, meestal drie weken later tijdens een stand-up.
Is uw roadmap een PowerPoint of een Confluence-pagina die iemand vlak voor de kwartaalreview met de hand bijwerkt, dan is het een communicatiemiddel, geen planningsinstrument. Vanaf het moment van exporteren begint hij te verouderen.
De leiding stopt met vragen als "wat gebeurt er als we twee engineers aan het platformteam toevoegen?" of "waar doet een bezuiniging het minste pijn?", omdat het antwoord een week rekenwerk kost. Strategische nieuwsgierigheid sterft als verkennen te duur is.
Komt een van deze punten u bekend voor, dan stuurt uw roadmap geen beslissingen aan. Dan is het gewoon decoratie.
Waarom roadmaps bevriezen
De oorzaak is geen luiheid of gebrek aan discipline. Ze is structureel. De meeste roadmaps zijn gebouwd op tools die daar nooit voor bedoeld waren.
Spreadsheets kunnen een plan op één moment weergeven, maar kunnen niet opnieuw rekenen als de gegevens veranderen. Jira volgt de uitvoering uitstekend, maar begrijpt geen strategische volgorde. Slidedecks brengen een bedoeling over, maar kunnen geen gevolgen berekenen. En roadmaptools? De meeste draaien om mooie tijdlijnweergaven en sjablonen, maar worden met de hand bijgewerkt. Hetzelfde probleem.
Wat er dan gebeurt, is dat iemand de menselijke rekenmachine wordt. Die persoon zit tussen strategie en uitvoering in en vertaalt prioriteitswijzigingen met de hand naar een nieuwe planning, zet features in een nieuwe volgorde, controleert de capaciteit en jaagt teams na voor herziene schattingen. Meestal is dat een programmamanager of iemand van product operations, die 80% van de tijd kwijt is aan het bijhouden van de roadmap en maar 20% aan er echt over nadenken.
Die verhouding is precies omgekeerd.
Het bijhouden zou geautomatiseerd moeten zijn. Het nadenken zou het werk moeten zijn.
Hoe een levende roadmap er echt uitziet
Een roadmap die werkt, is geen mooiere versie van dezelfde spreadsheet. Hij werkt fundamenteel anders.
De planning van elke feature volgt uit de prioriteit, de afhankelijkheden en de capaciteit van de toegewezen teams. Verander een van die gegevens en de planning wordt opnieuw berekend. Niemand kiest een datum in een vergadering. Het systeem vertelt u wanneer iets realistisch klaar kan zijn, gegeven al het andere op het bord.
Loopt feature A uit, dan schuift alles wat ervan afhangt mee. Niet na een vergadering. Niet nadat iemand het opmerkt. Meteen. De roadmap toont de werkelijke stand van zaken, niet de stand waarop u hoopte toen u de spreadsheet voor het laatst bijwerkte.
Werken teams hun schattingen bij in hun dagelijkse tool (meestal Jira), dan ziet u dat terug in de roadmap. Sprints verstrijken, werkelijke cijfers vervangen schattingen en het plan past zich aan. Er is geen handmatige synchronisatiestap, geen wekelijkse export, geen "even de slides bijwerken voor de vergadering".
De leiding kan "wat als" vragen en binnen enkele seconden een antwoord krijgen. Wat als we dit team naar een ander initiatief verplaatsen? Wat als we de scope van deze feature verkleinen? Wat als we in Q3 twee extra engineers aannemen? De roadmap rekent opnieuw, afwegingen worden zichtbaar en beslissingen worden genomen op basis van echte informatie in plaats van onderbuikgevoel.
Het verschil tussen een verlanglijst en een roadmap is eenvoudig. Een verlanglijst is een statische lijst met dingen die u wilt. Een roadmap is een dynamisch systeem dat u vertelt wat er mogelijk is met wat u hebt, en wat er verandert als de gegevens veranderen.
De echte test
Zo weet u snel of uw roadmap leeft of dood is. Stel uw organisatie één vraag: "Als we de prioriteit van dit initiatief nu aanpassen, hoe lang duurt het voordat de roadmap de gevolgen laat zien?"
Is het antwoord minuten, dan hebt u een roadmap. Is het antwoord dagen of weken, dan hebt u een verlanglijst met een tijdlijn erop getekend.
De meeste organisaties nemen genoegen met het tweede antwoord, omdat ze het eerste nooit hebben meegemaakt. Ze gaan ervan uit dat het bijhouden van de roadmap nu eenmaal bij plannen hoort. Dat hoeft niet.
Het plan zou zichzelf moeten bijhouden. De mensen zouden het denkwerk moeten doen.
Zie uw roadmap opnieuw rekenen
Taskstreamer berekent doorlooptijden automatisch op basis van prioriteit, afhankelijkheden en capaciteit. Verander een gegeven en zie hoe de hele roadmap meebeweegt.
Probeer 30 dagen gratis