Travailler en agile ne signifie pas ne pas savoir où l’on va. Cela signifie être flexible quant au chemin que vous prenez. C’est à cela que la roadmap agile sert.

Résumé : La roadmap d’un produit est un plan d’action (dont le Product Manager est responsable) décrivant la façon dont un produit ou une solution évoluera dans le temps, jusqu’à ce que vous en trouviez le market fit. Les Product Owners utilisent la roadmap pour planifier les sprints de leurs équipes. Une roadmap fournit un contexte crucial pour le travail quotidien de l’équipe. Elle doit être réactive aux éventuels pivots que vous ferez lors de vos itérations.

L’idée que le développement agile rejette la planification à long terme est un mythe. Une roadmap est importante pour une équipe agile : elle fournit un contexte au travail quotidien des équipes.

Roadmap produit : comment la rédiger ?

1. Qu’est-ce qu’une roadmap de produit agile ?

La roadmap est un plan d’action sur la façon dont un produit ou une solution évoluera dans le temps. Les Product Owners utilisent la roadmap pour décrire les fonctionnalités futures du produit et le timing de leur implémentation. Une Roadmap fournit un contexte crucial pour le travail quotidien de l’équipe et doit être réactive aux pivots éventuels de votre entreprise. Plusieurs équipes agiles peuvent partager une seule feuille de route de produit.

2. Comment la concevoir ?

Pour élaborer une roadmap, le Product Manager s’interroge sur les fondamentaux. Il cherche comment atteindre le plus rapidement possible un market fit et scale up. Pour cela, il fait des hypothèses, en prenant en compte la vision stratégique, les retours marché, et les contraintes techniques. Ces facteurs forment l’ADN de la roadmap, sous forme d’initiatives et de calendriers. Je vous conseille de mettre en parallèle votre roadmap produit avec la roadmap des hypothèses.

3. Impliquez vos équipes

Une fois que le Product Manager a établi un brouillon de feuille de route, il la partage avec l’ensemble de l’équipe et sollicite les feedbacks, et fera les ajustements nécessaires (sans trahir le Principe Premier, chaque élément doit avoir une raison d’être fondamentale).

La plupart des outils de collaboration conçus pour ce genre de choses prévient les équipes de chaque évolution.

Lorsque vous ajoutez une initiative à la roadmap, posez-vous les questions suivantes :

  • Quelles sont les priorités relatives de chaque initiative par rapport à l’objectif stratégique et aux hypothèses à valider ?
  • Quand aurons-nous l’intention de travailler sur chaque initiative ?
    • Y a-t-il des deadlines dont l’équipe doit avoir conscience ?
    • Quelles sont les dépendances de l’initiative – internes ou avec d’autres équipes ?
  • Quelles sont les équipes qui travaillent sur chaque initiative ?
    • Les équipes actuelles ont-elles de la disponibilité dans leur calendrier et une capacité suffisante ?
    • Pouvons-nous garder les équipes agiles actuelles stables ?
      • Si non…
        • Comment réorganiser les équipes ?
        • Est-ce que nous tenons compte de la montée en compétence des nouvelles équipes dans le calendrier du projet ?

Et surtout : consultez vos équipes lorsque vous faites évoluer la roadmap.

4. De quoi est composée la roadmap ?

Votre équipe doit pouvoir rattacher son travail à la roadmap pour comprendre le « contexte », ils pourront également s’appuyer sur la roadmap des hypothèses.

Les feuilles de route sont avant tout composées d’un axe temporel. Il faut pouvoir placer chacun des éléments selon une succession logique, généralement guidée par le temps. Le choix de l’axe temporel dépend du contexte dans lequel le product manager travaille, il doit choisir l’axe temporel le plus pertinent. Note: l’axe temporel peut être flou, ou conceptuel tel « maintenant », « juste après », « à moyen terme » et « à plus long terme ».

Lorsque vous concevez la roadmap, gardez en tête que vous l’utiliserez lors des réunions de sprint planning.

Les éléments de base de la roadmap

Les roadmaps sont composées d’ « Epics » (une feature développée sur plusieurs sprints), de features, de correction de bugs, ou de points d’action de rétrospective. Les Epics et les features sont décrites de façon complète : vous expliquez le contexte, leur objectif, les illustrez par une user story, et donnez une « definition of done ». Ces éléments permettent aux développeur de comprendre l’intention derrière une demande. En reliant chaque élément de la roadmap à ses fondamentaux (voir Premier Principe), l’équipe de développement peut travailler indépendemment, sans compromettre le travail futur. Si votre outil permet de relier chaque élément de votre roadmap à votre roadmap des hypothèses (Asana le fait avec des tags) : encore mieux !

Une chose à garder en tête : la feuille de route est un outil flexible. Elle évoluera au fil du temps. Votre voie vers le market fit n’est pas toute tracée : vous allez devoir valider des hypothèses, faire des découvertes, et pivoter. Chaque validation d’hypothèse pourra potentiellement faire évoluter votre feuille de route, chaque pivot sera un autre changement important.

La réussite d’une feuille de route, c’est la capacité de prendre du recul et de faire des recherches avant de prendre une décision cruciale. Elle permet à l’équipe de faire évoluer les fonctionnalités au fur et à mesure qu’elle valide des hypothèses et avance vers le market fit ou le scale-up.

5. Les choses à éviter

  • Vos équipes ignorent complètement la roadmap – elles fonctionnent au jour le jour (et donc ne comprend pas les fondamentaux)
  • Vous la mettez à jour de façon abusive, sans Principe Premier : vous n’avez pas de vision sur les fondamentaux.
  • Les feature requests semblent venir de nulle part : vous vous laissez influencer par des gens qui n’ont pas de vision fondamentale du produit.
  • Votre équipe ne partage pas ses activités avec le reste de l’entreprise : vous fonctionnez en vase clos – des erreurs seront faites, et vous devrez les corriger. Votre produit trouvera son market fit moins facilement, s’il le trouve un jour.
  • Vous détaillez trop les exigences : vos équipes se noient et perdent leur vision fondamentale.
  • Vous ne spécifiez pas les exigences, vos demandes sont floues.
  • Des deadlines sont inadéquates par rapport à la bande passante de votre équipe. Elle se retrouve vite démotivée, a l’impression de ne jamais atteindre ses objectifs.

Conclusion

Pour lutter contre l’immobilisme, la démotivation et la myopie, la roadmap doit se concentrer sur les fondamentaux. De là seulement découlent les tactiques à court terme. Un excellent moyen de maintenir le cap est de revoir la roadmap tous les trimestres en la mettant en parallèle avec la roadmap des hypothèses, et de l’ajuster si nécessaire. Cette méthode fonctionne bien quelle que soit la taille de l’organisation. N’oubliez pas qu’une seule feuille de route peut concerner plusieurs équipes agiles ; inspectez, adaptez et communiquez en conséquence.

Pour aller plus loin : exemples de roadmap