Francois Fort

Lors de mes formations Scrum ou coachings en entreprise, il n’est pas rare que les participants expriment leur souhait d’accéder à davantage du contenu 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 :-)

Kate Hobler challenged Rich Visotcky and I to share our thoughts on the article “Commitment is not free overtime" based on the Quora question below. Rich already responded in Kate’s article and now it’s my turn. As a CEO, odds are that you are not where you are now by chance. You identified a need in the market or something you wanted to improve in society. You didn’t wait to see if things happened on their own - you stood up, took risks, and worked on achieving your vision. You probably worked day and night, endlessly postponing your personal life, sacrificing the comfort of seeing your friends and family, and putting your own health on the line… with a potentially high level of stress and lack of time to cook healthy meals. After all those long hours of hard work, who can blame you for having pizza and soda at 2 am when you’ve just had to meet a customer deadline? I was also there as a CEO, and I deeply understand how it feels when you see some employees leaving their desk at 6 pm, arriving late and tired the morning after a big party, or spending a lot of time having fun around the coffee machine. I felt powerless and somehow abandoned by the very people I paid with my own money when the company cash level was low. I was tempted to ask for free overtime, but I also felt that something was wrong. Was it about my own psychological needs or the organization’s needs? Is employee free overtime an efficient way to measure commitment to the organization’s goals? Well… years later, I can clearly say it was more about my own psychological needs as a CEO than the organization’s needs. Markets and technologies are moving at a higher pace every month. In this complex adaptive environment, what helps achieve the organization’s vision is delivering value to delight customers here and now, and not endlessly doing more of the kind of work we used to do before. What we need is true collaboration and creativity from the teams to inspect and adapt our products, business models, and the way we delight customers. I noticed that employees who have lives outside of work are more able to think out of the box - and more able to focus on creating value out of the blue. They brought new patterns, experiences, and connections into their work. Can this happen if they’re stuck at their desk 10 hours a day? Chances are low. My experience is that free overtime is a poor demonstration of commitment to the organization’s success. As Kate Hobler wrote in her article, commitment is often misunderstood and it’s something you may want to inspect for yourself as a CEO or manager. Not inspecting it may foster fear and uncertainty in your work environment as Rich Visotcky detailed. I couldn’t agree more. Free overtime demonstrates a poor commitment to what is important for organizations: productively and creatively achieving the company’s vision by delighting customers. It’s not about the hours you stay at your desk - life is unfortunately not that simple.

Lors de mes formations Scrum ou en coachings d'organisations, il n’est pas rare que les participants expriment leur souhait d’accéder à davantage du contenu Scrum de qualité en français. Cette série « Le meilleur de Scrum » contribue à répondre à 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. Cet article est une traduction d’un article original de Hiren Doshi : The Three Pillars of Empiricism (Scrum). Hiren est Professional Scrum Trainer (PST) chez Scrum.org, et auteur de l’ouvrage : Scrum Insights for Practitioners: The Scrum Guide Companion. Vous retrouverez une interview d’Hiren Doshi en fin d’article. Bonne lecture :) Les Trois Piliers de L’Empirisme (Scrum) Travailler de façon empirique signifie qu’on agisse sur la base de faits, d’expériences, et de preuves. Scrum met en oeuvre un processus empirique au sein duquel les progrès sont établis sur des observations de la réalité, et pas sur des plans fictifs. Scrum accorde une place importante à l’état d’esprit et aux changements culturels pour atteindre l’agilité économique et organisationnelle. Les trois piliers de l’empirisme sont tels que ci-dessous : Transparence: Cela signifie présenter les faits tels qu’ils sont. Tous les individus concernés (clients, PDG, et autres contributeurs individuels) font preuve de transparence dans leurs relations quotidiennes. Ils se font confiance et ont le courage d’affronter les bonnes comme les mauvaises nouvelles. Tous s’efforcent de collaborer collectivement vers le but commun à l’organisation, et personne n’a d’agenda caché. Inspection : Dans ce contexte, l’inspection n’est pas réalisée par un inspecteur ou un auditeur, mais par tout un chacun dans l’équipe Scrum. L’inspection peut être appliquée au produit, aux processus, aux aspects humains, aux pratiques, et à l’amélioration continue. Par exemple, l’équipe présente ouvertement et de manière transparente le produit au client à la fin de chaque Sprint, afin de recueillir de précieux avis. Si le client modifie son besoin pendant l’inspection, l’équipe ne s’en plaint pas mais au contraire exploite cette opportunité de collaboration en s’adaptant à cette clarification des exigences et à l’expérimentation de cette nouvelle hypothèse. Adaptation : L’adaptation, dans ce contexte, à trait à l’amélioration continue, à la capacité à s’adapter en fonction des résultats de l’inspection. Toute personne de l’organisation doit poser cette question régulièrement : Sommes-nous dans une meilleure situation qu’hier ? Pour les organisations commerciales, la valeur est représentée sous forme de rentabilité. L’adaptation devrait éventuellement être liée aux raisons premières du choix de l’agilité : Notons par exemple, un temps de commercialisation plus rapide, un retour sur investissement amélioré grâce à des livraisons basées sur la valeur, un coût total de possession réduit par l’amélioration de la qualité logicielle, et une plus grande satisfaction des clients et des employés. Le bon fonctionnement de Scrum n’est pas dû aux trois rôles, aux cinq événements ou aux trois artéfacts, mais à l’adhésion aux principes agiles sous-jacents d’itérations, de livraisons incrémentales fréquentes basées sur la valeur, de collecte des retours utilisateurs et sur l’acceptation du changement. Cela génère des temps de commercialisation plus courts, une plus grande prévisibilité des livraisons, une réactivité accrue aux besoins clients, une capacité à changer de direction en tenant compte des priorités changeantes, une amélioration de la qualité logicielle, et une meilleure gestion des risques. C’est l’un des sujets que j’ai abordé dans mon livre : « Scrum insights for practitioners: The Scrum Guide Companion ». Bonne lecture ! Interview de Hiren Doshi Hiren, pourquoi as-tu ressenti le besoin d’écrire cet article ? Cet article est issu de mon livre “Scrum Insights for Practitioners”. J’ai écrit cet article parce-qu’il y avait un flou dans la compréhension de ce que signifient Transparence, Inspection et Adaptation dans le guide Scrum. J’ai souhaité apporter une explication simple des trois piliers de l’empirisme. As-tu remarqué une différence lors de tes formations avec les participants ayant lu cet article ? Oui, ça aide significativement les participants à approfondir leur compréhension de Scrum. En particuliers lors de mes enseignements, je complète l’article en expliquant en quoi les trois Artéfacts de Scrum donnent vie à la Transparence, en quoi les cinq événements de Scrum donnent vie à l’Inspection et l’Adaptation, et en quoi les trois Rôles de Scrum donnent vie à un profond sens des responsabilité. Quelle est ton activité privilégiée pour aider les professionnels à gérer au mieux les trois piliers de l’empirisme ? En général, je propose une analogie avec la vie quotidienne. Par exemple, Avions-nous pu prévoir l’épidémie de Covid-19 ? Est-ce que certains pays ont été Transparents à propos du virus? Est-ce que le manque de transparence à dégradé la capacité à Inspecter convenablement ? Est-ce que les résultats de ces inspections dégradées ont diminués la capacité à s’Adapter ? Est-ce qu’une mauvaise adaptation entraîne un effondrement économique et la perte de nombreuses vies humaines ? 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 :-)

Le Daily Scrum n’est-il pas l’événement où l’on vient vérifier que l’équipe de développement avance comme prévu ? C’est une question récurrente lors de mes formations Scrum. Elle arrive souvent en début de session, un peu comme une pâle évidence à confirmer. Et pourtant, il s’agit bien d’un mythe, aussi toxique que répandu. Ce mythe nuit considérablement à l’efficacité des équipes Scrum et aux organisations qui les emploient. Explorons les différences clés entre le Daily Scrum et une réunion d’avancement. Qu’est-ce qu’un Daily Scrum ? Le Daily Scrum est un événement porté par et pour l’équipe de développement. Il lui offre l’opportunité d’inspecter le travail réalisé durant les dernières 24 heures, et de s’adapter pour l’atteinte de l’objectif du Sprint, avec un nouveau plan pour les prochaines 24 heures. Par l’intense collaboration qu’il provoque pour l’atteinte de l’objectif du Sprint, le Daily Scrum promeut et renforce l’auto-organisation de l’équipe de développement. Le sentiment d’urgence généré par son révolutionnaire timebox de seulement 15 minutes est une immense opportunité offerte à l’équipe de développement d’être et de devenir une réelle équipe, et pas une simple somme d’individualités. Le focus du Daily Scrum vers l’objectif du Sprint et ce court timebox nous poussent tous à l’essentiel : Collaborer avec productivité et créativité. L’équipe de développement peut-elle y inviter d’autres personnes ? Le Scrum Guide est silencieux à ce sujet. Il précise cependant que le Daily Scrum est pour l’équipe de développement et que cette dernière est auto-organisée. C’est à dire qu’elle décide par et pour elle-même comment atteindre au mieux ses objectifs. Une équipe de développement peut décider d’inviter un tiers (Scrum Master, Product Owner, ou expert) si cela lui est utile à un moment donné, mais le risque est grand d’abimer ses actifs les plus utiles à l’atteinte de l’objectif du Sprint : Collaboration sincère et auto-organisation. Personnellement, lorsque quelqu’un vient m’observer travailler, mon comportement a tendance à changer, pas vous ? Qu'est-ce qu'une réunion d’avancement ? S’il n’y a pas de définition formelle, l’usage constaté dans les organisations est que chaque individu expose tour à tour son avancement propre en lien avec les travaux qui lui ont été assignés par une autre personne. Le focus est posé sur la réalisation des tâches ou l’atteinte de jalons, pas sur la valeur délivrée ni sur l'impact utilisateur, et enfin les contributions individuelles sont scrutées, voir comparées. Ces réunions d’avancement tendent consciemment ou inconsciemment à imposer un contrôle sur les individus et à mesurer leurs contributions individuelles. Les individus étant incités à se faire concurrence, la collaboration est endommagée tout comme l’indispensable Transparence nécessaire au bon fonctionnement de l’Empirisme. Transformer le Daily Scrum en réunion d'avancement est un frein parfois brutal à la création de valeur par l'équipe Scrum et va contre l'intérêt bien compris des parties prenantes. Le Daily Scrum contrôle naturellement les risques du Sprint En nourrissant l’équipe de développement de confiance, le Daily Scrum renforce la Transparence. Son rythme quotidien permet de contrôler non pas les individus, mais les risques qui ne manquent pas d’apparaitre dans nos environnements complexes adaptatifs. Ceux qui souhaiteront imposer leur présence au Daily Scrum mettent l’équipe en difficulté et le Sprint en danger. Ils signifient leur manque de confiance à l’équipe de développement et découragent les élans et idées les plus créatrices de valeur. Synthèse Par et pour l'équipe de développement, le Daily Scrum est indispensable à la création de valeur dans un environnement complexe. Sa capacité à donner vie à l'Empirisme et à l'auto-organisation de l'équipe de développement met quotidiennement les risques sous contrôle et maximise les chances d'atteindre l'objectif du Sprint, sans aucun besoin d'intervention extérieure à l'équipe de développement. Le Daily Scrum est un art, autant qu'un événement Scrum. Et vous, quelles techniques utilisez-vous pour rendre à cet événement toute son efficacité ?