Feuilles de route agiles : développer, partager, utiliser, évoluer

Résumé : une feuille de route produit est un plan d'action décrivant la façon dont un produit ou une solution évoluera au fil du temps. Les équipes produit utilisent des feuilles de route pour définir les futures fonctionnalités du produit et le calendrier de publication des nouvelles fonctionnalités. Lorsqu'elle est utilisée dans le développement Agile, une feuille de route fournit un contexte crucial pour le travail quotidien de l'équipe et doit pouvoir s'adapter aux changements dans le paysage concurrentiel.

L'idée que le développement Agile ne permet pas des planifications à long terme pourrait bien être le plus gros mythe depuis le Monstre du Loch Ness. La feuille de route est, en tous points, aussi importante pour une équipe Agile que pour une équipe en cascade. En effet, elle fournit le contexte du travail quotidien de l'équipe, une vision à long terme et s'adapte aux évolutions du paysage concurrentiel. Cependant, à la différence du célèbre monstre écossais, une feuille de route Agile est facile à trouver et facile à comprendre.

Une feuille de route produit est un plan d'action décrivant l'évolution d'un produit ou d'une solution dans le temps. Les équipes produit utilisent des feuilles de route pour définir les futures fonctionnalités du produit et le calendrier de livraison de ces nouvelles fonctionnalités. Lorsqu'elle est utilisée dans le cadre du développement Agile, une feuille de route fournit un contexte crucial pour le travail quotidien de l'équipe ainsi qu'une vision d'avenir, et doit pouvoir s'adapter aux changements dans le paysage concurrentiel. Plusieurs équipes Agile peuvent partager la même feuille de route produit, ou chaque équipe peut avoir sa propre feuille de route produit.

Pour établir une feuille de route, les équipes produit prennent en compte les évolutions du marché, les objectifs de l'entreprise, les commentaires et les idées des clients, ainsi que des contraintes techniques. Une fois ces facteurs raisonnablement appréhendés, ils sont consignés dans une feuille de route sous forme d'initiatives et de délais. Vous trouverez ci-dessous une feuille de route très simple pour une équipe produit. D'une manière générale, il vaut mieux que les feuilles de route des produits s'en tiennent à des périodes plus longues, comme des mois ou des trimestres, plutôt que de mentionner des dates précises. Pour que les conversations sur la priorisation soient centrées sur les objectifs et la stratégie, plutôt que sur la chronologie, vous pouvez même essayer de définir « Now » (maintenant), « Next » (après) ou « Later » (plus tard) comme délai correspondant aux initiatives.

Une fois que la feuille de route a été élaborée, elle doit être partagée avec l'ensemble de l'équipe produit, la direction et les équipes de livraison. Ainsi, tous en comprennent la vision et l'orientation. Dans de nombreuses entreprises, les Product Owners créent leurs feuilles de route dans PowerPoint ou un tableur, puis envoient, par e-mail, les diaporamas et les feuilles de calcul à l'équipe. Quoique bien intentionnée, cette stratégie est biaisée dès le départ. Chaque membre de l'équipe disposant de sa propre copie de la feuille de route, il peut être chronophage et fastidieux (c'est peu de le dire) de tenir tout le monde au courant si la feuille de route change.

Alors, comment les équipes produit peuvent-elles mieux informer l'organisation ? C'est simple.

La plupart des outils de collaboration avertiront automatiquement l'ensemble des participants à un projet en cas de modification de la feuille de route.

Lorsque vous ajoutez une initiative à la feuille de route, posez-vous les questions suivantes :

Avant de parler de solutions de prévision dynamique, parlons des étapes pour développer un plan Agile à long terme en utilisant la métaphore de la construction d'une maison :

• Quelles sont les priorités relatives de chaque initiative ?
  • Quel impact aura chaque initiative sur les objectifs du produit et de l'entreprise ?
  • Quel effort faut-il déployer pour chaque initiative ?
  • Y a-t-il suffisamment d'informations et de données pour soutenir une initiative ?
• Quand avons-nous l'intention de travailler sur chaque initiative ?
  • L'équipe a-t-elle certains délais à respecter ?
  • Quelles sont les dépendances du programme, internes ou avec d'autres équipes ?
• Quelles équipes travaillent sur chaque initiative ?
  • Les équipes actuelles ont-elles les capacités suffisantes et de la disponibilité dans leur calendrier ?
  • Pouvons-nous conserver les équipes agiles actuelles ?
    • Dans la négative...
      • Comment les équipes seront-elles réorganisées ?
        • Le déploiement des nouvelles équipes est-il pris en compte dans le calendrier du projet ?

Il est important de faire état du travail de votre équipe sur la feuille de route. Ainsi, vous disposerez du « contexte » dans son intégralité, comme mentionné plus haut. Une méthode éprouvée consiste à répertorier les idées de produits priorisées sur votre carte des produits, puis à les répartir en catégories epics, exigences et témoignages d'utilisateurs sur votre feuille de route de livraison. Souvent, chaque initiative est associée à une epic qui doit être décomposée en petites tâches pour être terminée. En reliant les idées de la feuille de route du produit aux epics de la feuille de route de livraison, les ingénieurs peuvent facilement accéder au contexte des initiatives prioritaires telles que les commentaires des utilisateurs et les recherches. De plus, cela permet aux équipes produit et de développement de prendre ensemble des décisions à court terme sans mettre en péril le travail ultérieur.

Imaginons, par exemple, que nous voulons déployer, sur notre site Web, une fonctionnalité étendue pour les profils des utilisateurs. Si nous constatons que nos clients n'adoptent pas cette fonctionnalité, devons-nous continuer à investir de ce côté ? Peut-être bien que oui, peut-être bien que non. Avant de prendre cette décision, nous devons comprendre les raisons de ce faible engagement. Par conséquent, plutôt que de poursuivre dans cette voie, nous pourrions décider de mettre en œuvre des tests A/B dans l'espoir de mieux comprendre ce faible taux d'engagement. Cela peut très bien nous orienter dans une direction qui aurait été beaucoup plus difficile (voire impossible) si nous nous étions contentés de foncer en ajoutant toujours plus de fioritures.

Cette possibilité de prendre du recul et d'effectuer des recherches avant de prendre une décision cruciale est l'essence même de la feuille de route Agile. Et idéalement, le processus de découverte qui consiste à recueillir des informations et des données est la première étape réalisée avant de décider de mettre en œuvre une décision. Cela permet à l'équipe d'ajuster les fonctionnalités au fur et à mesure qu'elle apprend à connaître le produit et le marché.

Les projets en cascade nécessitent des investissements considérables en amont. En conséquence, les membres de l'équipe développent un lien émotionnel avec la feuille de route. Ils renoncent à prendre la bonne décision parce qu'il est trop douloureux de défaire le travail qu'ils ont accompli. Un péché humain, s'il en est.

Pour sa part, le développement agile est confronté à trois risques différents :

• Si la feuille de route est modifiée trop souvent, l'équipe risque de perdre confiance dans la capacité des dirigeants à prendre des décisions stratégiques.
• Si la feuille de route n'est pas assez souvent actualisée, le produit risque d'arriver trop tard sur le marché et de passer à côté de la demande latente.
• Les efforts à long terme peuvent sembler « trop importants et trop difficiles » pour les itérations plus courtes. L'équipe surcompense en divisant le travail en tâches granulaires très fines et finit par se concentrer trop lourdement sur les résultats à court terme.

Pour lutter contre les « gesticulations », l'obsolescence et la vision à trop court terme, la feuille de route doit se focaliser, de façon égale, sur les tactiques à court terme et les objectifs stratégiques à long terme. Le fait de réviser les feuilles de route chaque trimestre, de l'ajuster si nécessaire, et de la partager est un excellent moyen d'y parvenir. Cela fonctionne bien dans les entreprises, quelle que soit leur taille, mais n'oubliez pas : une seule feuille de route peut couvrir plusieurs équipes agiles. Vérifiez, adaptez et communiquez en conséquence.

Poursuivez votre lecture du « Coach Agile » pour découvrir certains aspects propres aux équipes plus grandes, qui gèrent des portefeuilles Agile grâce à des feuilles de route impliquant plusieurs équipes. Vous pouvez également essayer d'élaborer gratuitement votre propre feuille dans Jira Product Discovery, fonctionnalité conçue pour les équipes produit.