Agile roadmaps: bouwen, delen, gebruiken, veranderen

Kiezen voor agile betekent niet dat je niet weet waar je naartoe gaat. Het betekent flexibel zijn over de weg die je volgt om er te komen.

Dan Radigan Door Dan Radigan
Onderwerpen zoeken

Samenvatting: Een roadmap is een actieplan dat bepaalt hoe een product of oplossing in de loop van de tijd zal evolueren. Producteigenaren 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 en moet snel kunnen reageren op verschuivingen in het competitieve landschap.

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 een agile team als voor een watervalteam, omdat het context biedt rond het dagelijkse werk van het team en reageert op verschuivingen in het competitieve landschap. Maar in tegenstelling tot een bepaald Schots watermonster is een goed samengestelde agile roadmap gemakkelijk te vinden en te begrijpen.

Wat is een agile productroadmap?

Een productroadmap is een actieplan voor hoe een product of oplossing in de loop van de tijd zal evolueren. Producteigenaren 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 en moet snel kunnen reageren op verschuivingen in het competitieve landschap. Meerdere agile teams kunnen samen één productroadmap delen.

De roadmap samenstellen

Bij het bouwen van een roadmap houden producteigenaren rekening met markttrajecten, waardeproposities en technische beperkingen. Op het moment dat 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. De initiatieven zijn blauw en tijdlijnen worden aangegeven door rode mijlpaalmarkeringen.

Agile roadmap | Atlassian agile coach

De roadmap delen

Zodra een roadmap is gebouwd, 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, kent deze strategie duidelijk zwakke punten. Elk teamlid heeft namelijk een eigen exemplaar van de roadmap en iedereen op de hoogte houden van wijzigingen in de roadmap is nogal omslachtig (op zijn zachtst gezegd).

Dus hoe kan de producteigenaar het team beter op de hoogte houden? Heel eenvoudig:

De meeste samenwerkingstools die hiervoor zijn gebouwd, zullen automatisch alle deelnemers van een project op de hoogte brengen en hen laten weten dat de roadmap is gewijzigd. (Als jouw tool dat niet doet, is het misschien tijd om een andere tool te kopen.)

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?
  • 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?

De roadmap gebruiken

Het is belangrijk om het werk van je team terug te koppelen aan de roadmap, zodat inderdaad de context wordt gecreëerd waar ik het eerder al over had. Een beproefde manier om dit te doen, is door initiatieven op te splitsen in epics in de productbacklog en deze vervolgens verder op te splitsen in vereisten en userstory's. Door alles zo met elkaar te verbinden, wordt het voor producteigenaren en het ontwikkelingsteam gemakkelijker om beslissingen op korte termijn te nemen die toekomstig werk niet in gevaar brengen. Laten we een voorbeeld bekijken om te zien hoe dit in zijn werk gaat.

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.

Het vermogen om een stap terug te doen en onderzoek te doen voordat we een cruciale beslissing nemen, is de essentie van een agile roadmap. Het geeft het team de mogelijkheid om functies te ontwikkelen naarmate ze meer leren over een product en de markt.

Antipatronen om op te letten
  • Planning voor de toekomst wordt volledig genegeerd en we reageren overhaast.
  • De 'rest van het bedrijf' is onwetend over wat het team van plan is.
  • De roadmap wordt continu bijgewerkt (of nooit bijgewerkt).
  • Gedetailleerde vereisten maken de roadmap onnodig log.

Ontwikkeling van de roadmap

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.

Blijf The Agile Coach lezen om meer te weten te komen over speciale overwegingen voor grotere teams die agile portfolio's beheren met roadmaps in verschillende teams. Of lees meer over het aanbod aan roadmaps van Jira Software.