Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.
J’ai remarqué quelque chose à ce sujet, cependant.
La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.
Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.
Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.
J’ai eu beaucoup de succès en répondant quelque chose comme ceci
Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?
Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.
Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.
PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
À 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
J’espère vous rencontrer (virtuellement) nombreuses et nombreux 🏝⛵️⚓️🌊🌬pour partager ce retour d’expérience !
Rétrospective Agile sur un programme Agile de digitalisation du parcours support client le mardi 28 février à 14h30 avec mon partenaire Planisware.
Nous y aborderons de nombreux aspects de ce programme à travers une rétrospective Agile
L’équipe
La vision
Les freins
Les accélérateurs
Les obstacles
Le bilan actuel
Cela ne m’étonnerait pas que vous rencontriez bon nombre de ces aspects si vous managez un programme Agile dans une grande organisation et même dans une plus petite…
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.
Le Thème retenu pour cette première édition est :《Ensemble, prenons un peu de recul sur l’état de l’Agilité en 2023.》
PIAF 2023, c’est quoi ?
C’est une journée de conférences Agile en distanciel avec des conférences plénières en ouverture et clôture et 3 à 6 sessions en parallèle pour permettre de partager entre 15 et 30 sessions au total.
De plus, toutes les conférences seront enregistrées et diffusées pendant l’année 2023.
Que va t-on partager ?
Que peut-on dire des méthodes, des référentiels, des outils, des pratiques Agile ?
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
La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.
Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.
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 