Lors de mes formations Scrum ou coachings en entreprise, il n’est pas rare que les participants expriment leur souhait d’accéder à davantage de contenus Scrum de qualité en français. Cette série « Le meilleur de Scrum » répond à ce besoin en proposant des traductions d’une sélection d’articles de référence écrits par d’autres PSTs de chez Scrum.org.
Ce second article est une traduction d’un article original de Robbin Schuurman: Tips for Agile product roadmaps & product roadmap examples. Robbin est à la fois Professional Scrum Trainer chez Scrum.org, steward du programme PSPO-A et auteur de l’ouvrage : 50 nuances de non: Gestion efficace des parties prenantes à destination des Product Owners. Vous retrouverez une interview de Robbin Schuurman en fin d’article. Bonne lecture :)
Conseils pour les roadmaps produit agiles & exemples
En tant que Product Owner, vous êtes responsable du management du Product Backlog, des parties prenantes et des prévisions. Par conséquent, vous allez probablement utiliser différents outils et techniques pour suivre l’avancement, gérer les besoins et tenir les gens informés. Un des outils qui vous sera particulièrement utile est la roadmap produit, même si son utilisation peut se révéler difficile. Le concept de roadmap produit tient à un plan stratégique de haut niveau décrivant le développement probable du produit pour la prochaine période de temps. Une roadmap se doit de soutenir la raison d’être et la vision produit, elle aide le Product Owner à rester aligné avec les parties prenantes. Une roadmap facilite aussi la coordination de différents produits et renforce la Transparence nécessaire à la gestion des besoins client. Dans de nombreuses organisations, j’observe que les Product Owners se focalisent sur le développement de fonctionnalités, et par conséquent un grand nombre de roadmaps sont dominées par des fonctionnalités et des caractéristiques à livrer. L’inconvénient à trop se focaliser sur les fonctionnalités est qu’il y aura toujours de nouvelles fonctionnalités à valeur ajouté, au détriment du focus sur la vision et des objectifs. En se focalisant trop sur les fonctionnalités, les roadmaps se changent en un Product Backlog surchargé en lieu et place d’un plan stratégique de haut niveau pour le développement futur du produit.
Dans ma pratique quotidienne, j’ai pu observer différentes roadmaps produit à l’usage. Bien que ces trois différentes roadmaps aient toutes divers avantages et inconvénients, je les ai toutes vues apporter de la valeur aux Product Owners dans le quotidien. Personnellement, j’ai toujours employé une combinaison de ces trois types de roadmaps. J’utilise principalement le storymap en début de développement Produit, car je veux permettre aux parties prenantes d’avoir un aperçu des fonctionnalités du Produit.
La roadmap orientée objectifs ou GO (Goal Oriented)
Ce que j’apprécie particulièrement à propos des roadmaps produit orientées objectifs (ou GO) est qu’elles renforcent le focus sur les objectifs que vous souhaitez atteindre en tant que Product Owner, bien plus que sur le travail à faire (les fonctionnalités). Bien qu’une roadmap GO offre aussi la possibilité d’ajouter des fonctionnalités, j’aime débuter avec les objectifs finaux à l’esprit, et je crois que chaque Product Owner devrait en faire de même. Les roadmaps GO et le focus sur les objectifs rendent possible le pilotage par la valeur (pilotage par l’impact) à la place d’un pilotage par les livrables (pilotage par les extrants).
Sachant que vous êtes responsable de la vision produit, la stratégie et la roadmap en tant que Product Owner, je pense que les roadmaps GO constituent un atout précieux. Un autre aspect des roadmaps GO que j’apprécie est qu’elles vous aident à identifier les fonctionnalités les plus prometteuses pour l’atteinte de vos objectifs. Parce-que l’agilité, c’est aussi la « simplicité - c’est à dire l’art de minimiser la quantité de travail inutile » (principe Agile #10), j’aime l’idée de ne pas avoir suffisamment d’espace dans ce modèle, pour forcer à réfléchir aux trois plus importantes fonctionnalités d’une livraison. Ce que j’apprécie aussi, c’est que d’un coup d’oeil, vous disposez d’une vue d’ensemble des développements pour vos prochaines livraisons. Ce qui est très pratique pour le management des parties prenantes!
En fonction du contexte organisationnel, je laisse parfois de côté les sections "date" et "étiquetage des livraisons" de la roadmap GO. Je le fais car à de nombreuses reprises par le passé, des parties prenantes ayant pris connaissance des dates de la roadmap (qui étaient des prévisions de mon point de vue), en ont conclu qu’elles prendraient formellement livraison de la fonctionnalité à la date présentée dans la roadmap. Puisque nous travaillons dans des environnements complexes changeants et puisque les individus changent d’avis au fil du temps, ces prévisions n’étaient pas toujours exactes. Aussi, selon le contexte, j’utilise, ou pas, les sections "date" et "étiquettage des livraisons", afin de stimuler les interactions et parer à de mauvaises interprétations des éléments de la roadmap. Dans ces cas, je combine souvent la roadmap produit GO avec la roadmap Produit Now-Next-Later.
La roadmap produit « Now-Next-Later »
La roadmap produit Now-Next-Later est une représentation que j'aime beaucoup, car elle est compréhensible par tous. Les parties prenantes en assimilent le principe, car il est facile de saisir que vous travaillez en ce moment sur les éléments de la partie « Now », que la partie « Next » vient ensuite, et enfin que la partie « Later » interviendra plus tard dans le temps et doit encore être priorisée. L’aspect négatif de ce type de roadmap est de mon point de vue qu’elle se concentre davantage sur les fonctionnalités plutôt que les buts que vous visez en tant que Product Owner. De plus, ce modèle ne laisse que trop peu de place pour l’insertion de KPIs, versions ou dates. Sachant que les dates et délais sont des données importantes pour les parties prenantes (dans la plupart des situations dans lesquelles je me suis trouvé), c’est peut-être quelque chose que vous devriez prendre en compte dans l’utilisation de cette roadmap. D’autre part, c’est peut-être un avantage que la roadmap « Now-Next-Later » n’inclut pas de dates, car ça crée une opportunité d’interagir avec vos parties prenantes plutôt que de simplement communiquer les données de la roadmap. Comme évoqué précédemment, j’apprécie la combinaison des roadmaps GO et « Now-Next-Later » car il vous apporte un supplément de valeur à vous et à vos parties prenantes.
La storymap
La storymap est un type de roadmap sympa que j’utilise souvent au début de nouveaux projets ou produits. La storymap est une excellente façon de créer une vue d’ensemble de toutes les fonctionnalités que vous et vos parties prenantes pourraient être amenés à imaginer, et qui seront importantes pour votre produit. Bien que l’idée ne soit pas de créer une liste illimitée de caractéristiques et fonctionnalités à développer dans le futur, elle apporte un point de départ facilitant la génération d’idées créatives pour votre produit. Ce qui me plait le plus avec la storymap est qu’elle propose un aperçu de toutes les activités qui devront être couvertes par le système, et vous permet ainsi de créer des user stories à la fois petites et de valeur, à même d’être développées et livrées de manière incrémentale et itérative.
Un autre facette particulièrement appréciable de la storymap et qu’elle se constitue à partir des activités utilisateurs, elle apporte ainsi une perspective orientée utilisateur du produit. Je suis attaché à ce concept car il nous aide à réfléchir au produit du point de vue de l’utilisateur. Après tout, ne développons-nous pas nos produits pour nos utilisateurs et clients ?
L’inconvénient principal à la storymap que j’ai constaté en pratique est qu’elle promeut l’illusion que toutes les fonctionnalités du produit seront développées. Puisque nous sommes Agiles, notre objectif n’est pas de créer un plan complet ou partiel du produit. Aussi mon conseil est d’utiliser une storymap au démarrage de votre nouveau projet de développement produit, mais précisez clairement auprès des parties prenantes que vous ne développerez pas nécessairement tous les éléments de votre story map. Prenez soin de bien gérer ces attentes!
11 conseils pour vos Roadmaps Produit Agiles
J'espère que ces différents types de roadmap vous sont utiles, mais souvenez-vous : « L’agilité ne concerne pas les processus et les outils mais les individus et les interactions". Par conséquent, et merci à Roman Pichler pour son inspiration, je voudrais partager avec vous les 11 conseils suivants pour la création de roadmaps produit Agiles :
- Commencer par votre vision produit (conseil: utiliser la Roman's Product Vision board);
- Décrire et valider votre stratégie produit;
- Se concentrer sur les objectifs et les bénéfices, en créant une roadmap produit GO (ou l’une des autres présentées précédemment);
- Communiquer une histoire cohérente sur la croissance probable de votre produit et ne le sur-vendez pas;
- Rester simple! Résister à la tentation d'ajouter trop de détails à votre roadmap;
- Collaborer activement avec les parties prenantes pour garantir l'adhésion;
- Avoir le courage de dire non, et évitez ainsi une surcharge de fonctionnalités dans votre roadmap;
- Réfléchir à deux fois avant d’ajouter échéanciers, dates et jalons à votre roadmap;
- S’assurer que votre roadmap est mesurable, en ajoutant des objectifs mesurables et des KPIs;
- Créer un chiffrage approximatif pour chaque fonctionnalité (nombre de personnes et compétences requises) pour déterminer la viabilité d'une fonctionnalité;
- Analyser et adapter régulièrement votre roadmap produit.
Merci d'avoir lu, si vous avez des commentaires à partager, n'hésitez pas, et bonne chance dans la création de votre roadmap Produit!
Interview de Robbin Schuurman
Robbin, pourquoi as-tu ressenti le besoin d’écrire cet article ?
Tout d’abord, merci François pour avoir pris le temps de traduire cet article en français. C’est formidable de constater l’intérêt croissant pour le product ownership et le product management en France, mais aussi dans le monde. J’espère que cette traduction permettra à de nombreux product owners, product managers, et toute personne en charge de produits en France de s’inspirer de cet article.
La raison première à l’élaboration et à la publication de cet article traitant des roadmaps produit agiles, était que nous recevions de nombreuses questions à ce sujet lors de nos formations PSPO (Professional Scrum Product Owner). Les participants ont vraiment appréciés la façon dont nous avons répondu à leurs questions sur les roadmaps. Je m'astreins ainsi depuis un certain temps à noter les questions fréquemment posées par les Product Owners de nos classes. Afin qu’après la formation, je puisse être en mesure d’y répondre à travers un article de blog pour un public plus large. J'espère que cela aidera les communautés Scrum et du product management à progresser.
Depuis que l’article a été publié en 2017, j’ai reçu de nombreux retours et commentaires positifs. C’est formidable de constater l’intérêt croissant sur ce contenu.
As-tu remarqué une différence lors de tes formations avec les participants ayant lu cet article ?
Oui, complètement. C'est formidable de voir que les apprenants qui ont lu l'article sont déjà plus conscients des possibilités, limites et concepts liées des roadmaps produit. Maintenant que j’y réfléchis, je pense que je devrais probablement prendre le temps de réécrire mon article d'origine, car j'ai appris de nombreux formats, pratiques, et astuces roadmap depuis la publication initiale de 2017. Cependant, c'est aussi une bonne chose que nous puissions également ajouter de nouvelles connaissances, formats, astuces et concepts dans nos classes. En particulier dans la classe Professional Scrum Product Owner - Advanced (PSPO-A), la gestion des roadmaps est l'un des sujets que nous couvrons le plus en détail.
De plus, je constate que de plus en plus de personnes dans le monde nous contactent et nous suivent sur Medium (The Value Maximizers). Sur notre blog Medium, nous publions régulièrement des articles sur divers sujets et nous obtenons d'excellents retours de la part de product owners et product managers sur ces contenus
Quelle est ton activité privilégiée pour aider les professionnels à gérer au mieux les roadmaps produit agiles ?
De mon point de vue de formateur / consultant, c'est certainement pour aider les professionnels du produit à clarifier la vue d'ensemble de leur produit. C’est à dire s’assurer que vision, stratégie, objectifs, roadmap et tactiques du produit sont alignés. Non seulement au sein du produit, mais également avec la vision et la stratégie de l'entreprise. Nous avons accompagné de nombreuses organisations dans leur transformation Agile, Numérique ou Produit, et l'écart ou le désalignement entre la vision, la stratégie, les tactiques et encore les opérations de l'entreprise ne cesse de me surprendre. Ce que j'aime faire, c'est créer une stratégie compréhensible, alignée du PDG à toute personne de l’entreprise.
Mon activité préférée en lien avec les roadmaps est le management des parties prenantes. Les roadmaps sont souvent interprétées à tort comme des «plans fixes» ou des «plans contractuels. A mon avis, une roadmap est «un plan à ne pas respecter». Ceci est souvent mal compris dans la pratique et j’ai beaucoup de plaisir à aider, cadrer, influencer les parties prenantes dans l’adoption de ce principe. Cela peut prendre un certain temps, mais c'est formidable de faire changer d'avis les gens à ce sujet.
Vous souhaiteriez obtenir une traduction en français et conforme au Scrum Guide d’un article du blog Scrum.org ? Choisissez lesquels seront les prochains à être traduits en posant leurs lien ci-dessous :-)