Agile roadmaps: bouwen, delen, gebruiken, veranderen

Samenvatting: Een productroadmap is een actieplan dat bepaalt hoe een product of oplossing zich in de loop van de tijd ontwikkelt. Productteams gebruiken roadmaps om toekomstige productfunctionaliteit te beschrijven en aan te geven wanneer nieuwe functies worden uitgebracht. Wanneer een roadmap wordt gebruikt in het agile ontwikkelingsproces, biedt deze cruciale context voor de dagelijkse werkzaamheden van het team. De roadmap moet snel kunnen worden aangepast afhankelijk van verschuivingen in de concurrentie.

Het idee dat bij agile ontwikkeling langetermijnplanning geen rol speelt, is misschien wel de grootste mythe sinds het monster van Loch Ness. Een roadmap is net zo belangrijk voor agile teams als voor watervalteams, omdat deze context biedt rond de dagelijkse werkzaamheden van het team en zich snel aanpast aan verschuivingen in de concurrentie. Maar in tegenstelling tot het Schotse watermonster is een goed samengestelde agile roadmap makkelijk te vinden en te begrijpen.

Een productroadmap is een actieplan voor hoe een product of oplossing zich in de loop van de tijd ontwikkelt. Productteams gebruiken roadmaps om toekomstige productfunctionaliteit te beschrijven en aan te geven wanneer nieuwe functies worden uitgebracht. Wanneer een roadmap wordt gebruikt in het agile ontwikkelingsproces, biedt deze cruciale context voor de dagelijkse werkzaamheden van het team. De roadmap moet snel kunnen worden aangepast afhankelijk van verschuivingen in de concurrentie. Meerdere agile teams kunnen een roadmap voor één product delen, maar elk team kan ook een eigen productroadmap hebben.

Om een roadmap te maken, houden productteams rekening met markttrajecten, bedrijfsdoelstellingen, feedback en inzichten van klanten en technische beperkingen. Zodra deze factoren redelijk goed in kaart zijn gebracht, worden ze in een roadmap uitgedrukt als initiatieven en tijdlijnen. Hieronder zie je een heel eenvoudige roadmap voor een productteam. Over het algemeen is het voor productroadmaps het beste om langere tijdsperioden te gebruiken, zoals maanden of kwartalen, in plaats van je vast te leggen op specifieke datums. Om ervoor te zorgen dat de gesprekken over prioriteiten gericht blijven op doelen en strategie in plaats van tijdlijnen, kun je zelfs proberen initiatieven in kaart te brengen op Nu, Volgende en Later.

Zodra een roadmap is gemaakt moet deze worden gedeeld met het hele productteam, zodat iedereen de visie en richting begrijpt. In veel organisaties maken producteigenaren hun roadmaps in PowerPoint en spreadsheets en e-mailen ze vervolgens de slides en spreadsheets naar het team. Hoewel dit waarschijnlijk met de beste intenties gebeurt, heeft deze aanpak veel nadelen. Elk teamlid heeft namelijk een eigen exemplaar van de roadmap. Iedereen op de hoogte houden van wijzigingen in de roadmap is dan nogal omslachtig (op zijn zachtst gezegd).

Dus hoe kunnen productteams de organisatie beter op de hoogte houden? Dat is heel simpel.

De meeste samenwerkingstools die hiervoor zijn gebouwd, houden alle deelnemers van een project automatisch op de hoogte en sturen een melding wanneer de roadmap wordt gewijzigd.

Houd bij het toevoegen van een initiatief aan de roadmap rekening met de volgende vragen:

Voordat we het gaan hebben over oplossingen voor dynamische voorspelling, bespreken we de stappen die nodig zijn om een agile plan voor de lange termijn te bouwen. We doen dit aan de hand van de metafoor van het bouwen van een huis:

• Wat zijn de relatieve prioriteiten van elk initiatief?
  • Welke impact zal elk initiatief hebben op de doelstellingen van het product en het bedrijf?
  • Hoeveel moeite is er nodig voor elk initiatief?
  • Zijn er genoeg inzichten en gegevens om het nastreven van een initiatief te ondersteunen?
• Wanneer gaan we volgens planning aan elk initiatief werken?
  • Zijn er bepaalde datums die het team moet halen?
  • Welke afhankelijkheden heeft het programma, intern of van andere teams?
• Welke teams werken aan elk initiatief?
  • Hebben de huidige teams ruimte in hun planning en voldoende capaciteit?
  • Kunnen we de huidige agile teams stabiel houden?
    • Zo niet ...
      • Hoe worden teams gereorganiseerd?
        • Wordt er rekening gehouden met het opzetten van nieuwe teams in de tijdlijn van het project?

Het is belangrijk om het geleverde werk van je team terug te koppelen aan de productroadmap, zodat inderdaad de hierboven genoemde context wordt gecreëerd. Een beproefde manier om dit te doen is door de productideeën die je prioriteit hebt gegeven op je productmap in kaart te brengen en die ideeën vervolgens op te splitsen in epics, vereisten en userstory's in je leveringsroadmap. In veel gevallen heeft elk idee een bijbehorende epic die moet worden opgesplitst in kleinere taken die moeten worden voltooid. Door ideeën op de productroadmap te koppelen aan epics in je leveringsroadmap, hebben engineers context achter geprioriteerde initiatieven, zoals feedback van gebruikers en onderzoek, binnen handbereik. Bovendien maakt dit het makkelijker voor product- en ontwikkelingsteams om samen beslissingen op korte termijn te nemen, die toekomstige werkzaamheden niet in gevaar brengen.

Stel dat we op onze website een uitgebreide gebruikersprofielfunctie uitrollen. Als we vervolgens ontdekken dat onze klanten de functie niet of nauwelijks gebruiken, moeten we er dan in blijven investeren? Misschien wel, maar misschien ook niet. We moeten begrijpen waarom de functie niet wordt gebruikt voordat we deze beslissing nemen. Dus in plaats van stug door te gaan, is het misschien beter om een aantal A/B-tests uit te voeren in de hoop enig inzicht te krijgen in het lage gebruikspercentage. Dit kan ons in een richting wijzen die we nooit of pas na lange tijd zouden hebben ontdekt als we gewoon waren doorgegaan met het toevoegen van meer toeters en bellen.

De mogelijkheid een stap terug te doen en onderzoek te doen voordat je een cruciale beslissing neemt, is de essentie van een agile roadmap. En idealiter is het ontdekkingsproces van het verzamelen van inzichten en gegevens de eerste stap die je neemt, voordat je besluit om een beslissing uit te voeren. Het geeft het team de mogelijkheid om functies te ontwikkelen naarmate ze meer te weten komen over een product en de markt.

Watervalprojecten vereisen een enorme investering vooraf. Als gevolg hiervan raken teamleden emotioneel gehecht aan de roadmap en stellen ze alles in het werk om de juiste beslissing te nemen, aangezien het te pijnlijk is om het werk dat ze hebben gedaan verloren te zien gaan.

Bij agile ontwikkeling daarentegen kan er sprake zijn van drie verschillende risico's:

• Het team kan het vertrouwen verliezen in het vermogen van het leiderschap om strategische beslissingen te nemen als de roadmap te vaak wordt bijgewerkt.
• Het product kan te laat op de markt komen en de inhaalvraag mislopen als de roadmap niet regelmatig genoeg wordt bijgewerkt.
• Inspanningen op de lange termijn kunnen 'te groot en te moeilijk' lijken voor kortere iteraties. Het team gaat overcompenseren door het werk op te splitsen in zeer kleine taken en richt zich uiteindelijk te veel op kortetermijnresultaten.

Om 'thrashing', verouderde informatie en kortzichtigheid te bestrijden, moet de roadmap evenredig veel aandacht besteden aan kortetermijntactieken en strategische langetermijndoelen. Een prima manier om dit te doen is om roadmaps elk kwartaal te evalueren, indien nodig aan te passen en opnieuw te delen. Dit werkt goed in organisaties van elke omvang, maar onthoud wel: één roadmap kan meerdere agile teams omvatten, dus let daar op als je gaat inspecteren, aanpassen en communiceren.

Lees verder in The Agile Coach om meer te weten te komen over speciale overwegingen voor grotere teams die agile portfolio's beheren met roadmaps in verschillende teams. Je kunt ook gratis proberen je eigen roadmap samen te stellen in Jira Product Discovery, speciaal gemaakt voor productteams.