À lire les nombreux articles qui fleurissent un peu partout, la gestion de projet hybride semble parée de toutes les vertus.
Si cela n’est pas dénué de certains fondements, cette approche possède également quelques inconvénients que l’on oublie trop souvent de présenter.
Qu’est-ce qu’une méthode hybride
Pour commencer, il semble intéressant de revenir à la définition même de la gestion de projet hybride.
Une méthode hybride en management de projet est une approche qui combine différentes méthodes et techniques de gestion de projet pour répondre aux besoins spécifiques d’un projet donné. Elle peut inclure des éléments de méthodes agiles et traditionnelles, ainsi que d’autres approches adaptatives ou itératives.
Pour avoir pratiqué de nombreuses méthodes de gestion de projet durant plus de 25 ans, je reconnais un certain nombre de qualités à l’approche hybride.
En effet, elle permet de combiner les éléments issues des méthodes agiles pour la rapidité de livraison et la réactivité aux changements, avec des éléments issus de la méthode traditionnelle (cycle en V) pour une planification plus structurée et une gestion plus rigoureuse des coûts et des ressources.
Le célèbre cycle en V des approches prédictives
Ainsi, cette approche hybride peut aider à maximiser les avantages de chaque méthode, tout en réduisant les risques et en garantissant une livraison de projet réussie.
Les prérequis trop souvent oubliés
Mais, trop souvent, nous oublions le fait que tirer parti des avantages de chaque méthode nécessite de les connaître en profondeur, de les avoir éprouvées au travers d’expériences concrètes, de succès mais aussi d’échecs.
Cet apprentissage par la pratique rejoint le fameux principe du shuhari, issu des arts martiaux japonais et repris par Alistair Cockburn, figure emblématique de la communauté Agile :
Shu: Découvrir et suivre les règles à la lettre pour les conserver et les protéger
Ha: Comprendre les règles, se les approprier, les éprouver pour en comprendre les limites, faire le lien avec d’autres techniques.
Ri: S’en détacher, les adapter au contexte, voir créer ses propres règles.
La gestion de projet hybride représente donc l’étape ultime, le « Ri » de ce processus d’apprentissage auquel on ne peut accéder qu’au travers des étapes précédentes.
De fait, nous sommes assez loin de la situation trop classique d’une « méthodologie » créée en mode pompier, souvent sur un coin de table et à partir de petits bouts de savoir théoriques, pour tenter de sauver un projet devenu incontrôlable.
La gestion de projet hybride n’est là ni pour pallier à l’absence de formation ni au manque d’expérience pratique des parties prenantes. Et encore moins à l’absence de volonté de transformation des organisations, de formation et d’accompagnement nécessaires lors du passage en mode Agile.
Le côté obscur de l’approche hybride
Se lancer dans une approche hybride sans en maîtriser l’ensemble des composantes présente aussi de nombreux inconvénients qui peuvent rapidement devenir des risques projet.
Les principaux inconvénients :
Le manque de clarté de la démarche : L’accumulation de pratiques disparates, parfois redondantes ou qui présentent des ruptures, est source de confusion et de complexité. Il en résulte souvent une définition floue des rôles et responsabilités de chacun. Ce qui entraîne des erreurs, des retards et surtout de la tension. Ajoutez à cela l’impact du télétravail et le cycle naturel de création des équipes et vous obtenez rapidement une bombe à retardement.
Des coûts supplémentaires : Une méthodologie hybride constituée de techniques mal maîtrisées demande du temps pour se stabiliser. L’affiner et la formaliser nécessite des investissements en formation, en description des processus, en formations à l’utilisation des outils (mal) adaptés à cette méthodologie. Le moindre ajustement vous oblige à reprendre l’ensemble. Bref, tout le monde passe plus de temps sur la méthodologie que sur la production en elle-même.
Le manque de répétabilité : C’est l’une des raisons pour lesquelles la plupart des discours sur les méthodologies hybrides ne se réfèrent qu’à des anecdotes et des expériences auxquelles on ajoute plus ou moins de storytelling. En effet, étant par principe destinée à s’adapter à une situation particulière, chaque méthodologie hybride est unique. Il est donc impossible d’établir des processus standardisés et donc d’établir des études comparatives sérieuses ni même d’en mesurer l’efficacité. Cela rend également obsolète la notion de capitalisation du savoir et de retour d’expérience.
La gestion de projet hybride répond efficacement à certaines situations
En conclusion, oui, la gestion de projet hybride répond à certaines situations. Tous les projets ne nécessitent pas obligatoirement de passer en mode Agile. Apporter de la flexibilité, de la réactivité et mettre la valeur au centre des préoccupations sont de bonnes pratiques qu’il faut encourager.
Mais attention, l’approche hybride ne doit pas être le joker destiné à masquer le manque d’expérience et de maîtrise des méthodologies projet, qu’elles soient classiques ou Agiles.
Contrairement, à ce que l’on entend trop souvent, elle n’est pas non plus un « premier pas » vers l’agilité. En effet, soit votre méthodologie hybride donnera de mauvaises habitudes / pratiques qu’il sera très difficile de changer par la suite. Soit son échec sera utilisé comme un argument de poids par vos détracteurs pour démontrer que l’agilité ne fonctionne pas. Et cela, même si vous ne l’avez pas mis en œuvre dans sa forme la plus basique.
Bref, entre le cycle en V, le Lean, le Kanban, le SCRUM ou le SAFe, il existe de nombreuses méthodes et outils à explorer avant de vouloir faire preuve de créativité.
Ne tombez pas dans l’effet Frankenstein : Une accumulation d’outils et de techniques non maîtrisés ne fait pas une méthode de projet viable. Le monstre aura tôt fait de se retourner contre son créateur et de semer la terreur autour de lui.
Qui est Pierre-Étienne Pernet ?
Pierre-Étienne Pernet
Après 10 ans de gestion et de direction de projets internationaux au sein d’Oracle Consulting, Pierre-Étienne PERNET a rejoint les équipes internes de développement d’Oracle Corporation. Il y a occupé un poste de Product Manager dans les équipes Supply Chain d’Oracle Cloud pendant près de 15 ans. Il a collaboré au développement du module Asset Lifecycle Management.
Aujourd’hui, il est Directeur Consulting Delivery chez CGI. Au sein de l’entité France Global Delivery Center, il a en charge des équipes de consultants dédiées à l’ERP Oracle. Il partage son activité entre la direction de TMA et la direction de projets.
Diplômé d’un Master en gestion de projet et d’affaires au sein de l’Institut International du Management, il a enseigné le management de projets en cycle d’ingénieur au sein du Conservatoire National des Arts et Métiers de Lille pendant 9 ans, en parallèle de son activité professionnelle.
Certifié SAFe, ITIL et PMP, il est membre du chapitre Nord de France du Project Management Institute et volontaire au sein du programme de mentorat. Il accompagne bénévolement les membres du PMI qui souhaitent profiter de ce programme mis gratuitement à leur disposition.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?
Prioritisation in Agile: Focus on the Benefits par Quay Consulting
L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.
Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.
Relisez ce billet
Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.
Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.
Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?
Contraintes de priorisation
Le time-boxingest une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.
Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.
Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.
Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?
Facteurs de priorisation
Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.
Par exemple :
Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?
Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.
Le processus de priorisation et le contexte
Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles. Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.
Il y a un peu plus…
Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables. La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.
Considérons ce que chaque composant représente :
Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.
Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.
Maintenir un focus laser sur les bénéfices et le retour sur investissement
Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.
La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.
Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous propose de commencer par Scrum.Org avant de zoomer sur les valeurs de Scrum, le Sprint Planning et les Sprint Reviews.
Ces vidéos peuvent s’avérer très utile pour sensibiliser votre comité de projet, votre sponsor et autres parties prenantes à ce qu’est Scrum avec ses valeurs ainsi que certaines de ses « cérémonies » les plus utiles.
Dans cette vidéo de 2 minutes, apprenez-en davantage sur ce que Scrum.org est et fait.
Voici quelques exemples de comment appliquer les valeurs Scrum de courage, engagement, focus, ouverture et respect.
Comment faciliter le Sprint Planning ?
Dans cette vidéo introductive, comprenez comment et quand utiliser certaines techniques de facilitation comme le vote romain, la visualisation et le questionnement afin que votre équipe puisse quitter la session de planification du sprint avec un objectif de sprint en direction de l’objectif du produit et un plan initial pour le sprint.
Comment faciliter les primordiales sessions de Sprint Review ?
Voici au moins une technique de facilitation qui va vous aider à transformer la revue de sprint en une session plus engageante et collaborative. Vous pourrez alors y recueillir des commentaires précieux des parties prenantes pour déterminer les futures adaptations de votre approche et de votre produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Daily Scrum n’a qu’un seul but : Inspecter les progrès vers l’objectif de sprint en réfléchissant à l’apprentissage d’hier. Ensuite, si le besoin s’en fait sentir, les développeurs adaptent leur plan pour atteindre l’objectif de sprint. Bien que la théorie puisse être généralement acceptée, passer de l’idée à la pratique est plus difficile. L’un des problèmes récurrents est la popularité continue des « 3 questions du Daily Scrum» selon le Guide Scrum 2017.
Réfléchissons à la raison pour laquelle répondre à ces questions obsolètes influence négativement l’équipe Scrum.
Le but du Daily Scrum
Le but du Daily Scrum est clairement décrit dans le Guide Scrum, aucune supposition n’est nécessaire :
« Le but du Daily Scrum est d’inspecter les progrès vers l’objectif de sprint et d’adapter le backlog de sprint si nécessaire, en ajustant le travail prévu à venir.
Guide téléchargeable gratuitement
Le Daily Scrum est un événement de 15 minutes pour les développeurs de l’équipe Scrum. Pour réduire la complexité, il a lieu à la même heure et au même endroit chaque jour ouvrable du Sprint. Si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que développeurs. »
Par conséquent, le Daily Scrum est un événement important pour l’inspection et l’adaptation, géré par les développeurs, et les guidant pour les prochaines 24 heures sur leur chemin vers la réalisation de l’objectif de sprint. Le Daily Scrum est également l’horizon de planification le plus court dans Scrum et donc très efficace pour guider les efforts de l’équipe Scrum : se concentrer sur le résultat.
Le problème avec les 3 questions quotidiennes
Cependant, cette noble idée est entachée d’une habitude répandue : Centrer la réunion quotidienne autour de la réponse à trois questions
Qu’est-ce que j’ai fait hier ?
Que vais-je faire aujourd’hui ?
Y a-t-il un obstacle ?
Initialement, ces trois questions du Daily Scrum ont été ajoutées au Guide Scrum 2017 comme exemple de la façon dont les membres de l’équipe Scrum peuvent inspecter les progrès vers l’objectif de sprint. Cependant, ces trois questions sont rapidement devenues synonymes de Daily Scrum. Depuis lors, il s’agissait de répondre à ces trois questions, de transformer le Daily Scrum en une sorte de réunion de rapport d’état d’avancement, avec des développeurs faisant la queue pour « répondre à ces trois questions » au Scrum Master, au Product Owner, ou peut-être même à une partie prenante.
Malheureusement, les « trois questions du Daily Scrum» plaisent à de nombreux praticiens : Elles sont simples, efficaces et créent une routine réconfortante. Cependant, en tant qu’équipe Scrum, nous nous soucions moins de détailler notre travail précédent et de justifier pourquoi nous méritons un chèque de paie à la fin du mois.
Au lieu de cela, nous voulons comprendre si nous atteindrons l’objectif de sprint. Si les progrès de l’équipe Scrum sont douteux, compte tenu des développements récents et des apprentissages, nous voulons prendre des mesures pour nous remettre sur les rails. Toute forme de rapport de situation est une simple distraction et un gaspillage à cet égard.
Scrum en tant que pratique est axée sur les résultats
Il ne s’agit pas de maximiser le nombre de tickets obtenus pendant le Sprint. Au lieu de cela, en tant qu’équipe, nous sommes intéressés par atteindre l’objectif de sprint.
Il existe d’innombrables façons d’exécuter votre Daily Scrum sans tomber dans cette routine des 3 questions. Par exemple, parcourez le tableau et déterminez ce qui doit être fait pour déplacer les billets les plus proches de « terminés » sur la ligne d’arrivée.
Livre sur Amazon
Consultez les pratiques d’utilisation des liberating structures pour faciliter le Daily Scrum.
S’il vous plaît, faites-vous une faveur et évitez de transformer votre Daily Scrum en une session de reporting ennuyeuse.
Comment gérez-vous vos Daily Scrum ? S’il vous plaît, partagez vos conseils et astuces dans les commentaires.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Il existe plusieurs techniques différentes pour mener le processus d’estimation. Cet article décrit ces techniques, leur pertinence et leur praticité dans les projets Agiles.
Les estimations traditionnelles sont basées sur des unités de jours ou d’heures (dans de rares cas, je l’ai même vu utilisé pour estimer des histoires basées sur 20, 30 et 45 minutes), et l’équipe les utilise pour estimer leurs histoires et leurs tâches. À mon avis, c’est bien si cela aide l’équipe dans le processus de transition et même si elle veut l’adopter comme technique d’estimation. J’espère que vous ne tenez pas compte des récits selon lesquels les estimations traditionnelles ne conviennent pas à Agile car elles sont rarement exactes pour tous ceux d’entre vous qui pensent autrement.
Taille de T-shirt
La taille des t-shirts est une excellente technique d’estimation que j’utilise dans les organisations au début de la transformation. Vous ne pouvez pas utiliser de story points avec certaines équipes, car les membres de l’équipe alignent les story points sur des heures d’effort. Cela conduit à une confusion supplémentaire.
La taille du t-shirt permet aux équipes de surmonter ce problème car cette technique d’estimation n’est pas numérique. Cela permet aux équipes Agile de travailler avec quelque chose de plus facile à comprendre. Cela supprime la précision implicite d’une valeur numérique et libère l’équipe pour penser de manière abstraite à l’effort qu’elle doit investir dans chaque histoire.
Le processus de base de cette technique est relativement simple à utiliser
Un jeu de cartes représentant une taille spécifique est distribué horizontalement sur une table. Les tailles sont divisées en Extra Small (XS), Small (S), Medium (M), Large (L) et Extra Large (XL).
L’équipe ajoute chaque user story sous la carte de taille appropriée.
Une fois que toutes les histoires sont triées sur la base d’une discussion collaborative, l’équipe approuve leur sélection ou conduit un autre cycle de débat sur les histoires qui ont révélé une grande incertitude.
Vote par points (dot voting)
Le vote par points est une autre technique d’estimation relative. Il permet aux équipes Agile de voter leurs préférences parmi un ensemble d’éléments en plaçant simplement des points sur des éléments (par exemple, des fonctionnalités, des histoires, des obstacles, etc.) qui, selon elles, devraient avoir une priorité plus élevée que les autres éléments. Le nombre de points détermine le niveau de priorité. Plus il y a de points, plus la priorité de l’élément est élevée.
Le vote par points est une technique d’estimation très efficace car il permet à tous les membres de l’équipe d’affecter la priorité des éléments de manière égalitaire. Tous les membres de l’équipe ont un nombre égal de votes (représentés par des points), qu’ils peuvent répartir entre les éléments dans le cadre du processus d’estimation.
Par exemple, l’équipe a dressé une liste de huit points lors de la réunion rétrospective. Ils doivent maintenant restreindre la liste aux éléments de valeur la plus élevée. Pour ce faire, chaque membre de l’équipe reçoit un nombre égal de points (entre 3 et 5) pour voter sur les éléments.
Remarque: Ils peuvent mettre tous les points sur un élément ou les répartir entre différents éléments.
Le processus d’utilisation de haut niveau de cette technique d’estimation comprend les phases suivantes
Phase 1 : Facilitation, examen et vote
Tous les articles sont placés dans un endroit accessible pour permettre aux membres de l’équipe de voter.
Tous les éléments sont examinés et compris par toutes les parties prenantes.
Chaque membre de l’équipe reçoit un nombre égal de points (j’utilise généralement cinq points).
Chaque membre de l’équipe est invité à voter. Chacun des membres place des points sur les éléments en fonction de son jugement.
Une fois le processus d’estimation terminé, les articles sont classés du plus fort au plus faible nombre de points.
Approuvez avec l’équipe le résultat du vote.
Phase 2 : Ajustements et nouveau vote (facultatif)
Si l’équipe n’est pas complètement satisfaite du résultat (comme cela arrive souvent…), vous devez suivre les étapes suivantes pour optimiser le résultat :
Organisez les éléments en trois groupes pour représenter les priorités faibles, moyennes et élevées.
Passez en revue avec l’équipe les histoires de chaque groupe.
Lancez un nouveau cycle de vote pour tous les points de priorité la plus élevée.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !
Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business. SAFe 6.0 comprend de nombreuses nouvelles pratiques pour supporter les dernières tendances technologiques et business, y compris comment accélérer le flux de valeur et étendre SAFe à travers toute l’organisation à d’autres fonctions business.
Et, bien sûr, ces nouvelles directions se reflètent dans les mises à jour du didacticiel, de l’apprentissage en ligne et des ressources SAFe. Leading SAFe®, l’un des cours les plus populaires de Scaled Agile, est désormais disponible en français.
Pour tous les détails, lisez l’article What’s new in SAFe 6.0. Et n’oubliez pas de regarder les vidéos d’annonce de lancement de SAFe 6.0 pour en savoir plus sur SAFe Studio, SAFe 6.0 et d’autres nouveaux produits pour vous aider dans votre parcours SAFe.
Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles. La façon dont nous abordons les discussions difficiles peut faire la différence entre un moment de transformation et un déraillement. Heureusement, nous pouvons faire beaucoup pour nous préparer à ces moments où nous devons nous débattre d’une question épineuse. Examinons quelques stratégies pour faciliter les conversations difficiles de l’équipe Scrum.
Sujets sensibles et fort niveau émotionnel
Les conversations difficiles impliquent des niveaux élevés d’anxiété, d’inquiétude ou de doute. Peut-être devons-nous prendre une décision difficile ou trouver comment faire quelque chose que nous n’avons jamais réalisé auparavant. Peut-être qu’il y a un conflit entre les membres de l’équipe, ou qu’il y a eu un échec important ou bien un Sprint exceptionnellement difficile. Peut-être que les parties prenantes ne sont pas satisfaites des progrès ou ont des opinions divergentes sur l’orientation du produit ou sur la façon d’interpréter les changements sur le marché. Il existe une myriade d’exemples de circonstances à enjeux élevés auxquelles les équipes Scrum sont régulièrement confrontées et qui nécessiteront des conversations difficiles. Alors, comment pouvons-nous traverser ces périodes avec succès ?
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Respirez et préparez-vous
L’un des faux pas les plus courants que nous faisons face à une conversation difficile est d’être réactif et de sauter directement sur une tentative pour « résoudre » le problème.
Mais une facilitation réussie implique de prendre le temps de vous familiariser avec la situation et de décider comment vous allez l’aborder.
Idéalement, vous serez en mesure de prendre suffisamment de temps pour vous préparer en toute confiance. Mais même dans les situations où une situation difficile a émergé, vous pouvez souvent faire une brève pause pour vous recentrer. Laisser le temps à la conversation de se dérouler avant de vous lancer vous aidera à comprendre les problèmes. Vous pourriez avoir besoin de proposer une ou plusieurs sessions de travail pour permettre aux gens d’analyser des idées et des options avant de vous réunir.
Définissez l’intention
Le fait d’être clair sur l’objectif de la conversation apporte de la clarté au processus de facilitation. Tout le monde autour de la table devrait savoir pourquoi ils sont là et quelles sont les attentes.
Êtes-vous réunis pour chercher à comprendre le point de vue de chacun ? Allez-vous réfléchir ensemble à des solutions ou parvenir à un consensus sur les idées déjà sur la table ? Devez-vous en équipe réparer les relations interpersonnelles ou créer une identité d’équipe plus claire ? Avoir une idée claire de l’objectif de se réunir réduit l’anxiété et maintient la conversation centrée et productive.
Soyez inclusif
Familiarisez-vous avec la gamme de techniques et activités de facilitation adaptées à différentes personnalités et attitudes. Certaines personnes préfèrent faire un remue-méninge par elles-mêmes avant de partager des idées en groupe. D’autres préfèrent interagir en petits groupes ou partager leurs pensées par écrit plutôt que verbalement. Les techniques impliquant la visualisation, les métaphores et autres outils créatifs peuvent également mieux convenir à certaines équipes. Vous aurez probablement besoin de combiner ces techniques et outils.
Comprendre la dynamique de notre équipe et présenter les options aidera à faire en sorte que tout le monde se sente aussi à l’aise que possible pour s’engager.
Soyez présent
Soyez présent et appréciez pleinement cette opportunité.
Les facilitateurs efficaces sont à l’écoute de ce qui se passe pendant la conversation en :
Écoutant activement (vous vérifiez avec l’orateur pour vous assurer que vous avez compris ou pour clarifier).
Lisant les messages non exprimés, telles que « se déconnecter » en regardant son smartphone ou d’autres indices.
Remarquant des interactions entre les membres de l’équipe qui pourraient révéler une dynamique tacite en action.
Être conscient et présent vous permet de détecter la direction de la conversation et de faire des choix éclairés dans l’instant.
Soyez flexible
Bien que vous deviez être intentionnel et prêt à faciliter, vous devez également vous adapter à ce qui se passe devant vous. Comme tous les agilistes le savent, les choses ne se déroulent pas toujours comme prévu, il est donc préférable de ne pas trop vous attacher à votre agenda ou à des structures de facilitation spécifiques.
Ralentissez
Il est très facile dans les situations de forte émotion de passer en mode réactif, ce qui réduit votre capacité à rester ouvert, flexible et créatif. Vous voulez éviter une réaction instinctive à ce que vous entendez ou expérimentez pour diriger la situation de manière réfléchie. Vous pouvez en apprendre plus sur cette dynamique dans ce précédent article Staying Creative in a Reactive World.
Prendre conscience de la façon dont vous réagissez pendant les périodes stressantes peut vous aider à rester calme et à changer de cap si nécessaire. Une première étape utile consiste simplement à ralentir les choses lorsque le stress du moment vous incite à les accélérer. Ce n’est pas aussi facile qu’il n’y paraît. Les anglophones nord-américains deviennent typiquement mal à l’aise avec des pauses de plus de quelques secondes dans les conversations. Il faut de la pratique.
Faire des pauses régulières pour traiter l’information améliore la compréhension et vous permet de répondre avec curiosité et ouverture. Alors, respirez et encouragez les autres membres de votre équipe à faire de même. Prendre des pauses fréquentes permet également aux membres de votre équipe qui pourraient avoir besoin de plus de temps pour traiter les informations de s’engager plus facilement. Il permet à chacun de prendre de meilleures décisions, plus éclairées.
Reconnaissez également que certaines situations et décisions nécessitent plus de temps que d’autres. Nous avons tendance à avoir un faux sentiment d’urgence dans nos organisations, mais souvent nous pouvons retarder un peu les décisions quand nous devons prolonger la conversation ou recueillir plus d’informations. L’expression « Prenez des décisions au dernier moment raisonnable » me vient à l’esprit.
Notez que je ne préconise pas d’étendre les durées des événements Scrum. Si les problèmes que vous devez traiter nécessitent plus de temps, il est préférable de déplacer ces discussions en dehors de l’événement.
Cultivez un « espace courageux »
Faciliter une conversation difficile avec succès nécessite une sécurité psychologique pour les participants. Les membres de l’équipe doivent savoir qu’ils ne seront pas punis ni humiliés pour avoir dit ce qu’ils pensaient et suggéré des idées. Mais gardez à l’esprit qu’un espace « sûr » ne signifie pas nécessairement être parfaitement à l’aise. Les membres de l’équipe vont éprouver des sentiments inconfortables en discutant de questions épineuses.
Je promeut plutôt l’idée d’un « espace courageux ». Dans un espace courageux, nous sommes prêts à être vulnérables. Nous sommes ouverts aux commentaires difficiles de nos collègues. Nous nous engageons à apprendre.
Les compétences en animation sont pour tout le monde
L’amélioration des compétences en animation n’est pas réservée aux Scrum Masters. Tout membre de l’équipe Scrum peut animer des événements et des sessions de travail. Les compétences en facilitation sont précieuses pour de nombreux problèmes qui surviennent dans votre vie professionnelle quotidienne, et lorsque chaque membre de l’équipe Scrum se sent à l’aise avec la facilitation, toute l’équipe en bénéficie.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Conclusion
Il existe de nombreuses techniques de facilitation créatives et intéressantes disponibles en ligne. Mais il est essentiel que vous soyez intentionnel quant aux techniques que vous sélectionnez, comment vous les combinez et comment vous choisissez de répondre dans l’instant en ce qui concerne la direction de ce qui émerge au cours de nos conversations.
C’est pourquoi j’apprécie la formation Professional Scrum Facilitation Skills (PSFS). Tout comme « there are no best practices in Scrum”, il n’a pas de meilleures techniques de facilitation. Ce cours vise à vous aider à développer l’état d’esprit d’un facilitateur, en apprenant à sélectionner des techniques efficaces pour différentes situations dans votre contexte.
Petit rappel: Développez la productivité et l’innovation avec des groupes de toutes tailles grâce aux Liberating Structures !
Visitez le site en Français
Voici un pointeur fort utile vers des méthodes (et une app pour votre mobile) pour vous aider à impliquer tout le monde lors de vos sessions de travail de groupe.
Téléchargez l’app LISA sur votre smartphone IOS ou Android. C’est gratuit, très intéressant et fort utile !
partagez ce billet avec vos amis, collègues et relations professionnelles
Les rétrospectives présentent de belles opportunités pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.
Improving organizational culture through retrospective recognition par Kiron Bondale
Après avoir observé les acheteurs frénétiques en compétition les uns avec les autres lors des ventes du Black Friday à l’automne dernier, on pourrait être tenté d’oublier que Thanksgiving était à l’origine une expression de gratitude.
Guide téléchargeable gratuitement
Le Guide Scrum n’identifie pas spécifiquement l’expression d’appréciations comme un ingrédient clé des rétrospectives de sprint, mais il énumère les activités qui peuvent intégrer l’appréciation telles que l’inspection des interactions des membres de l’équipe et le rôle du Scrum Master pour encourager l’équipe non seulement à être plus efficace, mais aussi à passer un moment plus agréable ensemble au prochain sprint.
Les animateurs de rétrospectives encouragent souvent les participants à identifier ce qui s’est bien passé ou ce qu’ils ont aimé. C’est une bonne opportunité pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.
Remercier pour l’aide reçue pour franchir un obstacle signifie aussi que vous seriez prêt à aider à votre tour.
Tout comme l’identification des possibilités d’amélioration, les membres de l’équipe doivent non seulement reconnaître les grandes réalisations, mais aussi les petites qui peuvent s’additionner au fil du temps. Nous sommes prompts à reconnaître un membre de l’équipe qui a laissé tomber ce qu’il faisait pour nous aider pendant quelques heures sur une question vraiment délicate, mais qu’en est-il de ce membre de l’équipe qui nous a emmenés prendre un café parce qu’il a remarqué que nous semblions être particulièrement stressés ce jour-là ?
Tout comme pour fournir des commentaires constructifs, nous ne devrions pas attendre une prochaine rétrospective pour nous remercier, mais la cérémonie de rétrospective offre une bonne occasion de remercier tardivement ceux dont les efforts ont fait la différence au cours du sprint passé. Un Scrum Master peut introduire cette pratique dans une rétrospective en utilisant des chocolats ou tout autre petit cadeau à offrir par les membres de l’équipe à ceux qu’ils souhaitent reconnaître. Dans les rétrospectives ultérieures, l’équipe peut identifier de nouvelles façons de faire pour garder la pratique vivante.
Toute personne qui a participé ou initié une chaîne de « paiement en avance » serait probablement d’accord avec l’auteur de l’article. Lorsque quelqu’un apprécie de vive voix ce que nous faisons, nous ressentons le besoin de faire de même. Exprimer régulièrement vos sentiments positifs pourrait améliorer progressivement la culture au sein de vos équipes, de vos départements et, éventuellement, de votre organisation globale.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.
Voici des questions que vous pouvez utiliser pour développer vos propres critères de qualification pour Agile :
Pouvez-vous obtenir le bon personnel ?
Les membres appropriés de l’équipe technique et métier doivent être dédiés au projet. Cela signifie que vous devez gérer les compromis difficiles entre le travail de projet et les considérations opérationnelles. Les projets agiles produisent des résultats rapidement, ils prennent donc beaucoup de temps aux participants. De plus, les approches agiles nécessitent des membres essentiels des équipes business et technique qui sont critiques à vos activités opérationnelles. Il est important de prioriser leur temps sur le projet afin qu’ils puissent contribuer efficacement.
Les ressources ont-elles une profondeur de connaissances appropriée ?
Une connaissance approfondie des domaines business et techniques liés au projet est cruciale. L’approche agile repose sur des experts métier travaillant en étroite collaboration avec les experts de l’équipe technique. Ce qui rend les méthodologies agiles Agile, c’est la réactivité à l’évolution des besoins. Les techniciens et les personnes du business compétents doivent constamment réévaluer les livrables du projet, les besoins de l’entreprise aux niveaux macro et micro et la priorité des fonctionnalités requises par le client final.
Le Sponsor a-t-il un état d’esprit Agile ?
Le sponsor doit être disposé à participer à des revues fréquentes du produit en construction, qui sont fondamentales dans l’approche agile. La réactivité agile aux conditions changeantes de l’entreprise et son environnement évolutif sont très différentes des méthodes de projet traditionnelles. Si un sponsor veut un ensemble linéaire et méthodique d’objectifs livrés selon un calendrier prédéfini, il aura du mal avec les livrables du projet en approche agile. Les sponsors qui sont mal à l’aise avec la nature évolutive de l’agilité créent des difficultés qui peuvent couler le projet.
L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?
Agile implique un dialogue profond, interactif et parfois difficile. Pour tirer le meilleur parti de ce dialogue, vous devez créer l’environnement le plus riche possible. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la colocalisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir. Essayez de faciliter un dialogue agile avec des outils de communication médiocres, c’est comme essayer de remorquer une caravane avec une tondeuse à gazon.
Existe-t-il une synergie entre les membres de l’équipe business et technique ?
Une équipe agile doit bien s’entendre pour réussir. Les méthodologies agiles nécessitent le dévouement d’experts business et techniques qui sont ouverts à soutenir de nouvelles idées et à se soutenir les uns les autres en tant qu’individus. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations.
Le produit peut-il être construit (et livré) de manière itérative ?
Les meilleures qualités des approches Agile proviennent de la fourniture de solutions partielles tout en apprenant de chaque itération. En plus des livrables logiciels, d’autres produits peuvent également être construits de cette façon. Avec un peu de créativité, des déménagements, la mise en œuvre de nouveaux processus et même certains projets de construction dans le bâtiment peuvent utiliser des approches agiles.
Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?
Si oui, partagez-les avec nous !
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
La roue de croissance du coaching agile est un outil pour les coachs agiles, les scrum masters, les leaders et tous ceux qui souhaitent accroître leur capacité à aider et à développer les équipes et les organisations en utilisant les principes et les pratiques agiles.
La roue vous permet de réfléchir et de grandir dans votre cheminement agile.
Faites-vous aider d’un autre coach Agile pour progresser.
Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes.
How does your team run their standups? par Kiron Bondale
Que vous les appeliez Scrums, stand-ups ou daily, une façon de planifier au fur et à mesure avec une approche adaptative est d’organiser régulièrement des événements de coordination pour s’assurer que tout le monde travaille de manière alignée et sur le travail le plus important.
L’un des sujets les plus courants pour de tels événements est de discuter de l’arriéré de travail de l’équipe à court terme.
Mais de telles discussions peuvent avoir lieu de différentes manières.
Pour s’assurer que tout le monde a la possibilité de s’exprimer, une approche pourrait être de discuter du travail incomplet personne après personne.
Bien que cela ait l’avantage de s’assurer que la voix de chacun soit entendue et donne à chaque membre de l’équipe l’occasion de remonter ses préoccupations ou de confirmer les hypothèses qu’il pourrait faire, cela peut également amener les membres de l’équipe qui ont déjà parlé à se désengager de ce qui est discuté par les membres de l’équipe qui viennent après eux. Bien que cela ne soit pas très préoccupant si le travail de chaque membre de l’équipe est indépendant des autres, dans la plupart des cas, il est probable qu’il y ait des dépendances entre les membres de l’équipe au niveau d’un élément de travail ou d’une activité.
Dans de tels cas, si un membre de l’équipe « s’est déconnecté » de la conversation, il pourrait manquer quelque chose d’important pour son travail ou manquer l’opportunité de corriger une hypothèse invalide faite par les autres.
Une alternative qui résout cet inconvénient est de travailler élément de travail par élément de travail. Cela est susceptible de garder la plupart des membres de l’équipe engagés plus longtemps que l’approche personne par personne, en particulier lorsque plusieurs membres de l’équipe doivent collaborer ensemble pour terminer un élément de travail. Cependant, lorsque certains membres de l’équipe ont terminé les éléments de travail qu’ils ont choisis et soutiennent maintenant activement les autres dans l’achèvement d’éléments de travail « étrangers », tous les membres de l’équipe peuvent ne pas avoir la chance de s’exprimer.
Lorsque les éléments de travail passent par un flux de travail bien défini, une autre option consiste à discuter des éléments de travail en fonction de la phase de développement dans laquelle ils se trouvent. En supposant que les membres de l’équipe travaillent sur des éléments à travers différentes phases, cela réduira la probabilité qu’un membre de l’équipe se désengage de la conversation générale, même s’il a déjà terminé la discussion des éléments de travail dans la phase en cours.
La plupart des outils de management du travail fournissent une méthode pour organiser les éléments dans les colonnes d’un tableau de travail afin que l’équipe puisse discuter des éléments incomplets dans l’ordre dans lequel ils sont présentés. Cependant, une approche plus efficace pourrait consister à donner la priorité aux quelques éléments vitaux qui méritent vraiment d’être discutés.
Il y a 3 façons courantes de le faire
Par coût du retard
Cela comprend des considérations telles que la valeur commerciale, la réduction des risques, la dépendance d’éléments de travail à venir ou la capacité d’exploiter une opportunité.
Par durée des éléments de travail
Visualisation sous forme de tableau Kanban
En supposant que l’équipe a atteint une maturité suffisante pour n’avoir que quelques tailles d’éléments de travail différentes, l’équipe pourrait se concentrer sur la discussion des éléments de travail actifs qui sont en dehors des attentes normales en matière de durée pour leur taille.
Par statut de l’élément de travail
Cela peut être fait en commençant par les éléments de travail bloqués, puis ceux avec des obstacles identifiés, puis (si nécessaire) les autres.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Beaucoup d’équipes avec lesquelles j’ai travaillé utilisent une méthode personne par personne pour leurs événements de coordination, mais je voulais comprendre quelle était la répartition entre les différentes approches.
66 % ont utilisé une approche élément de travail par élément de travail,
20 % ont été traitées personne par personne,
11 % ont discuté des éléments de travail par étape de développement et
3 % ont eu une autre méthode.
Dans ce dernier cas, j’avais demandé aux répondants de fournir des détails, mais dans la plupart des cas, les commentaires reflétaient une approche par élément de travail et par ordre de priorité.
Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes. Discuter de l’efficacité et de l’efficience de tous les événements standard dans les sessions d’amélioration des processus, tels que les rétrospectives, est un moyen de s’assurer que cela ne se produise pas.
le livre de Kiron Bonale : « Easy in Theory, Difficult in Practice » contient 100 autres leçons sur le leadership de projet
(Si vous avez aimé cet article, pourquoi ne pas lire le livre de Kiron Easy in Theory, Difficult in Practice qui contient 100 autres leçons sur le leadership de projet ?)
Petit retour sur 7 précédents billets au sujet des Daily Scrum meetings
Nous tirons un énorme avantage de prendre un engagement simple :
Nous respectons les délais.
L’avantage est qu’une fois que nous avons convenu de la date limite, nous n’avons plus à nous en soucier. Nous n’avons pas à négocier, à trouver des excuses ni même à stresser à ce sujet.
Il ne sera pas livré quand il sera parfait.
Il sera livré quand nous avons dit qu’il le serait.
Une fois que ceci est clair, la qualité de ce que nous expédions augmente grandement. Au lieu de passer du temps et de l’énergie à chercher des raisons, des excuses ou à être dans le déni, nous faisons simplement le travail.
Et au fil du temps, nous estimons de mieux en mieux les délais sur lesquels nous engager. Parce que si nous promettons, nous livrons.
Selon moi, comme avec l’approche Agile, les délais et les moyens sont fixés au départ, la variable d’ajustement devient le contenu et surtout la priorisation de ce contenu en fonction de sa valeur business et de la capacité de l’équipe à livrer.
partagez ce billet avec vos amis, collègues et relations professionnelles
« Mechanical Scrum » consiste à appliquer les principes et cérémonies de Scrum. « Professional Scrum » va plus loin, changeant la manière dont vous travaillez, pensez et agissez.
Cette brève vidéo de Scrum.org revient sur les idées qui supportent « Professional Scrum » et expose comment cela dépasse le Scrum Guide.
Et cette vidéo, plus longue et en français, entre dans les détails de ce qu’est Scrum Professionnel
French edition Scrum Pulse – Ne faites pas semblant, pratiquez Scrum professionnel ! avec Fabio Panzavolta
Scrum a été développé à l’origine pour des projets complexes de développement de logiciels. Il est maintenant utilisé pour presque tout type de produits crées en équipe. Le cadre, tel qu’il est défini dans le Guide Scrum, est un moyen simple mais puissant de mettre de l’ordre dans la complexité par l’apprentissage en fournissant des occasions fréquentes de feedback à la fois sur la façon de travailler et sur ce sur quoi nous avons et aurons à travailler.
Bien que de nombreuses personnes pratiquent Scrum, le pratiquer efficacement exige quelque chose de plus que de simplement suivre les mécanismes et les principes fondamentaux du cadre. Scrum professionnel aide les équipes à se défaire de cette habitude mécanique et routinière lorsqu’il s’agit de Scrum.
Dans ce webinaire Scrum Pulse, Fabio Panzavolta, PST @Scrum.org, partage avec les participants en quoi le Scrum professionnel est différent et comment il requiert les valeurs de Scrum, une mentalité et des méthodes de travail et de pensée différentes, en se concentrant sur les résultats et un environnement qui soutient le Scrum professionnel, y compris la confiance.
La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».
Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.
Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.
Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.
Une approche axée sur les livrables
Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.
Une approche axée sur les phases
Livre sur Amazon
Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.
Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.
Une approche axée sur la responsabilité
Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
Sondage auprès des professionnelles et professionnels du management de projet
57 % utilisaient une ventilation axée sur les livrables
28 % une approche axée sur les phases
9 % une approche axée sur la responsabilité
Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.
Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.
Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.
partagez ce billet avec vos amis, collègues et relations professionnelles
« Nous n’avons pas terminé tout le travail de ce sprint. Nous allons découper l’histoire afin d’obtenir du crédit pour le travail que nous avons déjà réalisé. »
« C’est fait à 90%, il faut juste le tester. Passons de 13 points à 1 point pour le prochain sprint. »
« Wow, c’est bien plus que 5 points. Nous aurions dû en faire un item à 13 points. »
« Nous n’avons pas terminé ces quatre histoires, nous allons simplement les reporter au prochain sprint. »
« C’est fait, il faut juste le tester. Créons une nouvelle histoire juste pour ça et marquons celle-ci comme terminée. »
J’entends ces phrases et d’autres similaires tout le temps. L’estimation, dans des circonstances normales, est difficile. Ensuite, tenez compte de ce qu’il faut faire lorsque vos estimations étaient « fausses » et que cela devient carrément désordonné. Ces exemples sont les raisons et les scénarios les plus courants que j’entends lorsque les gens posent des questions sur la réestimation du travail.
Alors, comment ré-estimez-vous le travail inachevé ?
Réponse courte : Je ne le fais pas.
Je ne ré-estime jamais le travail qui n’est pas terminé. Il n’a pas répondu à la définition de Done et retourne dans le l’arriéré de produit (le « backlog produit ») où il pourra être pris en compte pour le prochain sprint.
L’estimation ne change pas parce que nous avons commencé ou que c’est plus difficile que nous le pensions, et nous n’obtenons aucun crédit pour un travail qui n’est pas « terminé ».
En tant que « sauveteur » chef de projet, j’aime beaucoup la simplicité de la définition de Fait (Done) (les mesures de qualité requises pour le produit). Comme le binaire n’est qu’une série de 1 et de 0, la définition de Done n’a que 2 états, « Done » et « Not Done ».
À la fin du sprint , nous examinons chaque élément du backlog produit et nous nous demandons : « Est-ce que cela répond à la définition de Done ? » Si la réponse est oui, elle va à la revue du sprint. Si la réponse est non, cela retourne dans l’arriéré de produits.
« Not Done » est également très précis : l’élément de l’arriéré de produit n’est pas utilisable et ne génère donc aucune valeur. Cela retourne dans l’arriéré de produits et je le traite comme si aucun travail n’avait été fait. C’est dans l’arriéré de produit et vous le traitez comme n’importe quel autre élément du backlog. Il a juste l’avantage de plus de « préparation ».
Pourquoi ne ré-estimez-vous pas ?
C’est une bonne question. Il y a un certain nombre de raisons de traiter un item « Not Done » comme n’importe quel autre élément de l’arriéré de produit.
Doit être utilisable
La première raison vient directement du Guide Scrum. « Afin de fournir de la valeur, l’incrément doit être utilisable. » Je ne divise pas une histoire juste pour obtenir un crédit partiel. Si j’avais pu le diviser en un travail plus petit et qu’il était encore utilisable, j’aurais déjà dû le faire en guise de préparation. Nous nous concentrons sur les résultats (la valeur) et non sur les livrables (le travail accompli).
Le code pourrit
J’ai appris cela d’un développeur expérimenté il y a des années. Même dans les environnements où la « production » ne change que tous les six mois, la base de code peut changer beaucoup en une semaine. Lorsque le travail a commencé sur la nouvelle interface de connexion, les environnements étaient à l’état X. À la fin du sprint, les environnements étaient à l’état Y et lorsque nous avons finalement terminé l’interface de connexion, deux sprints plus tard, les environnements étaient à l’état Z. J’ai vu du travail qui répondait à la définition de Done dans le sprint précédent planter le système construit parce qu’il n’a été déployé que quatre semaines plus tard. « Il faut juste le tester », est probablement tout en haut avec « qu’est-ce qui pourrait mal tourner? » dans les déclarations qui précèdent la catastrophe.
Ne prenez pas de raccourci
Ceci est étroitement lié à la pourriture du code. Si le travail n’est pas terminé dans le sprint, je ne le reprends pas dans le sprint suivant comme si rien n’avait changé. Je prends toutes les tâches (qui ne sont pas Done) et les ramène à « à faire » (To Do). Lorsque je reprends le travail, je valide à nouveau tout le travail. Non seulement le « code pourrit », mais vous avez peut-être appris quelque chose de nouveau, avez une nouvelle approche, quelqu’un d’autre a fait le travail. En revenant au tout début, vous vous assurez que rien n’a été manqué et que la qualité reste élevée.
Le tout s’équilibre
Cela entre en jeu à la fois avec un travail qui est « presque terminé » et un travail qui est « ouh la la ! C’est beaucoup plus gros que ce que nous pensions ». Vous allez reprendre un travail qui a été entrepris dans un sprint précédent et qui était à 1 point d’effort de finir, et vous allez également prendre un travail qui finira par nécessiter trois fois plus de travail que prévu, et à long terme, le tout s’équilibre. La loi des grands nombres nous dit essentiellement que, au fil du temps, le nombre d’éléments surestimés s’équilibrera avec le nombre de sous-estimés.
Ne le faites pas
Si cela n’a pas été fini dans le sprint, profitez-en pour examiner le travail à nouveau. Commencez par les critères d’acceptation. Sont-ils trop vagues ? Peut-on y répondre par oui ou non ? Regardez au-delà de cet élément de l’arriéré pour avoir une vue d’ensemble. L’équipe prend-elle trop de travail, cet élément dépendait-il d’un autre élément, y a-t-il une difficulté avec la définition de Done ?
Enfin, profitez-en pour poser la question suivante
Devrions-nous encore faire ce travail ?
Chaque sprint est une opportunité d’inspection et d’adaptation. Une partie consiste à examiner tout ce qui se trouve dans l’arriéré de produit et à vous demander si cela soutient toujours l’objectif du produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !
Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
Livre référence sur Amazon
Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?
Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?
Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.
L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.
Qu’est-ce qu’un Story Point ?
Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.
Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.
Relisez ce billet sur « pourquoi Fibonacci ? »
Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.
Comment les story points sont-ils utilisés dans les sprints ?
Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.
L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).
Pourquoi les story points peuvent-ils être sujets à controverse ?
Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.
Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.
La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.
Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.
Trouvez un équilibre
Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.
Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.
Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».
Guide téléchargeable gratuitement
La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).
La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.
Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.
Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.
Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :
Les événements/cérémonies : 31 %
Les rôles : 31 %
Les livrables/artefacts : 17 %
Le timeboxingde 1 à 4 semaines : 20%
Cela concorde avec ce que j’ai observé.
Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.
Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.
Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.
La propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.
Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.
Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.
Et c’est pourquoi « Scrumbut» (Scrum mais…) est la valeur par défaut, pas l’exception.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.
Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.
Scrumbut – L’équipe contourne le problème plutôt que le résoudre.
ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.
Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.
Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)
Exemples de ScrumBut
« (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
« (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
« (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
« (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »
partagez ce billet avec vos amis, collègues et relations professionnelles
Certaines startup décident de ne pas construire de MVP et d’attendre que le produit soit complet et mature avant de demander à des clients potentiels de l’essayer et fournir des retours. Vous voudrez peut-être aussi envisager cette approche…
A minimum viable product is not always a startup’s most valuable player de Srikrishnan Ganesan
Une pratique courante de lancement de startup consiste à créer d’abord un produit minimum viable (MVP). Largement considéré comme la meilleure première étape pour prouver un produit, un MVP permet à une startup de commercialiser rapidement une version initiale du produit et de solliciter au plus tôt les commentaires des clients pour l’améliorer avant de lancer le produit. Avec un MVP, une startup peut se concentrer sur la unique selling proposition du produit, la proposition de valeur qui rend le produit unique, et construire autour de celle-ci.
Rocketlane a pris un chemin différent. Nous n’avons pas construit de MVP, mais nous avons attendu que le produit soit complet et mature avant de nous engager avec des clients potentiels et de leur demander de l’essayer et de fournir des retours. Vous voudrez peut-être aussi envisager cette approche lorsque vous évaluerez diverses façons de mettre votre produit sur le marché. Dans cet article, nous allons vous expliquer pourquoi.
Pourquoi casser les codes ?
Brisez les codes !
Un MVP fonctionne bien lors de la création d’un produit entièrement nouveau pour un nouvel espace et pour des solutions ponctuelles simples pour les petits clients. Cependant, si un produit doit remplacer des produits horizontaux matures par des solutions spécialement conçues, le produit ne réussira pas en commençant en tant que MVP, d’autant plus si le produit cherche à unifier, en remplaçant un ensemble d’outils horizontaux cloisonnés.
Les principaux piliers de notre histoire de produit sont ses capacités de « tout-en-un » et « d’unification », rassemblant les tâches, les rapports de projet, les notes de réunion, la collaboration de documents en direct et les flux de travail dans une expérience étroitement couplée.
Nous devions intégrer tous ces composants dans notre toute première version de produit et livrer un produit avec une gamme significative de fonctionnalités dès le premier jour. Pour gagner l’adhésion, un produit qui promet une expérience tout-en-un doit faire au moins 80% de ce que fait chacune des solutions horizontales. Le produit doit d’abord avoir toutes ses fonctionnalités de base en place, puis ajouter une couche d’innovation au-dessus.
Distractions et détours
Si vous créez un produit tout-en-un remplaçant plusieurs outils établis et cloisonnés, ce n’est pas non plus une bonne idée de développer et de lancer chaque module séquentiellement en tant que MVP. Si vous donnez un module ou une partie de votre solution à vos clients potentiels pour qu’ils la testent, ils vous fourniront des retours pour améliorer cette partie, ce qui pourrait vous faire perdre de vue votre solution complète.
Supposons que vous alliez plus loin et que vous lanciez une partie de votre produit en tant que MVP, alors l’ensemble du marché pourrait fournir des commentaires similaires et vous faire perdre encore plus de concentration sur votre vision plus aboutie. Vous lanceriez également un MVP qui n’est probablement pas encore au niveau en le comparant fonctionnalité par fonctionnalité avec l’une des solutions établies et cloisonnées que vous souhaitez remplacer, ce qui pourrait entraîner des critiques plus mitigées que vous ne le recevriez autrement si vous aviez attendu pour livrer votre vision complète.
Ne laissez pas un client vous entraîner dans la spirale d’une vision qui lui est propre.
Un autre risque à lancer ou engager des clients potentiels avec un module MVP de votre produit est de suivre LEUR vision de ce module.
Il pourrait finir par ressembler à d’autres produits déjà sur le marché, car ils vont comparer chaque module MVP à d’autres solutions cloisonnées qu’ils utilisent ou connaissent déjà.
Il est préférable d’allouer du temps et des ressources à l’analyse des retours des clients sur des modules et des fonctionnalités spécifiques après avoir livré la vision complète et votre différenciation.
Construire dans les délais lors de la création d’un produit
Une autre raison d’impliquer les clients potentiels tard dans la phase de développement est que les clients jugent en fonction de l’agilité et de la vitesse de production. Lors de la construction des fondations d’un produit, les clients ne percevraient peut-être pas de progrès mensuels significatifs. Plutôt que d’impliquer les clients potentiels dans les premières étapes et risquer la désillusion, il est préférable d’attendre les derniers mois avant le lancement.
Une fois que vous avez un bon produit qui est à 80% de ses fonctionnalités, il ne devrait pas être difficile d’engager des clients potentiels à l’essayer pour quelques équipes et cas d’usage, puis à itérer rapidement avec eux pour atteindre l’adéquation produit / marché cible.
La présentation d’un nouveau produit presque fini aux clients potentiels garantit également qu’ils n’ont pas besoin d’imaginer ce qu’il sera à l’avenir. Ils le voient déjà fonctionner avec succès en fonction de votre vision et peuvent mieux comprendre cette valeur.
Idéalement, les clients potentiels verraient également qu’il n’y a pas d’autre produit équivalent sur le marché ni ailleurs. Lorsqu’ils utilisent le produit en fonction de votre vision complète, ils doivent également imaginer comment cela pourrait les aider.
Impliquer des clients potentiels tard dans la phase de développement inclut le risque de construire trop sans le valider. Le risque augmente avec l’ampleur et la complexité du produit. Même si vous avez de l’expérience dans la création de produits et que vous connaissez la direction, les demandes des clients et ce dont ils peuvent et ne peuvent pas se passer, il est préférable d’engager un panel d’examinateurs, pas nécessairement des clients potentiels, qui sont intéressés par votre vision. Dès la phase de conception, vous pouvez leur montrer des maquettes de ce que sera votre produit complet. De cette façon, vous aurez un flux de retours sur les démonstrations de maquettes même pendant la construction du produit, ce qui vous aidera à réduire les risques.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Vendre la vision
Vous devrez peut-être éduquer les investisseurs et les employés sur votre approche de produit mature. Les deux groupes peuvent être plus familiers de l’approche MVP et peuvent se demander pourquoi attendre la fin de la phase de développement pour engager des clients potentiels. Vous pouvez manager cela avec des réunions régulières où vous présentez les progrès et répondez aux questions. Vous pouvez également distribuer une note de service écrite aux investisseurs et employés, ce qui serait un bon exercice pour cristalliser votre pensée et pour les deux groupes d’avoir un document de référence.
Un produit mature est le produit le plus viable
Il y a plus d’une façon de construire un produit, en particulier pour les catégories horizontales et compétitives. Au lieu de créer un MVP, vous voudrez peut-être créer un produit avec plus de maturité et d’étendue avec quelques expériences innovantes clés qui servent de promesse différenciante (unique selling proposition) et illustrent pourquoi votre produit est le meilleur pour des cas d’utilisation spécifiques.
Si vous engagez les clients potentiels lorsque le produit semble mature, ils comprendront pourquoi ils devraient s’aligner sur votre vision et vous ne sacrifierez pas la différenciation que vous apportez sur le marché.
partagez ce billet avec vos amis, collègues et relations professionnelles
Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
DantotsuPM.com 