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 Product Owners utilisent des feuilles de route pour définir les futures fonctionnalités du produit et le calendrier de livraison 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 écarte la planification à 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 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 à comprendre.

Une feuille de route produit est un plan d'action décrivant l'évolution d'un produit ou d'une solution au fil du temps. Les Product Owners utilisent des feuilles de route pour définir les futures fonctionnalités du produit et le calendrier de livraison 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. Plusieurs équipes Agile peuvent partager une feuille de route produit unique.

Pour élaborer une feuille de route, les Product Owners prennent en compte les trajectoires du marché, les propositions de valeur et les contraintes en termes d'ingénierie. Une fois ces facteurs raisonnablement appréhendés, ils sont formulé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. Les initiatives apparaissent en bleu, et les délais sont indiqués par les marqueurs en rouge.

Une fois que la feuille de route a été élaborée, elle doit être partagée avec l'ensemble de l'équipe produit. Ainsi, tous en comprennent la vision et l'orientation. Dans de nombreuses entreprises, les responsables produit 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 fastidieux (c'est peu de le dire) de tenir tout le monde au courant quand et si la feuille de route change.

Dans ce cas, comment le responsable produit peut-il, plus facilement, tenir l'équipe informée ? C'est simple.

La plupart des outils de collaboration conçus pour ce type de démarche avertiront automatiquement l'ensemble des participants à un projet en cas de modification de la feuille de route. (Si votre outil spécifique ne le fait pas, il est peut-être temps d'aller faire un peu de shopping.)

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 ?
• 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 répercuter le travail de votre équipe sur la feuille de route. Ainsi, vous disposerez du « contexte » dans son intégralité, comme je l'ai mentionné plus haut. Une façon éprouvée d'y parvenir consiste à diviser les initiatives en epics dans le backlog produit, puis à décomposer ceux-ci en exigences et user stories. En reliant tous ces éléments, les Product Owners et l'équipe de développement peuvent plus facilement prendre des décisions à court terme sans mettre en péril le travail ultérieur. Examinons un exemple concret et voyons comment cela se passe.

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. Elle 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. Sinon, découvrez-en plus sur les offres de feuille de route de Jira Software.