La roadmap produit est un sujet récurrent dans les organisations IT, agiles ou non. Outil de communication avant tout, la Roadmap est aussi du point de vue de l’Agilité, l’un des niveaux de planification, plutôt « high level » à mi-chemin entre la Vision du Produit (structurante et long terme) et par exemple ce qui est produit dans un Sprint…
Les paradoxes de la Roadmap
Elle est attendue…
- Héritée, marquée par un doux parfum « Command & Control », elle est fortement demandée par le Top Management, parfois pour des raisons plus ou moins obscures
- Côté Equipe, la roadmap est souvent réclamée, pour savoir dans la lignée de la Vision Produit, ce qui va arriver dans les mois qui viennent (sujets importants, dates clés…)
- Côté Produit, elle est attendue pour bénéficier et donner de la visibilité sur ce qui est fait et ce qui arrive mais aussi pour fixer des priorités en termes de périmètre et de livraisons
- Dans les contextes Multi-Equipes, à l’echelle ou gros projets, la Roadmap est attendue globalement à des fins de synchronisation, prise en compte des dépendances et ajustement des effectifs
Attendue donc, et POURTANT rarement faite, rarement BIEN faite, peu satisfaisante, peu partagée, rarement à jour!
Juste une autre Roadmap… la Roadmap Agile
La roadmap Agile est PHYSIQUE, accessible, visible, flexible (en partie) et revue régulièrement. La spécificité du format nécessite une mise en mouvement, et permet de voir en temps réel (par Equipes ou Non):
- Ce qui vient d’être livré (Just Shipped)
- Ce qui est En cours (CURRENT)
- Ce qui arrive
Elle se fonde aussi sur un découpage et un traitement différentié de l’axe temporel (Présent – Court terme – Moyen Terme) impactant à la fois degré de certitude et flexibilité.
Le Long terme étant porté par la Vision, le travail sur la Roadmap ne peut peut se faire indépendamment de la Vision Produit. Plus exactement, sans ses fondations et une Vision produit stable, l’activité et la communication autour de la Roadmap ne pourront être que chaotiques.
J’ai utilisé ce format dans plusieurs organisations avec un succès variable; voici quelques clés pour que cela marche:
- Un bon niveau de granularité pour les items affichés (notamment sur la partie « Current » et « Planned »).
- Un climat de confiance dans l’organisation avec une roadmap comme un support de dialogue entre le Top Management et les Product Owners…. J’imagine que « Collaboration avec le Client plutôt que contractualisation des Echanges » … « Acceptaion du Changement plutôt que conformité aux Plans » vous disent quelque chose 🙂
- Visibilité (au bon endroit) et lisibilité (le bon format)
- A jour (outil des PO’s)
La Roadmap Agile affichée au sein du radiateur d’informations Produit doit être vue comme un lieu d’echange et de partage Management / Product Owners ce qui suppose que le Top Management se déplace et s’approprie son contenu, et que des points de rencontre réguliers soient organisés.
Directement connectés aux Backlogs de Produit, une Roadmap Produit utile et utilisable suppose que les Backlogs de Produit soient « propres » et bien maintenus.
Pour l’initier, rien de tel que de commencer par des ateliers StoryMap ou Prune The Product Tree
Enfin, n’oubliez pas…
« Une seule chose est certaine, ce qui se passe Maintenant » E. TOLLE ; ou l’éloge du Moment Présent 🙂
Merci pour l’article !
Il est important que la Roadmap agile ne soit pas uniquement centrée sur la livraison de fonctionnalités mais également sur la valeur apportée au produit (en mode Lean Startup)
Quelques pistes :
– Etre centré sur l’objectif du développement. (par exemple en utilisant une couleur différente pour chaque catégorie d’objectif)
– Etre centré sur la mesure. Une fois le développement livré, est-ce qu’il a atteint les objectifs attendus ? Dans le cas contraire, qu’est-ce que l’on a appris ? Cet apprentissage doit nourrir les futures développements de la roadmap.
Merci pour cet article !
Avec mon équipe on cherche à construire une roadmap mais on a un peu de difficultés car le backlog est énorme, les informations jalons nombreuses. J’ai peur aussi que si la roadmap est physique, ce soit impossible à maintenir avec les évolutions quotidiennes du backlog.
Ma question est vraiment pratico pratique : qu’est-ce que vous utilisez concrètement pour construire la roadmap ?
Hello,
Difficile de vous répondre hors contexte. Dans tous les cas, l’idée est de revenir au pourquoi de la Roadmap, à qui elle est destinée et les problématiques qu’elle est censée adresser…
Vous parlez d’évolution quotidienne du Backlog… Produit j’imagine? Quotidienne?
Dans tous les cas, le niveau de granularité est différent, et en principe moins sujette à changer trop souvent. Une roadmap qui change toutes les semaines est plutôt déstabilisant pour les Equipes: j’en ai fais l’expérience 🙂
Un grand mur est nécessaire, accompagné d’une version électronique, PPT par exemple…
Merci de votre commentaire Géraldine