Francois Fort

Cette question m’est posée régulièrement lors de mes formations officielles Scrum.org et j’aime y répondre. C’est une opportunité pour les participants d’explorer leurs passions et de se reconnecter à ce qui les fait vibrer, les rend vivants. Il n’y a pas « une » réponse standardisée, mais au contraire plusieurs options particulièrement enthousiasmantes. Les équipes Scrum sont autogérées A propos des équipes Scrum, le Guide Scrum nous apprend : « Elles sont autogérées, ce qui signifie qu’elles décident en interne qui fait quoi, quand, et comment » . C’est tellement révolutionnaire qu’on peut naturellement être tenté d’en diminuer la portée des termes. Ça serait une erreur. Dans leur publication « The New New Product Development Game », Hirotaka Takeuchi et Ikujiro Nonaka démontrent que l’autogestion est une fondation de l’efficacité des équipes face à un environnement complexe. Le terme Scrum est d’ailleurs un hommage à cette autogestion. « Scrum » fait référence aux mêlées (Scrum en anglais). Comme au rugby, le ballon est passé au sein de l'équipe alors qu'elle se déplace en tant qu'unité sur le terrain. Les caractéristiques du chef de projet L’institut de référence en management de projet, PMI® nous indique les domaines d’excellence du chef de projet : Agent du changement, planification, maximisation du résultat, recueil des besoins des parties prenantes, organisation des travaux, maîtrise de la qualité et incarnation d’une vision partagée. Le Pmbok® (ouvrage de référence des certifications PMI®) définit le chef de projet par : « La personne désignée par l’organisation pour diriger l’équipe chargée d'atteindre les objectifs du projet ». Si la définition (contrôle des individus) diverge de ce que nous souhaitons faire en agilité avec Scrum (autogestion), les compétences, elles, offrent de belles opportunités pour les chefs de projet souhaitant avancer vers Scrum. Parcourons ensemble les options possibles : Devenir Product Owner Devenir Développeur Devenir Scrum Master Rester chef de projet et être une partie prenante du produit portée par l’équipe Scrum Devenir Product Owner Le Product Owner est responsable de maximiser la valeur du produit. Il représente les parties prenantes et a autorité sur le product backlog. Le Product Owner est un professionnel passionné par la création de produits et services incroyables. Si vous avez plaisir à comprendre vos parties prenantes de la manière la plus fine possible, si vous aimez résoudre des problématiques business complexes créatrices de valeur, si des clients heureux vous rendent profondément heureux. Alors n’hésitez pas à vous lancer dans une carrière de Product Owner ! Pour vous préparer, la formation certifiante Professional Scrum Product Owner™ pourrait vous être d’une grande aide. Devenir Développeur Le Développeur est une des personnes de l’équipe Scrum engagée à créer des incréments de produit utilisables. Développeur ne veut pas forcément dire programmeur informatique. Il s’agit de toutes les compétences nécessaires à la création d’incréments Sprint après Sprint, vous pouvez être un spécialiste du marketing, des ressources humaines, de la qualité, du hardware, de la user experience, du big data ou bien sûr du Développement informatique par exemple. Si la transformation d’une idée en incrément de produit vous fait vibrer, si vous attaquer à la planification et à la réduction des inter-dépendances vous passionne, si vous aimez collaborer en équipe autogérée et voir de vos propres yeux l’impact de vos réalisations sur les utilisateurs. N’hésitez plus, une carrière de Développeur s’ouvre à vous ! Pour vous préparer, la formation certifiante Applying Professional Scrum™ pourrait vous être très utile. Devenir Scrum Master Le Scrum Master aide tout un chacun à comprendre Scrum, sa théorie, ses pratiques, ses règles et valeurs tels que décrits dans le Guide Scrum. C’est un maître de l’empirisme. Le Scrum Master favorise l’efficacité de l'équipe Scrum, du Product Owner et de l’organisation dans sa transformation Agile. Si ré-humaniser l’espace de travail vous comble, si aider les professionnels à développer leur efficacité vous réjouit, si aider l’organisation à développer son agilité business vous inspire. La carrière de Scrum Master est probablement pour vous! Pour vous préparer à cette responsabilité, la formation certifiante Professional Scrum Master™ pourrait vous apporter énormément de valeur. Personnellement, cette formation m'a transformé. Devenir partie prenante… Et rester chef de projet en dehors de l’équipe Scrum, car c’est une noble mission. Avec Scrum, il y a trois responsabilités : Développeur, Scrum Master et Product Owner. Les autres professionnels ayant un intérêt au produit développé sont appelés parties prenantes. Un chef de projet est une partie prenante avec Scrum. Il ou elle échange régulièrement avec le Product Owner et peut être invité à participer à l’inspection collective lors de la Sprint Review. Le leadership par exemple est une forme de parties prenantes. Si donner du feedback et des idées au Product Owner pour maximiser la valeur du produit vous enthousiasme, si contribuer à la résolution des obstacles organisationnels vous passionne, si contribuer à l’inspection collective de l’incrément lors de la Sprint Review vous nourrit intellectuellement. Alors devenez partie prenante du produit développé par l’équipe Scrum ! Pour vous préparer au mieux à cette expérience, la formation Applying Professional Scrum™ va beaucoup vous aider à tirer le maximum de cette posture. Faites vous plaisir Les chefs de projets souhaitant avancer vers l’agilité peuvent par exemple devenir parties prenantes, ou s’engager vers l’une des trois responsabilités de Scrum (Développeur, Scrum Master ou Product Owner). La recherche scientifique sur le cerveau montre que l’apprentissage de nouvelles aptitudes est favorisé par le plaisir et la socialisation. Alors voilà, faites-vous plaisir… Choisissez l’option qui vous intéresse le plus, celle dont les sujets et les défis vous passionnent le plus, et n’hésitez pas à partager vos découvertes avec d’autres professionnels. Sources : - PMI Pmbok 6th - Whitten, N. (1999). Duties of the effective project manager. PM Network, 13(9), 16. - « The New New Product Development Game », par Hirotaka Takeuchi and Ikujiro Nonaka, Havard Business Review (Jan. 1986) - « The Accelerated Learning Handbook », Dave Meier

L’apport le plus notable de la version 2020 du Guide Scrum est l’ajout d’un Product Goal au Product Backlog. Cette nouvelle caractéristique du Product Backlog vient accroître la transparence de cet artéfact Scrum. Explorons ensemble ce que le Product Goal implique et comment en tirer parti en 7 questions. 1 - Qu’est-ce que le Product Goal ? Le Product Goal est un but mesurable à atteindre par le produit. Il rassemble l’équipe Scrum et les parties prenantes autour du pourquoi du contenu du Product Backlog. Le Product Goal est la cible vers laquelle le Product Backlog est affiné. Le propre des environnements complexes est que de nombreux faits et savoirs émergent sans crier gare, aussi il est possible que l’équipe Scrum atteigne le Product Goal sans avoir réalisé tous les Product Backlog Items (PBIs). Il est aussi probable qu’au fur et à mesure de la valeur créée par les différents Sprints, que le Product Goal lui-même soit affiné, fort de ces nouvelles connaissances. Le Product Goal permet aux équipes Scrum de mieux comprendre les intentions des uns et des autres par leur liaison à cet objectif cadre. Lorsque les membres d’une équipe sont au clair sur le pourquoi ils travaillent ensemble, ils ont la légitimité et la force de prendre les meilleures décisions possibles pour maximiser la valeur. L’inspection collective de l’incrément résultant du Sprint Goal en Sprint Review est éclairée par cet objectif cadre qu’est le Product Goal. Il facilite l’inspection des découvertes et l’adaptation du Product Backlog. 2 - Quelle est la différence entre Product Goal et vision ? L’ajout du Product Goal donne plus de clarté et renforce le focus des équipes Scrum. Le Product Goal est désormais un élément nécessaire à tout Product Backlog, il permet aux équipes de travailler et de se lancer. Probablement trop vague dans la pratique, le terme vision a littéralement disparu du Guide Scrum. Aujourd’hui, rien n’interdit de placer le Product Goal dans le contexte plus large d'une vision. L’usage d’une vision est désormais une pratique complémentaire à Scrum. 3 - Qui crée le Product Goal ? Le Product Owner est comptable du développement et de la bonne communication du Product Goal. Un travail continu entre le Product Owner, l’équipe Scrum et les parties prenantes est indispensable pour s’assurer que le Product Goal soit à la fois connu et clairement compris par tous. Un Product Goal à la fois inspirant et tangible, est un moteur puissant pour toute équipe Scrum. 4 - A quelle fréquence change le Product Goal ? Dans la majorité des cas, il faudra plusieurs Sprints pour atteindre cet objectif stratégique qu’est le Product Goal. Certaines équipes pourraient changer leur Product Goal chaque année, quand d’autres le changeraient chaque mois en cas de Sprints courts et d’un contexte marché ou technologique volatile. Le Guide Scrum n’impose aucune prescription à ce sujet. Il laisse chaque Product Owner décider de la fréquence, régulière ou non, la mieux à même de maximiser la valeur générée par le produit. 5 - Que se passe-t-il si le Product Goal change au cours du Sprint ? Le Sprint Goal est un pas vers le Product Goal. Il peut arriver, qu’en cours de Sprint, l’équipe découvre quelque chose qui vienne invalider le Sprint Goal, voire même, cas encore plus rare, le Product Goal. Le Guide Scrum laisse aux équipes le loisir de décider en fonction de leur propre contexte de l’action à suivre. Par exemple, dans certains cas le Product Owner pourrait décider d’arrêter le Sprint et retrouver les parties prenantes pour discuter ensemble des résultats. Dans d’autres cas, l’équipe Scrum pourrait utiliser la prochaine Sprint Review pour affiner un nouveau Product Goal. Les règles du jeu de Scrum donnent aux équipes suffisamment de liberté pour identifier ce qui est le mieux dans leur contexte pour maximiser la valeur du produit. 6 - Peut-on avoir plusieurs Product Goals à la fois ? Il y a un seul et unique Product Goal par Product Backlog, lorsque le Product Goal actuel est atteint, un nouveau Product Goal est créé. Il est possible de définir un Product Goal constitué de plusieurs éléments précisant le but à atteindre. Dans ce cas, il est important de veiller à ce que ce Product Goal reste clair et concis, conformément à sa raison d’être. 7 - Que conclure de l’ajout du Product Goal à Scrum ? Je travaille régulièrement avec les équipes Scrum à faire émerger l’indispensable alignement entre la stratégie business des organisations et la direction du produit. Le Product Goal, parce qu’il introduit la notion d’objectifs précis est une aide bienvenue offrant aux équipes de mieux se synchroniser avec la stratégie business des organisations pour maximiser davantage la valeur générée.

Pour le 25ème anniversaire de Scrum, ses co-créateurs, Jeff Sutherland et Ken Schwaber nous livrent le millésime 2020 du Guide Scrum. Cette version améliorée, réduite à 13 pages est à la fois plus simple et moins prescriptive. Scrum abandonne les termes dédiés à l’informatique pour développer un vocabulaire plus inclusif, à destination de toute les équipes adressant des problématiques complexes, quels que soient les secteurs ou industries. Explorons ensemble ces changements. Une équipe Scrum, un produit Le Guide Scrum ne reconnaît désormais plus qu’une seule équipe, l’Équipe Scrum. L’objectif ici est de prévenir d'éventuels effets claniques entre l’Équipe de Développement et l’Équipe Scrum. Il y a désormais une Équipe Scrum focalisée sur un même objectif, elle est constituée d’un Product Owner, un Scrum Master et de Développeurs. Auto-management, plutôt qu’auto-organisation Les versions précédentes du Guide Scrum faisaient référence au terme auto-organisation pour caractériser le choix par l’Équipe de Développement de qui et comment réaliser le travail. Avec un focus désormais mis sur l’Équipe Scrum, la version 2020 du Guide Scrum fait évoluer cette notion. L’ Équipe Scrum est auto-managée, c’est à dire qu’elle choisit qui, comment et sur quoi travailler. Introduction du Product Goal Le concept nouvellement introduit de Product Goal apporte à l’Équipe Scrum un focus vers un objectif de valeur plus large. Chaque Sprint se doit de rapprocher le produit du Product Goal. Le terme vision disparaît du Guide Scrum. Un foyer pour le Sprint Goal, la Definition of Done et le Product Goal Le Sprint Goal et la Definition of Done n’ont jamais fait parti des rôles, événements ou artéfacts de Scrum, ils faisaient parti des règles qui lient ces éléments, mais sans identités propres. Ils n’étaient pas des artéfacts, mais y étaient rattachés d’une façon ou d’une autre. La version 2020 du Guide Scrum vient clarifier ce sujet. Chacun des trois artéfacts contient à présent un engagement qui lui est propre : - Au Product Backlog est associé un Product Goal - Au Sprint Backlog est associé un Sprint Goal - A l’Incrément est associé une Definition of Done Ce rattachement a été créé pour apporter plus de transparence et de focus sur l’avancement de chaque artéfact. Trois sujets pour le Sprint Planning Un « Pourquoi » est ajouté aux traditionnels sujets « Quoi » et « Comment » évoqués lors du Sprint Planning. Ce « Pourquoi » fait référence au Sprint Goal. Cette formalisation officialise un fonctionnement de fait seulement induit par les anciennes versions du Guide Scrum. Un retour à l'essence de Scrum Scrum n’est toujours PAS UNE MÉTHODOLOGIE. C’est un cadre de travail qui n’a jamais été aussi fidèle a ses caractéristiques qu'aujourd'hui : Léger, simple à comprendre, et difficile à maîtriser. Scrum s’améliore par affinages successifs, se libérant de formulations trop prescriptives ou répétitives. A titre d’exemple, les bien connues 3 questions du Daily Scrum ont été mises au rebut, tout comme les guillemets entourant le terme Done, ou encore l’obligation d’ajouter un plan d’amélioration au Sprint Backlog du prochain Sprint à l'issue de la Sprint Retrospective. Cette ré-écriture du Guide Scrum s'émancipe aussi des termes informatiques tels que système, conception, ou spécifications. Elle officialise l'intégration de toutes les équipes adressant des problématiques complexes, quels que soient leurs secteurs, renouant avec la vocation lean et inclusive de Scrum.

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. ..

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 :-)

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 de contenus 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é ?