Les meilleures pratiques du management de projet, programme et portefeuille de projets, partage d’expériences, questions/réponses sur les thèmes de ce domaine qui vous intéresse.
Ce blog est également ouvert aux discussions sur le leadership, l’innovation, les petites idées qui permettent de se faciliter la vie professionnelle et de progresser.
Ci-dessus, un extrait du contenu du tout premier billet, le 26 Juin 2009 !
Le blog DantotsuPM est né de mon envie de partager (dans la continuité de la création du PMI® France-Sud dans les années 2000).
Pourquoi ce nom « DantotsuPM » ?
Comme beaucoup d’entre vous qui suivez mes publications, je cherche en permanence à améliorer les multiples compétences qui permettent de progresser dans ma vie et mes pratiques.
C’est d’ailleurs de là que vient le nom du blog car le mot Dantotsuque j’ai croisé lors de voyages professionnels au pays du soleil levant signifie en Japonais « rechercher en permanence le meilleur du meilleur ».
J’ai accolé PM à Dantotsu pour Project Management, ma passion : DantotsuPM était né !
Je sélectionne, traduit en français et publie sur ce blog des billets liés au management de projets, programmes, Project Management Office (PMO) et Portfeuilles de projets (PPM), aux soft skills, à l’agilité, à l’analyse des besoins business et au leadership.
N’hésitez pas à réagir aux billets avec vos commentaires.
Contactez-moi sur LinkedIn pour publier vos propres articles.
Si votre société souhaite accroitre sa visibilité auprès des managers de projets et de leurs organisations, devenez sponsor-partenaire du blog DantotsuPM.
Il y a déjà plus de 4000 billets en ligne et j’en publie un nouveau chaque jour…
Je vous invite donc à venir y piocher à votre rythme et selon vos besoins.
Visitez également l’espace ressources gratuitesqui contient de nombreux pointeurs vers des documents utiles aux managers de projets.
J’espère que vous apprécierez d’utiliser les catégories qui regroupent les billets autour de grands thèmes ainsi que les mots clés qui rendront vos recherches plus faciles (dans la colonne de droite).
Voilà, je vous souhaite de belles lectures et de riches échanges et contributions à notre communauté de passionné.e.s du management de projets.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pour qu’une approche Agile, itérative et adaptative, fonctionne pour votre projet, vous devez avoir le bon état d’esprit et l’insuffler dans toute votre organisation.
L’adoption réussie des méthodologies agiles nécessite d’avoir le bon état d’esprit.
Pour que cette approche itérative et adaptative marche, vous devez adopter les éléments et caractéristiques suivants.
#1 – Rapidité et expérience.
Agile produit des résultats rapidement, mais cette vitesse a un coût. Vous avez besoin de personnes expérimentées et dédiées dans l’équipe pour produire des résultats de qualité et vous avez besoin d’une chaine de management impliquée dans l’effort, afin qu’elle sache ce qu’elle obtient. N’essayez pas de demander à des personnes moins expérimentées de produire des livrables intermédiaires, qui sont ensuite examinés par des personnes plus expérimentées. Si vous faites cela, les personnes expérimentées peuvent trouver des lacunes dans les livrables et demander des modifications. Pour que l’agilité fonctionne, les livrables et les décisions doivent être « à l’épreuve du veto ». C’est-à-dire qu’ils ne peuvent pas être annulés par un responsable d’équipe ou un manager qui n’aime pas le résultat. Cela démoralise l’équipe et sacrifie la vitesse que l’agilité est censée générer.
#2 – Un état d’esprit de « permettre l’apprentissage ».
L’un des bénéfices de l’agilité est qu’il permet aux parties prenantes et aux membres de l’équipe d’apprendre. L’utilisation des livrables inspire l’apprentissage et l’amélioration continue des produits du projet. Cela signifie que les parties prenantes doivent être prêtes à ce que les produits soient retravaillés après l’installation. De plus, cet apprentissage déplace souvent les priorités de la production de nouveaux livrables vers la refonte des précédents. Dans l’ensemble, cette volatilité dans ce sur quoi l’équipe travaille est productive. L’inconvénient est que les parties prenantes désireuses d’utiliser de nouvelles fonctionnalités pourraient être déçues. Pour soutenir l’état d’esprit de l’organisation apprenante, assurez-vous de communiquer et de rassurer les parties prenantes.
#3 – Encourager de petites améliorations fréquentes.
Agile produit rapidement les livrables les plus importants pour améliorer l’entreprise. Cette livraison rapide de valeur peut créer des attentes selon lesquelles les améliorations de l’entreprise se poursuivront à ce même rythme. Oui, l’amélioration se poursuivra, mais pas au même rythme qu’au début du projet. Les résultats produits par l’agilité sont généralement des améliorations progressives. Il est rare que l’agilité produise de grands sauts quantiques. Assurez-vous que les parties prenantes comprennent que les améliorations seront mineures et que des changements se produiront souvent au fur et à mesure que le projet se poursuit.
#4 – Confiance et responsabilisation.
Pour qu’une équipe agile prospère, les parties prenantes, la direction, même les utilisateurs finaux, doivent faire confiance à l’équipe. L’équipe doit avoir la permission de décider comment atteindre les objectifs business. Cela inclut la prise de décisions sur l’ajustement des processus métier. Si la confiance n’est pas là, la valeur de l’agilité diminue. La vitesse diminue et les membres de l’équipe seront frustrés.
#5 – Simplicité.
Les méthodologies agiles privilégient la simplicité à la complexité et à la documentation excessive. La simplicité s’applique aux processus, à la communication et aux livrables. Les parties prenantes doivent renoncer à la bureaucratie et à la documentation qu’elles ont reçues dans le passé. L’accent est plutôt mis sur la livraison de solutions fonctionnelles. La documentation est développée à partir d’un exercice d’observation de la façon dont les utilisateurs finaux utilisent ces solutions fonctionnelles.
Avez-vous d’autres suggestions à ajouter pour un bel état d’esprit agile ? Partagez-les avec nous.
Pour en savoir plus sur l’agilité, consultez la formation de Doug RoeAgile Foundations.
partagez ce billet avec vos amis, collègues et relations professionnelles
La session d’affinement de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit et des priorités.
La session d’affinement de l’arriéré de produit (Product Backlog Refinement) n’est pas un événement Scrum officiel, mais c’est une activité cruciale qui aide les équipes Scrum à parvenir à une compréhension commune des éléments de l’arriéré de produit en préparation à la planification du sprint. Les équipes qui adoptent l’amélioration de l’arriéré de produit comme pratique complémentaire ont tendance à avoir des événements de planification de sprint plus fluides. Le nombre de sessions de raffinement au sein d’un sprint dépend de divers facteurs tels que l’état de l’arriéré de produit, la maturité du produit, la disponibilité et l’expérience de l’équipe Scrum.
Il y a de nombreuses de façons de faciliter une session d’affinement de l’arriéré de produit, mais je présente ici certaines des activités que j’attendrais d’une équipe Scrum dans l’une de ces sessions. Celles-ci ne sont pas présentées dans un ordre particulier.
Ventiler les éléments de l’arriéré de produit (Product Backlog Items / PBI)
Dans la session d’affinement de l’arriéré de produit, l’équipe Scrum doit chercher à décomposer les PBI jusqu’à ce qu’ils soient suffisamment petits pour tenir dans le sprint.
La définition de terminé (done) doit être utilisée comme guide pour discuter du travail à accomplir pour chaque PBI du sprint.
Il y a de nombreuses techniques qui peuvent être utilisées pour décomposer les PBI, mais je préfère le découpage vertical des PBI, car l’équipe Scrum a une plus grande probabilité de fournir un incrément utilisable à partir d’un PBI, lorsque le PBI est découpé verticalement.
Estimer les PBI
Les équipes Scrum qui pratiquent l’estimation en tant que pratique complémentaire doivent fournir une prévision de l’effort requis pour fournir des PBI en utilisant la définition de terminé (done) pour le produit comme guide.
Pour ces équipes, l’estimation des PBI aide l’équipe Scrum à sélectionner des éléments de l’arriéré de produit jusqu’à la pleine capacité des développeurs. Si des estimations ont déjà été fournies pour les PBI, l’animateur de la session d’affinement de l’arriéré de produit doit reconfirmer que chaque développeur reste à l’aise avec l’estimation qui a été précédemment enregistrée sur le PBI.
Les critères d’acceptation devraient être revus pour en vérifier la clarté et l’exhaustivité lors de la séance d’amélioration de l’arriéré de produit. L’animateur doit inviter les participants à la session d’amélioration de l’arriéré de produit à poser des questions et à demander des éclaircissements si nécessaire. Il y a des cas où l’équipe n’arrive pas à s’entendre sur les critères d’acceptation, en particulier pour un PBI complexe ; L’équipe Scrum pourrait alors trouver utile de réexaminer le « pourquoi ? ». Le Product Owner doit être en mesure d’exprimer clairement la valeur du PBI ; D’après mon expérience, une fois que la valeur est transparente pour tous les participants, les développeurs peuvent s’autogérer pour déterminer les détails de ce qui doit être fait et comment le travail serait accompli.
Discutez des dépendances et des blocages
Attention aux dépendances croisées qui s’emmêlent et créent des nœuds inextricables.
Cela n’aurait aucun sens d’intégrer une histoire utilisateur / story avec des dépendances et des blocages dans un sprint, car cette story ne sera probablement pas terminée dans le sprint. L’équipe Scrum doit discuter de toutes les dépendances et de tous les bloqueurs pour s’assurer que tout le monde a une compréhension commune des dépendances et des blocages ; L’équipe Scrum doit mettre en place un plan pour résoudre ces dépendances et ces blocages. Le cas échéant, ces dépendances et blocages doivent être représentés dans l’arriéré de produit et attribuées aux personnes qui travaillent à les supprimer. À titre indicatif, l’équipe Scrum ne doit PAS présenter d’éléments avec des dépendances et des blocages non résolus pour la planification du sprint, sauf s’il existe un plan pour résoudre ces obstacles au sein du sprint.
Priorisez l’arriéré de produit
Le Product Owner est responsable de la priorisation de l’arriéré de produit et il existe un certain nombre de raisons qui peuvent être prises en compte telles que la Valeur, la Priorité, la Cohérence Business, la Cohérence Technique, etc. Le Product Owner doit prendre l’habitude de garder l’arriéré produit ordonné à tout moment et une session telle que la session d’affinement de l’arriéré de produit est un bon moment pour examiner et mettre à jour l’ordre des PBI dans l’arriéré de produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Comme indiqué dans l’introduction, la session d’amélioration de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit qu’il contient et des éléments de l’arriéré de produit qui ont émergé pour atteindre l’objectif produit.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si certains pensent que « Agile » ou les idées propagées par les praticiens Agile ne devraient jamais être critiquées, Michael Küsters explique ici pourquoi ceci est totalement l’inverse de ce qu’il convient de faire.
Certaines personnes pensent que « Agile » ou les idées propagées par les praticiens Agile ne devraient pas être critiquées. Elles considèrent ces critiques comme un manque de compréhension de l’agilité ou un manque de respect pour les agilistes. Je ne suis pas d’accord. Approfondissons cette question et explorons comment la critique se croise avec la science, le raisonnement et la croissance pour donner vie aux principes Agile.
Agile n’est pas une religion
Il est tentant de défendre Agile contre les critiques. Mais cela transforme l’approche pragmatique et empirique en fanatisme religieux. Nous ne rédigeons pas de Sainte Écriture ni de prophéties sur une vérité et des preuves observables.
L’agilité n’est pas dogmatique.
Elle se nourrit de l’ouverture, de l’interaction et d’une diffusion objective d’idées plausibles. La traiter comme un dogme inattaquable transforme cette façon dynamique de faire la meilleure chose possible en une pratique sectaire.
Le culte du dogme
Essayer de défendre farouchement « Agile » contre la critique crée un paradoxe : Agile, de par sa conception, se nourrit de l’ouverture, de l’interaction et de la recherche de meilleures solutions.
En faire un dogme étouffe le progrès et la croissance. Le dogmatisme, qu’il soit religieux ou idéologique, résiste à la remise en question et à la dissidence. Agile, cependant, accueille les deux.
Agile, c’est le dynamisme
« Agile » n’est pas gravé dans le marbre : c’est vivant, évolutif. Ses valeurs fondamentales soulignent la nécessité d’une réflexion et d’une adaptation continues.
Les praticiens agiles doivent adopter la critique comme catalyseur de croissance.
Science et Agile : Des âmes sœurs
« Agile » a été conçu à partir de la frustration face aux méthodologies de gestion de projet lourdes qui ont conduit à plus d’échecs que de succès. Ses fondateurs recherchaient une alternative qui valorise l’interaction, la collaboration, la flexibilité et la réactivité. C’est le contraire des dogmes religieux : Agile n’exige pas une foi inébranlable. Au lieu de cela, Agile encourage l’expérimentation empirique et l’adaptation.
Une place pour le scepticisme
Le progrès scientifique repose sur le scepticisme, la curiosité et la volonté de remettre en question les théories dominantes. Agile partage cet état d’esprit. Lorsque les praticiens remettent en question les hypothèses, expérimentent et apprennent, ils incarnent l’état d’esprit scientifique. L’approche empirique d’Agile nous encourage à examiner les pratiques, à écarter ce qui ne fonctionne pas et à affiner ce qui fonctionne. C’est une dérogation au dogme, où l’adhésion l’emporte sur les preuves.
Bienvenue à la critique valide
Une idée ou une pratique qui ne résiste pas à la critique est intrinsèquement imparfaite. Un examen rigoureux affûte nos outils. Lorsque la critique surgit, nous devons soit démystifier la critique avec des preuves, soit adapter notre approche à la critique. La résilience de l’agilité réside dans sa capacité à évoluer sur la base de retours valides. Cela ne correspond pas au rejet catégorique des idées inconfortables.
Conditions de laboratoire
Imaginez Agile comme un laboratoire : Un espace où les hypothèses sont testées, les résultats analysés et les théories affinées. Tout comme les scientifiques révisent leurs modèles en fonction des retours et des preuves empiriques, les praticiens agiles doivent faire de même. Un état d’esprit de laboratoire nous encourage à accepter la critique, à apprendre de nos échecs et à itérer vers l’excellence.
Pas de vaches sacrées
Soyez factuel, examinez les preuves tangibles.
Tant que nous nous en tiendrons à nos hypothèses, quelles que soient les preuves, nous aurons du mal à produire les meilleurs résultats possibles.
Faire preuve de souplesse
L’agilité repose sur la flexibilité, l’adaptabilité et l’apprentissage. La rigidité étouffe la croissance. En restant ouverts au changement et en remettant en question les normes établies, nous créons un environnement propice à l’innovation.
Lâcher prise sur les idées
Métaphoriquement parlant, les agilistes doivent manier une arme pour abattre les vaches sacrées, ces croyances ou pratiques incontestées qui se dressent entre nous et l’excellence. Cela nous aide à évoluer, à apprendre de nos erreurs et à affiner nos approches.
Examen minutieux et validité des réflexions
Les idées doivent faire l’objet d’un examen constant. Un examen rigoureux affine notre compréhension et garantit que seuls les concepts les plus fiables sont propagés. Les réactions émotionnelles ou l’arrêt de la réflexion entravent les progrès.
Le creuset de l’examen minutieux
L’agilité s’épanouit lorsqu’elle est soumise à un examen rigoureux. Tout comme les métaux sont raffinés dans un creuset, les idées agiles sont affinées par l’examen. Lorsque nous remettons en question des hypothèses, nous affinons notre compréhension et écartons ce qui ne tient pas la route. L’examen minutieux n’est pas une menace ; C’est un catalyseur de croissance.
Résilience émotionnelle
Les émotions ont leur place, mais elles sont souvent de mauvaises conseillères lorsqu’il s’agit de faire face aux critiques. Il est naturel de répondre à la critique par une réaction émotionnelle qui obscurcit notre jugement. La raison, la logique et les preuves sont des guides beaucoup plus fiables lorsque les émotions s’enflamment.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Critique constructive
« Agile » bénéficie d’une critique constructive. Plutôt que d’aborder la dissidence avec négativité, nous pouvons la voir comme un moyen de favoriser la croissance, d’affiner nos pratiques et d’élever notre performance.
Évitez le jargon à la mode
Les arguments « agiles » se réduisent souvent en une liste de mots à la mode, où les slogans remplacent la substance. Évitez le jargon et concentrez-vous sur le fond : Montrez-moi la « meilleure façon » avec clarté, preuves à l’appui. Les mots à la mode n’impressionneront pas ceux qui cherchent des réponses sérieuses.
Soyez positif
La critique n’est pas une attaque contre laquelle il faut se défendre. Au lieu de couper court à la question, ouvrons une conversation. En remettant en question les hypothèses, nous contribuons à la croissance. Mais de la même manière, le simple fait de s’en prendre à quelque chose étouffe le progrès. Cela ne conduira pas à une amélioration.
Soyez raisonnable
Les attaques ad hominem et la manipulation psychologique n’ont pas leur place dans un environnement collaboratif. Au lieu de cela, engageons-nous dans un raisonnement réfléchi. Lorsque vous n’êtes pas d’accord, présentez votre cas de manière logique. « Agile » se nourrit du respect des points de vue divergents, percevant les questions inconfortables comme des invitations à apprendre.
L’agilité n’est pas un monument figé ; C’est un jardin dynamique.
Arrosez-le de critiques constructives, élaguez les branches mortes et regardez-le s’épanouir. Cultivons la croissance, l’apprentissage et un discours respectueux.
partagez ce billet avec vos amis, collègues et relations professionnelles
La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.
Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.
Il s’agit notamment de :
Estimation et dimensionnement d’une histoire de Technical Spike
Limiter dans le temps (Timeboxing) un Technical Spike.
Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.
Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.
Je suggérerais au Product Owner / Business Analyst en collaboration avec unmembre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.
L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevésuffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’agilité organisationnelle implique que l’ensemble de l’organisation soit un réseau interdépendant d’équipes autogérées. De telles organisations nécessitent un type de leadership différent aux différents niveaux de l’organisation.
Scrum et d’autres cadres d’agilité se basent sur des équipes auto-organisées / autogérées.
L’agilité organisationnelle implique que l’ensemble de l’organisation soit un réseau interdépendant d’équipes autogérées. De telles organisations nécessitent un type de leadership différent aux différents niveaux de l’organisation.
« Les individus et les interactions plutôt que les processus et les outils »
Ma phrase préférée dans le Manifeste Agile est « Les individus et les interactions plutôt que les processus et les outils ». Cela implique que les leaders doivent créer un environnement permettant aux équipes de collaborer au sein des équipes et entre les équipes.
Dans cet article, je décris 5 caractéristiques des leaders qui réussissent à créer un environnement propice à l’épanouissement des équipes agiles.
#1 – Des leaders qui responsabilisent les équipes.
Ces leaders démontrent aux équipes qu’elles peuvent et doivent prendre des décisions qui affectent leurs équipes. Ils veillent à ce que leurs équipes possèdent les compétences appropriées et disposent en permanence d’informations qui leur permettent de s’autogérer.
Les équipes autonomes ont le pouvoir de prendre des décisions qui affectent leur façon de travailler et le produit qu’elles créent. Elles ont également la permission d’expérimenter et d’échouer (d’apprendre).
#2 – Des leaders qui font confiance à leurs équipes.
La confiance est une condition fondamentale pour que l’agilité prospère. Les leaders qui ont peu confiance en l’équipe ont tendance à micro-manager leur équipe, ce qui entraîne la frustration des personnes qui travaillent dans ces équipes. Un processus de gouvernance trop restrictif pourrait être le signe d’un manque de confiance dans le fait que l’équipe fera ce qu’il faut. Les contrôles sont une bonne chose, mais dans les situations où ils entravent la création de valeur, les leaders doivent se poser la question de la confiance.
#3 – Les leaders qui capturent, suivent et améliorent les indicateurs de valeur.
Le type de leaders qui soutiennent l’agilité s’intéresse à des indicateurs tels que :
Contrairement aux leaders qui s’intéresseraient qu’à des indicateurs tels que la quantité de travail effectuée par l’équipe, l’utilisation des ressources et nombreux autres indicateurs qui ne correspondent pas à l’agilité.
Les leaders qui se concentrent sur leur équipe et travaillent avec elle pour améliorer les indicateurs de valeur constituent des équipes et des organisations solides qui sont bien positionnées pour apporter de la valeur à leurs clients.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
#4 – Des leaders qui se concentrent sur les résultats plutôt que sur les livrables.
Faire rêver ces équipes plutôt que les surveiller.
Nous avons souffert de leaders qui se concentraient trop sur les résultats tels que le nombre de lignes de code produites, les articles de communication écrits, les billets publiés sur les médias sociaux, etc. car ceux-ci sont faciles à capturer.
Nous coachons ces leaders pour qu’ils aident leurs équipes à définir des résultats, ce n’est qu’alors que ces leaders auront plus de chances de constituer des équipes autogérées. Ces leaders co-créent des objectifs avec leurs équipes et les aident à atteindre ces objectifs. Il peut s’agir, par exemple, d’améliorer le Net Promoter Score de 20 % ou d’améliorer la fidélisation des clients de 30 % d’une année sur l’autre. Une fois les objectifs fixés, les leaders doivent permettre à leurs équipes de trouver des idées qui pourraient les aider à atteindre ces objectifs et à mesurer leurs progrès.
#5 – Des leaders qui coachent leurs équipes.
Une organisation agile est une organisation dans laquelle chaque leader est un coach, c’est-à-dire qu’il aide les membres de son équipe à être de meilleures versions d’eux-mêmes. Ces leaders sont des cheerleaders pour leur équipe, ils n’entravent pas le travail et ils déploient de l’autonomie, de la maîtrise et de la détermination pour motiver leur équipe. Ces leaders délèguent autant que possible à leur équipe et « révèlent plutôt que résolvent » lorsque leurs équipes sont confrontées à des défis.
Notre travail a vu beaucoup trop d’organisations commencer leur parcours agile en formant leurs équipes alors que les leaders sont généralement trop occupés pour se former. Les leaders ne peuvent pas mener des efforts de changement dont ils ne font pas eux-mêmes partie.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous vous retrouvez souvent à devoir repousser des histoires utilisateur d’un sprint au suivant, peut-être n’utilisez-vous pas les bonnes métriques ?
Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman
Je continue à travailler avec des gens qui ont du mal avec leur approche agile. Ils me disent que leur estimation relative ne fonctionne pas pour eux. Ils continuent de repousser des items, d’un sprint à l’autre. Ils ont repoussé certains items pendant six mois ou plus. Les gens se sentent démoralisés. Et les Scrum Masters ou les managers de projet agiles n’ont aucune idée de la façon de remédier à la situation.
C’est alors que je leur recommande d’utiliser les métriques de flux au lieu d’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles n’aident pas.
Les métriques de flux sont l’unique « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces métriques exposent les principes qui sous-tendent l’agilité. Lorsque les équipes mesurent ces 4 métriques, elles peuvent voir leur réalité et décider quoi faire pour créer un meilleur environnement. Et, comme pour la plupart des principes, il y a une petite différence dans la façon dont ils sont importants pour les équipes et les managers.
Tout d’abord, voyons quelles sont les métriques de flux.
4 Métriques de flux
WIP / Work In Progress, Travail en cours : Tout le travail qui est en cours : commencé et pas encore terminé.
Throughput, Débit : Nombre d’items de travail qu’une équipe/responsable peut effectuer par unité de temps.
Cycle Time, Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
Aging, Vieillissement : Depuis combien de temps un travail est en cours.
Bien que les métriques de flux soient indépendantes, elles créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager. Commençons par une équipe.
Interaction entre les métriques de flux
Imaginez une équipe qui termine régulièrement un item de travail chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense qu’il a besoin d’en faire « plus ». Peut-être que quelque chose a changé sur le marché ou que la direction n’est pas satisfaite du rendement de l’équipe. Ou peut-être qu’un concurrent gagne du terrain. Quoi qu’il en soit, l’organisation en veut « plus ».
Une personne bien intentionnée demande à l’équipe de commencer un item de plus cette semaine et de le terminer. Cela augmente le WIP de l’équipe. Cependant, à moins que l’équipe ne change quelque chose dans sa façon de travailler, elle n’augmente pas son débit juste parce qu’elle a commencé un item supplémentaire.
En fait, leur débit a diminué parce qu’ils travaillent sur deux éléments en même temps et qu’ils n’ont terminé aucun d’entre eux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux items de travail plus anciens, ce qui augmente le vieillissement de tous les items.
La demande de travail augmente, tout cela parce que l’équipe n’en a pas terminé « assez ».
C’est une boucle de rétroaction qui se renforce. Au fur et à mesure que l’encours augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des items plus anciens. Tout cela augmente leurs travaux en cours.
Nous tournons en rond, créant un environnement de pire en pire pour l’équipe.
Si vous avez déjà vu une équipe « repousser » des histoires utilisateur d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse ne sont pas utiles, mais la mesure du temps de cycle fonctionne.
La bonne nouvelle, c’est que l’équipe peut intervenir n’importe où dans ce cycle et apporter des améliorations.
Interventions d’équipe
Voici les questions que l’équipe peut poser :
Quelle est la seule et unique chose sur laquelle nous devrions travailler et terminer ? (Commencez par les travaux en cours.)
Quel âge a notre item le plus ancien ? Est-ce qu’il a encore de la valeur ? (Commencez par considérer le vieillissement.)
Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Concentrez-vous sur le temps de cycle.)
Comment pouvons-nous augmenter notre débit ? (Concentrez-vous sur le débit.)
J‘ai tendance à commencer par l’une ou l’autre des deux premières questions, car elles se concentrent sur une chose que l’équipe peut terminer. Lorsque l’équipe réduit son travail en cours à un seul élément, elle doit modifier sa façon de travailler.
Ensuite, plus le WIP est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens éléments est réduit.
C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.
Est-ce que « un » item est toujours le bon nombre pour les travaux en cours ? Non, je recommande à l’équipe de commencer par diviser par deux le nombre de personnes dans l’équipe (pour déterminer le WIP optimal de l’équipe). Si vous avez un nombre impair de personnes, arrondissez en dessous. Donc, si vous avez cinq personnes, utilisez « deux » comme travail en cours maximal.
Mais votre équipe peut commencer par des changements au sein de l’équipe pour réduire le temps de cycle et augmenter le rendement. Vous pouvez commencer n’importe où car c’est une boucle de rétroaction.
Interventions du management
Les managers travaillent différemment. Les métriques ne changent pas, mais les interventions du management sont différentes.
Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne produisent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées de « Pourquoi minimiser le temps de décision de la direction/ Why Minimize Management Decision Time” sont si importantes.
Plus les managers ont de décisions non finalisées (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus l’encours WIP d’un responsable est élevé, plus le temps de cycle est long et plus le débit est faible. Cela signifie que les gens ne savent pas quoi faire et décident par eux-mêmes. Les gens ne peuvent plus attendre une décision du management.
Les managers peuvent poser des questions légèrement différentes :
Dois-je prendre cette décision ou puis-je la déléguer à quelqu’un ou à une autre équipe ? (Cela réduit le WIP.)
Cette décision a-t-elle encore de la valeur ? (Réduire le vieillissement.)
Quelles décisions puis-je prendre aujourd’hui pour m’en débarrasser ? (Réduire le temps de cycle.)
De qui d’autre ai-je besoin pour prendre cette décision et comment pouvons-nous décider aujourd’hui ? (Augmenter le débit.)
Bien que les questions soient un peu différentes, les managers peuvent utiliser la boucle de rétroaction pour créer une boucle qui fonctionne pour eux, et non contre eux.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les métriques de flux peuvent guider de meilleures décisions
Lorsque les équipes et les responsables voient clairement leurs travaux en cours/WIP, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils souhaitent modifier.
Est-il temps de renforcer la collaboration ?
Commencez peut-être par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? »
Les métriques de flux sont importantes car elles permettent aux équipes et aux responsables de voir et de gérer leur façon de travailler.
Utilisez-les pour avoir un aperçu de l’endroit où vous pourriez choisir de modifier votre travail.
Cette lettre d’information aborde les sujets abordés dans les livres :
Une équipe autonome et autogérée s’épanouit lorsque les liens hiérarchiques sont relégués au second plan, ce qui permet aux responsabilités Scrum de guider les méthodes de travail. Bien que les hiérarchies organisationnelles persistent, en particulier lors de la formation des équipes Scrum, il est crucial de discuter des privilèges et de leur impact sur la capacité d’une équipe à s’auto-gérer.
Privilège hiérarchique
Cette forme explicite de privilège survient lorsqu’une équipe Scrum est composée d’employés ayant différents niveaux d’ancienneté. Les cadres supérieurs exercent une influence, prenant parfois des décisions unilatérales qui affectent l’ensemble de l’équipe. Par exemple, un responsable hiérarchique, également développeur au sein de l’équipe Scrum, pourrait choisir d’annuler une rétrospective de Sprint sans consulter les autres membres de l’équipe.
Privilège d’expertise
Accordé aux personnes expérimentées dans le domaine ou les compétences requises. Ce privilège peut conduire à une prise de décision rapide par les développeurs seniors et les responsables techniques, ce qui peut étouffer la contribution des membres moins expérimentés de l’équipe. Bien que des décisions rapides puissent être nécessaires dans certaines situations, il est essentiel d’assurer l’inclusivité.
Privilège culturel
Dans les équipes Scrum géographiquement distribuées, les nuances culturelles peuvent créer une dynamique de privilège. Les membres de l’équipe issus de cultures plus expressives peuvent involontairement dominer les discussions, ignorant les autres moins enclins aux confrontations. La reconnaissance et l’atténuation de ce privilège culturel favorisent un environnement véritablement inclusif et collaboratif.
Ces privilèges conduisent souvent quelques membres de l’équipe à prendre des décisions pour l’ensemble de l’équipe Scrum, s’écartant ainsi de l’essence de l’auto-gestion.
Le Scrum Master étant au service de l’équipe Scrum, ses interventions sont essentielles.
Reconnaître les privilèges au sein de l’équipe : Animez une conversation pour discuter de toutes les formes de privilèges au sein de l’équipe. La sensibilisation est la première étape pour faire prendre conscience aux membres de l’équipe de leurs privilèges et leur impact sur la collaboration et l’auto-gestion.
Discuter des techniques de gestion des privilèges : Aidez l’équipe à explorer les techniques permettant de gérer les privilèges. Les membres de l’équipe peuvent suggérer de créer de l’espace pour les autres et d’être plus conscients de ceux qui ne sont pas dans des positions privilégiées. Des techniques telles que la LiberatingStructure 1-2-4-All offrent des chances égales à chaque membre de l’équipe de participer.
Tenir chacun mutuellement responsable : Établissez ou mettez à jour un accord de travail qui comprend des techniques pour s’assurer que les décisions sont prises avec un minimum de privilèges. Définissez comment n’importe quel membre de l’équipe peut intervenir si cet accord de travail n’est pas respecté.
Pour illustrer l’impact des privilèges, prenons l’exemple d’une expérience récente.
Lors d’une session de planification de sprint avec un nombre limité de membres de l’équipe, le Product Owner, en raison de son rang supérieur, a proposé d’annuler la réunion sans consulter tous les membres de l’équipe. Reconnaissant ce privilège, le Scrum Master est intervenu, ce qui a déclenché une discussion qui a mené à un processus décisionnel plus inclusif.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
La prise en compte de la dynamique des privilèges garantit que les équipes Scrum incarnent les principes d’autonomie, de collaboration et d’auto-gestion, ce qui conduit au développement d’équipes hautement efficaces capables d’apporter de la valeur à leurs parties prenantes.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’UAT continuera-t-elle à être une pratique pertinente pour les équipes agiles et leurs parties prenantes qui cherchent à créer de meilleurs produits plus rapidement ?
Impact of User Acceptance Testing (UAT) phase on Organisation Agility par Sam Adesoga
Le test d’acceptation par l’utilisateur (User Acceptance Testing / UAT) est une pratique de développement de produits très populaire dans les méthodes traditionnelles de développement de produits. Ces méthodologies traditionnelles sont caractérisées par de longues phases de développement et de déploiement du produit dans un environnement UAT, suivies d’une longue période de test dans l’environnement UAT.
La question est de savoir si l’UAT continuera d’être une pratique pertinente pour les équipes agiles et leurs parties prenantes, en partant du principe que les organisations adoptent des méthodes de travail agiles pour être en mesure de créer de meilleurs produits plus rapidement. La phase d’UAT est une pratique qui est souvent mandatée par les cadres supérieurs au sein de l’organisation et parce que la phase d’UAT ne peut pas s’intégrer dans le Sprint (dans le cas des équipes Scrum), ces équipes contournent l’« obstacle » en modifiant la définition de Done pour leur produit afin d’exclure l’UAT. En d’autres termes, l’équipe Scrum a tendance à modifier son livrable de Sprint pour en faire un produit dont le développement est terminé mais qui n’a pas encore été testé par les utilisateurs et/ou les parties prenantes.
Pour le scénario décrit ci-dessus, quelle que soit la vitesse à laquelle l’équipe Scrum travaille pour amener ses éléments de travail à l’état de développement terminé, l’équipe Scrum crée effectivement un lot de travail qui n’est pas délivré en production avant un certain temps. La phase UAT peut durer de 4 semaines à 3 mois ; et nous pensons que la phase UAT ne rend pas service à tous les efforts visant à renforcer les capacités d’agilité de l’organisation.
Les approches agiles tels que Scrum aident les organisations et les équipes produit à gérer la complexité, et les implémentations de ces approches ne doivent pas introduire de complexité supplémentaire.
Voici quelques exemples de complexité supplémentaire introduite par une pratique distincte de l’UAT et question à se poser :
Comment les équipes corrigeront-elles les défauts détectés pendant la phase d’UAT ?
Cela affectera-t-il la capacité de l’équipe à se concentrer sur le travail de sprint ?
Les défauts seront-ils corrigés par une sous-équipe de développeurs ?
Comment les équipes fusionneront-elles l’incrément de la phase UAT et l’incrément des sprints ?
Chez Valuehut, nous aidons nos clients à intégrer toutes les formes de tests au sein du Sprint (y compris les tests d’acceptation par les utilisateurs) ; La promesse de Scrum est d’aider les équipes à fournir des produits utilisables et précieux à leurs utilisateurs le plus rapidement possible et en renforçant les capacités au sein de l’équipe pour effectuer des tests d’acceptation par les utilisateurs dans le cadre du Sprint. L’équipe a alors plus de chances de fournir un produit précieux et disponible à ses utilisateurs / parties prenantes dans chaque sprint.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Il existe 3 modèles et approches associées que nous avons suivis pour aider les équipes Scrum à éliminer la phase d’UAT de leur méthodologie de livraison de produits.
#1 – Environnements de test qui ne représentent pas l’environnement de production.
Les équipes Scrum qui n’ont pas accès à un environnement de test qui est une représentation de l’environnement de production disposent généralement d’un environnement UAT, qui est partagé par de nombreuses équipes. La non-représentativité peut faire référence à la taille et à la capacité de l’environnement ou à un environnement qui n’est pas configuré correctement avec toutes les applications en amont et en aval.
Pour résoudre ces problèmes, l’équipe doit argumenter en permanence pour avoir un environnement qui représente l’environnement de production. Rendre transparentes pour la direction les implications en termes de coûts qui pourraient être des opportunités perdues en raison de délais de livraison allongés.
#2 – Cas de test et scénarios utilisateurs inconnus.
Souvent, les utilisateurs professionnels qui sont censés exécuter le test d’acceptation utilisateur ont créé un ensemble de scénarios et de cas de test qui n’ont pas été partagés avec les développeurs.
Dans ce cas, l’équipe Scrum devrait plaider pour que ces scénarios utilisateur soient partagés avec l’équipe Scrum en s’associant aux utilisateurs professionnels et en utilisant le coût de la reprise pour répondre à ces scénarios.
#3 – Indisponibilité des données de test dans l’environnement de test.
Dans cette situation, l’entreprise n’est généralement pas confortable avec l’idée de charger des données de test représentatives dans les environnements de test pour un certain nombre de raisons, telles qu’un environnement de test inadapté ou un problème de confidentialité des données.
Les développeurs doivent s’efforcer d’anonymiser les données et de créer des jeux de test qui permettent à l’équipe Scrum d’accéder de manière cohérente à des données de test représentatives.
Élimination de phase d’UAT ?
Il convient de noter que l’élimination de la phase d’UAT prend du temps et nécessite que les équipes Produit s’associent aux leaders de l’entreprise sur une longue période de temps, en effectuant de petites expériences à chaque fois jusqu’à ce que la phase d’UAT soit rendue redondante. La seule façon de rendre la phase d’UAT redondante est de rassembler suffisamment de preuves empiriques qu’aucun défaut n’est trouvé dans cette phase d’UAT ; Cela permet d’établir la confiance avec les parties prenantes au fil du temps, et l’équipe Scrum doit fournir aux parties prenantes la preuve des tests exécutés dans chaque sprint.
La capacité d’agilité organisationnelle aide les organisations à être efficaces (en créant les bons produits, par exemple un produit que les clients aiment utiliser) et efficientes (en construisant les bons produits, par exemple en réduisant les délais de mise sur le marché) ; Par conséquent :
Les organisations qui veulent être compétitives dans un monde complexe doivent repenser des pratiques telles que la phase d’acceptation par les utilisateurs, qui ralentissent le temps total nécessaire pour mettre de nouveaux produits ou fonctionnalités entre les mains de leurs clients.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?
La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.
Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.
En 1961, Little a énoncé son théorème :
Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.
Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.
De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).
Cette formule est souvent exprimée ainsi :
WIP = T x LT
ou encore
LT = WIP / T
Toute augmentation des travaux en cours WIP augmente automatiquement les délais.
Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.
De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
La loi de Little dans le cadre du management de projet
Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.
Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.
Prenez un exemple :
Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.
Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.
Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.
Bien sûr, tout n’est pas si linéaire…
En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…
Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.
Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.
Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.
Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.
Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.
Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, leswitching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.
En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.
Et pour le management de Portefeuille de Projets (PPM) ?
La loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.
Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !
Plus spécifiquement sur les projets Agiles
Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.
C’est en Agile en grande partie la responsabilité du Product Owner.
Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !
En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.
En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.
Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?
J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.
Quelle est votre expérience de cette Loi de Little ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Le billet “What does an agile project manager do?” m’a interpelé et j’ai voulu comprendre si il existe réellement des différences majeures entre un(e) manager de projet Agile par rapport à tout(e) autre manager de projet.
Personnellement, je n’en vois aucune et je rejette la vue caricaturale du manager de projet « traditionnel » qui s’enfermerait dans un mode de management de type « commande et contrôle ».
Les responsabilités et compétences listées me semblent s’appliquer à toute et tout manager de projet, que le projet soit mené avec une approche prédictive, adaptative ou hybride. Connaître les principes et approches Agile est un prérequis pour tout(e) manager de projet dans le monde où nous œuvrons.
En matière de gestion de projet, l’émergence des méthodologies agiles a transformé la façon dont les entreprises conceptualisent, planifient et exécutent les projets.
Le manager de projet Agile est crucial pour le succès de toute entreprise Agile, un rôle central chargé de rassembler des éléments distincts pour atteindre les objectifs du projet. Le manager de projet a de nombreuses responsabilités, privilégiant l’adaptabilité, la collaboration et s’assurant que les projets répondent aux attentes. Un manager de projet agile est un poste complexe et polyvalent qui nécessite diverses compétences et attributs.
Ce rôle complexe n’est pas toujours facile à comprendre. Pourtant, le succès de l’entreprise repose souvent sur le fait que le manager de projet agile favorise la collaboration entre les services et donne aux équipes les moyens de comprendre, de communiquer et de renforcer le leadership. Ainsi, lorsque tout le monde comprend le rôle du manager, les projets ont plus de chances de réussir et les méthodologies agiles peuvent être déployées efficacement.
Qu’est-ce que le management de projet agile ?
Le management de projet agile est une approche dynamique et itérative du management de projet qui favorise la flexibilité, la collaboration et l’orientation client. Contrairement aux méthodologies traditionnelles, qui suivent souvent un chemin plus rigide et linéaire, l’approche Agile embrasse le changement et donne la priorité à la création de valeur incrémentielle aux parties prenantes pour une livraison précoce et continue.
En favorisant la planification adaptative et le travail d’équipe interfonctionnelle, les méthodes agiles permettent aux équipes de répondre rapidement à l’évolution des exigences et à la dynamique du marché.
Ces dernières années, la popularité des valeurs agiles a explosé, signalant un changement de paradigme dans le management de projet. Les organisations de tous les secteurs adoptent désormais les méthodes Agiles pour améliorer leur réactivité et augmenter la satisfaction de leurs clients.
Les rôles dans les équipes de projet agiles
Une équipe de projet Agile englobe une gamme de rôles essentiels qui conduisent collectivement les projets à leur terme. Différentes équipes peuvent avoir besoin d’une adaptation des rôles principaux.
Sponsor business, qui est responsable de l’ensemble du projet, du budget et des livrables dans le cadre commercial plus large ; Visionnaire, qui est responsable de la vision et de l’orientation globales.
Coordinateur technique, qui s’assure que la solution est techniquement correcte et répond aux exigences.
Manager d’équipe, responsable des petites zones et de parties détaillées du projet.
Analyste d’affaire, travaillant à identifier les opportunités et les changements dans l’entreprise dans son ensemble qui peuvent avoir une incidence sur le projet.
Développeur de solutions, prend les exigences de l’entreprise et les utilise pour informer la solution.
Solution Tester, responsable des tests de performance à chaque étape.
Les équipes agiles ont souvent des rôles divers et variés adaptés aux objectifs du projet, ce qui favorise l’idée d’adaptabilité. Pourtant, au milieu de ces variations, le rôle central du manager de projet agile reste le même, favorisant la coordination et promouvant les principes agiles.
Qu’est-ce qu’un manager de projet Agile ?
Un manager de projet Agile est un rôle à multiples facettes qui allie leadership de haut niveau et facilitation dans un environnement de projet Agile. Leur objectif principal est de façonner l’environnement de travail en évolution de la solution et de favoriser la collaboration au sein de l’équipe de développement de la solution. Le manager de projet guide les membres de l’équipe sans imposer de plans de projet détaillés au processus de développement. Au lieu de cela, ils utilisent une approche facilitatrice, pilotant le projet sans exercer un style strict de « commandement et de contrôle ».
Le rôle du manager de projet est essentiel pour assurer la réussite du projet, englobant des responsabilités allant de la communication efficace avec les parties prenantes à la supervision de la planification et de l’ordonnancement de haut niveau du projet. De plus, le manager de projet surveille les progrès, gère les risques et les problèmes, et encourage l’autonomisation et la motivation de l’équipe.
Tout au long du cycle de vie du projet, de la fondation au déploiement, le manager de projet reste essentiel au maintien d’une coordination et d’une communication efficaces.
Principales responsabilités d’un manager de projet agile
Les managers de projet agiles assument diverses responsabilités critiques, qui sont différentes des postes de manager de projet traditionnels. Ce rôle doit être flexible et central dans le flux de travail agile. Les responsabilités sont les suivantes :
Orchestrer l’évolution du projet jusqu’à son achèvement.
Promouvoir une communication et une collaboration transparentes au sein de l’équipe agile.
Favoriser un environnement où les membres de l’équipe peuvent s’auto-organiser et prendre des décisions.
Fournir du coaching et de la formation pour faciliter l’adoption d’Agile et l’amélioration continue.
Aligner les objectifs du projet sur les objectifs plus larges de l’organisation.
Faciliter une collaboration et une intégration interfonctionnelles efficaces.
Guider l’équipe de développement dans la création et le suivi d’un plan de livraison.
Suivi de l’avancement du projet et de l’échéancier du projet.
Identifier les obstacles et résoudre les problèmes rapidement.
Assurer le management des risques et la résolution des obstacles en temps opportun.
Cultiver une culture de l’adaptabilité, de l’innovation et de l’apprentissage.
Concilier les retours et les besoins des clients avec les contraintes techniques.
Encourager les boucles de rétroaction continues pour affiner les processus et les livrables.
Collaborer avec les parties prenantes pour recueillir et hiérarchiser les exigences.
Donner à l’équipe les moyens d’accepter le changement et de s’adapter à l’évolution des circonstances.
Promouvoir les pratiques agiles au sein de l’organisation.
Les responsabilités spécifiques du rôle de manager de projet agile varient en fonction des particularités de l’environnement Agile, de la nature du projet et des exigences de l’entreprise.
Quelle est la différence entre un manager de projet traditionnel et un manager de projet agile ?
La différence entre un manager de projet traditionnel et un manager de projet agile réside dans son approche du management de projet :
Manager de projets traditionnels
Met l’accent sur un style « commander et contrôler », en prescrivant des tâches et des processus. Se concentre sur la planification initiale détaillée, en visant un plan de projet complet dès le début. Principalement responsable de la répartition des tâches et de la supervision des contributions individuelles.
Manager de projets Agiles
Privilégie la collaboration et l’adaptabilité, en favorisant le travail d’équipe et la communication ouverte. Adopte une planification itérative et agile, permettant des ajustements flexibles tout au long du projet. Encourage le leadership partagé au sein d’équipes auto-organisées, en donnant aux membres les moyens de prendre collectivement des décisions et d’obtenir des résultats.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les compétences essentielles nécessaires pour réussir en tant que manager de projet Agile
Devenir un manager de projet Agile compétent implique de perfectionner un mélange de compétences techniques, interpersonnelles et de leadership pour guider les projets avec succès dans le paysage dynamique Agile. Les managers de projet Agile ont la responsabilité globale de gérer les projets agiles du début à la fin, ce qui nécessite un éventail de compétences uniques et adaptables, notamment :
Solides compétences organisationnelles : Capacité à gérer des projets complexes, à allouer efficacement les ressources et à s’assurer que les tâches sont accomplies à temps.
Excellentes compétences en communication : Aptitude à articuler les idées, les besoins et les progrès à différents niveaux de l’organisation, en favorisant la transparence.
Gestion des risques : Aptitude à identifier les risques potentiels du projet, à évaluer leur impact et à élaborer des stratégies d’atténuation.
Résolution de conflits : Capacité à gérer les désaccords et les différences au sein de l’équipe, à favoriser un environnement productif et agile et à améliorer l’efficacité de l’équipe.
Leadership adaptatif : Capacité à ajuster le style de leadership en fonction des besoins de l’équipe, en encourageant l’autonomie et l’auto-organisation.
Expertise Agile : Une compréhension du manifeste Agile et des quatre valeurs clés pourrait être avantageuse. Une connaissance approfondie d’un cadre Agile, tel que l’approche de projet DSDM, ainsi que des outils Agile, est essentielle pour une mise en œuvre réussie.
Flexibilité : Capacité à naviguer dans les incertitudes et les changements inhérents au travail Agile tout en se concentrant sur les objectifs.
Collaboration : Volonté de travailler en étroite collaboration avec les équipes interfonctionnelles, les parties prenantes et les clients afin de créer de la valeur en collaboration.
Approche centrée sur le client : Concentrez-vous sur la compréhension et la satisfaction des besoins des clients, en favorisant la satisfaction des clients et la collaboration.
Prise de décision : Capacités supérieures de pensée critique et de prise de décisions éclairées et opportunes.
Certifications et formations en management de projet agile
Alors que les approches de management de projet Agile continuent de dominer le management de projet, APMG propose une gamme variée de certifications de premier plan parmi lesquelles les apprenants peuvent choisir. Nos qualifications et formations en gestion de projet agile permettent aux managers de projet de développer des compétences et d’apprendre des approches agiles.
Cours et certifications agiles APMG :
Gestion de projet Agile (AgilePM) : Apprenez à appliquer le cadre de référence pour la réalisation de projets Agile
Gestion de programme Agile (AgilePgM) : Découvrez comment créer des programmes agiles flexibles, capables de répondre à l’évolution des besoins de l’entreprise.
Analyse d’affaires agile (AgileBA) : Maîtriser le rôle d’un Business Analyst dans un environnement Agile.
DASA DevOps : Transformez l’informatique de votre organisation en mettant en œuvre le DASA DevOps Principes.
Avec une qualification APMG, les managers de projet deviennent adeptes des processus agiles et des méthodologies agiles populaires, ce qui leur confère un avantage concurrentiel distinct.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Conclusion
Alors que les organisations reconnaissent de plus en plus le besoin de flexibilité, de collaboration et de progrès itératif, les managers de projet sont apparus comme des facilitateurs de ce changement de paradigme. En adoptant l’état d’esprit Agile, les managers de projet ne se contentent pas de superviser les projets, mais guident activement les équipes vers l’adaptabilité et l’orientation client.
En fin de compte, en incarnant l’éthique Agile et en cultivant un environnement qui nourrit les valeurs Agile, les managers de projet ouvrent la voie à des projets réussis, innovants et axés sur le client dans le paysage moderne dynamique.
Depuis son lancement en 2010, AgilePM s’est rapidement imposé comme le premier cadre et certification au monde pour le management de projet Agile, avec plus de 200 000 examens dans le monde.
La qualification AgilePM est basée sur le manuel AgilePM, publié par l’Agile Business Consortium.
Guide sur Amazon
Le manuel offre une méthodologie pratique et reproductible qui permet d’atteindre un équilibre idéal entre les standards, la rigueur et la visibilité requises pour un bon management de projet avec le rythme rapide, le changement et l’autonomisation fournis par Agile.
Avec la formation et la certification en management de projet agile vous :
Appliquez la philosophie et les principes sous-jacents d’AgilePM dans une situation de projet.
Configurez de manière appropriée le cycle de vie d’un projet Agile en fonction d’un scénario donné.
Identifiez et appliquez les techniques Agiles populaires dans une situation de projet, y compris la hiérarchisation MoSCoW, le développement itératif et le timeboxing.
Comprenez et attribuez des rôles et des responsabilités au sein d’un projet Agile.
Comprenez les mécanismes de gouvernance et de contrôle d’un projet Agile.
Comprendre comment tester, estimer et mesurer l’avancement d’un projet Agile
Décrivez et appliquez l’approche Agile à la gestion des exigences.
Vidéo de présentation d’AgilePM
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
Inspirés par le Manifeste Agile , découvrez de meilleures façons de travailler en le mettant en pratique de manière durable et en aidant les autres à le faire.
Engagez-vous à respecter le “Agile Sustainability Manifesto”.
L’ Agile Sustainability Initiative est un effort visant à sensibiliser la communauté Agile à la durabilité et à explorer comment Agile peut contribuer à un avenir plus durable.
Nous reconnaissons le rôle essentiel que l’agilité peut jouer dans la construction d’un monde durable et résilient. Nous croyons qu’en adoptant les valeurs et les principes agiles et en faisant évoluer nos pratiques, nous pouvons relever les défis complexes auxquels notre société, notre économie et notre environnement sont confrontés.
Inspirés par le Manifeste Agile et les contributions des membres de l’Alliance Agile, nous découvrons de meilleures façons de travailler en l’appliquant et en aidant les autres à le faire.
En reconnaissant que le Manifeste de développement durable agile changera au fur et à mesure que nous apprendrons au fil du temps, nous en sommes venus à apprécier :
Les gens et la planète plutôt que le profit
Nous accordons la priorité au bien-être des lieux (services écosystémiques et biodiversité) et des personnes (individus, communautés et générations futures) plutôt qu’aux gains financiers à court terme, favorisant ainsi un monde régénérateur et équitable.
L’adaptabilité plutôt que la rigidité
Nous considérons le changement comme une opportunité de croissance, de résilience et de durabilité, en valorisant l’adaptabilité plutôt que les plans et les structures rigides. Être capable de s’adapter à des conditions changeantes est une compétence clé face au changement climatique.
L’abondance plutôt que la rareté
Nous reconnaissons que les défis mondiaux exigent de cultiver des relations de coopération et des efforts de collaboration, et nous nous engageons à travailler ensemble au-delà des frontières pour trouver des solutions durables et, surtout, les mettre en pratique. #BetterTogether. Nous prônons une communication ouverte et transparente afin d’instaurer la confiance, de partager les connaissances et d’aborder honnêtement les questions de durabilité.
La valeur plutôt que la consommation
Nous nous efforçons de réduire la consommation d’énergie, de matériaux et de transport dans tout ce que nous faisons, avec le courage de donner impitoyablement la priorité à la valeur et de plaider pour une utilisation responsable des ressources et une consommation consciente sur notre planète finie avec la poursuite de la régénération chez toutes nos parties prenantes.
Les principes agiles de durabilité
#1 – Pratiques durables
Nous nous engageons à intégrer des pratiques durables dans tous les aspects de notre travail, en cherchant à minimiser l’impact environnemental et à promouvoir l’équilibre écologique.
#2 – Relever les défis mondiaux et y répondre
Nous accueillons les défis en constante évolution posés par le changement climatique, les inégalités sociales et la dégradation de l’environnement comme autant d’opportunités d’innover et de conduire un changement durable.
#3 – Fournir fréquemment de la valeur durable
Nous nous engageons à fournir des solutions durables de manière incrémentale, en privilégiant des délais plus courts, afin de résoudre les problèmes de durabilité urgents et à long terme. Nous insufflons et raccourcissons les boucles de rétroaction pour évaluer rapidement s’il faut changer ou persévérer.
#4 – Collaborer avec diverses parties prenantes
Nous collaborons activement avec diverses parties prenantes, y compris les communautés, les gouvernements et les organisations, afin de co-créer des solutions durables qui profitent à tous.
#5 – Responsabiliser les leaders agiles en matière de développement durable
Nous formons une nouvelle génération de leaders agiles en matière de développement durable qui défendent des pratiques éthiques, équitables et respectueuses de l’environnement.
#6 – Soutenir l’adoption académique de la durabilité agile
Nous encourageons l’intégration des principes de durabilité agile dans les programmes académiques afin d’éduquer les générations futures sur l’importance du développement durable.
#7 – Innover pour le bien-être de la société et de l’environnement
Nous explorons comment l’agilité peut être une force d’impact social et environnemental positif, en nous efforçant de trouver des solutions innovantes qui améliorent les vies (au-delà de l’anthropocentrisme – Système ou attitude qui place l’homme au centre de l’univers et qui considère que toute chose se rapporte à lui) et les écosystèmes.
#8 – Faire évoluer l’agilité pour répondre aux besoins modernes en matière de durabilité
Nous adaptons les pratiques agiles pour répondre aux besoins en constante évolution d’un monde durable, en améliorant continuellement nos pratiques pour créer un avenir meilleur. Laissant derrière nous un endroit meilleur qu’en l’état où nous l’avons trouvé.
En adoptant le Manifeste pour le développement durable Agile, nous nous engageons à utiliser les principes Agile pour relever les défis urgents de notre époque, en nous efforçant de créer un monde plus durable, équitable et prospère pour les générations actuelles et futures. Ensemble, nous pouvons bâtir un avenir résilient et harmonieux qui privilégie le bien-être humain, l’adaptabilité, la collaboration et la transparence dans la poursuite du développement durable.
Chaque geste compte, et chacun a quelque chose à apporter à la création d’une société respectueuse de la nature et régénératrice. Alors, retroussez vos manches ! Signez le Manifeste !
Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.
Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.
Comprendre les besoins et les exigences de l’entreprise
Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.
Guider le processus de développement
Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.
Trouver l’équilibre entre les besoins de l’entreprise et la convivialité
Trouver le bon équilibre entre les besoins des uns et des autres.
L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.
Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.
Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.
Communiquer avec les parties prenantes
En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.
Assurer le succès du lancement et de l’adoption
Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.
En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.
Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.
Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.
Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
La daily scrum est censée être une réunion de synchronisation d’équipe rapide et factuelle. Elle peut rapidement se transformer en cauchemars récurrents si les gens parlent trop ou trop peu. En tant que Scrum Masters, notre travail consiste à faciliter ces réunions quotidiennes afin qu’elles atteignent leur objectif et restent dans leur zone de temps.
Deux vidéos suivent. Et vous devrez peut-être regarder les deux, en fonction de votre équipe !
La première vidéo présente quatre choses que vous pouvez essayer pour faire bouger la réunion lorsque quelqu’un domine la conversation. La deuxième vidéo traite des choses à essayer lorsque certaines personnes donnent des réponses vagues (ou ne parlent pas du tout !). Si vous préférez lire, une transcription suit chaque vidéo.
Les deux vous aideront à éviter deux monstres des daily scrum : Les vampires qui sucent le temps et les zombies qui tuent l’énergie.
4 choses à essayer lorsque les gens parlent trop dans les mêlées quotidiennes
Certaines personnes ne veulent tout simplement pas se taire. Peut-être qu’elles sont nerveuses à propos de quelque chose, alors elles parlent. Peut-être pensent-elles que tout le monde veut entendre chacune de leurs pensées. Peut-être elles ne sont même pas conscientes qu’elles parlent autant. Mais trop parler peut être un énorme problème, surtout dans une réunion avec une limite de temps courte comme le daily scrum. Voyons ce que vous pouvez faire à ce sujet.
1. Mettez une minuterie
Une solution courante pour un membre de l’équipe trop bavard consiste à lancer un chronomètre d’une minute lorsque chaque personne commence à donner sa mise à jour pendant le daily scrum. Ce n’est pas grave, mais je trouve que cela oblige souvent une équipe à finir trop vite. La mise à jour de quelqu’un gagnerait souvent à prendre 2 à 3 minutes. Ceci est déconseillé, cependant, avec une minuterie d’une minute par personne.
2. Faites en sorte que l’horloge soit bien visible
Un Scrum Master, Kayleigh, m’a enseigné notre deuxième technique. Au fur et à mesure que chaque personne donne une mise à jour, elle tient un ballon de 3 kg droit devant elle.
La balle n’est pas très lourde, mais la tenir bras tendus devant vous deviendra plus difficile au fur et à mesure que vous parlerez. Ce que j’aime dans cette technique, c’est que la position devient de plus en plus difficile à tenir au fil du temps. Cela le rend très efficace.
3. Interrompez poliment
Voici un troisième conseil pour faire face à un membre de l’équipe trop bavard. Interrompez-le, surtout si vous êtes le Scrum Master ou le coach. Nous hésitons à l’interrompre parce que nous pensons que ce serait impoli. En réalité, ce qui est impoli, c’est que cette personne monopolise la réunion avec son soliloque.
Si quelqu’un est vraiment en train de blablater, le Scrum Master (ou, vraiment, n’importe qui sur le Équipe Scrum) doit les interrompre. Sinon, c’est impoli envers tout le monde dans la réunion.
Voici une bonne façon de l’interrompre poliment. Dites à la personne qui parle qu’il semble qu’elle ait encore beaucoup à dire sur ce sujet. Ajoutez ensuite que tout le monde doit avoir la possibilité de faire le point dans le délai prescrit de 15 minutes. Enfin, proposez de revenir vers l’orateur loquace une fois que tout le monde aura eu l’occasion de partager.
Certaines équipes utilisent l’idée bien connue d’un parking (parking lot) pour de tels sujets. Annoncez simplement que vous ajoutez cet élément au parking et que vous y reviendrez une fois que chacun aura fourni sa mise à jour.
D’autres équipes s’intéressent un peu plus à l’esprit agile des choses et se référeront au parking comme à la « seizième minute ».
4. Créez un signal
Si vous avez du mal à interrompre quelqu’un, voici une technique qui vous aidera. Au lieu d’interrompre la personne, donnez aux membres de l’équipe un moyen de signaler poliment à la personne qu’elle est trop longue. Pensez aux discours de remise des Oscars. Parlez trop longtemps et l’orchestre commence à jouer. Continuez à parler et ils jouent plus fort.
Une façon amusante d’obtenir le même effet est d’utiliser Elmo, le personnage de Sesame Street. Ensuite, utilisez son nom comme acronyme : Assez, passons à autre chose. Si vous êtes tous en présentiel, achetez un Elmo en peluche et gardez-le dans votre salle de réunion. N’importe qui peut brandir l’Elmo en peluche s’il pense que quelqu’un se perd. Cela fonctionne encore mieux pour les visioconférences. Encouragez tout le monde à trouver leur arrière-plan Elmo préféré et à le remonter lorsque quelqu’un parle trop longtemps.
Les daily Scrum sont censées être des réunions rapides et précises. Je ne veux pas qu’une équipe en termine en 5 minutes. C’est certainement trop court pour que quoi que ce soit de significatif ait été discuté ou partagé.
Mais je ne veux pas non plus que la réunion dure trop longtemps, et je ne veux certainement pas qu’une personne monopolise la conversation.
4 choses à essayer lorsque les gens ne parlent pas dans les mêlées quotidiennes
Parlons maintenant de ne pas parler. Comment faire en sorte que quelqu’un s’exprime lors d’une réunion quotidienne ?
Cela ne me dérange pas si quelqu’un reste silencieux lors d’une réunion alors qu’il n’a rien à apporter. C’est très bien, et il faut le féliciter davantage pour ce comportement de quelqu’un qui se sent obligé d’intervenir sur tout.
Mais, rester silencieux dans un stand-up quotidien est un problème parce que chaque personne est censée contribuer.
Pendant des années, les réunions quotidiennes scrum (ou réunions debout quotidiennes) ont suivi le même format. Chaque participant devait dire ce qu’il avait fait depuis la réunion précédente, ce qu’il ferait avant la prochaine réunion et décrire tout ce qui entravait ses progrès. Ces trois éléments représentaient les progrès, les plans et les problèmes d’une personne.
Ces trois éléments ne sont plus exigés d’une équipe Scrum dans ses daily scrum. Ils restent une bonne option par défaut pour la plupart des équipes sur ce qui devrait être couvert lors de la réunion. Mais la façon dont vous arrivez aux progrès, aux plans et aux problèmes n’est pas gravée dans le marbre. Vous devriez changer un peu, surtout si vos mêlées quotidiennes ne fonctionnent pas. Je recommande d’y aller histoire par histoire, plutôt que personne par personne.
Mais que devez-vous faire si vous êtes un Scrum Master ou un coach avec des membres de l’équipe qui fournissent une mise à jour mais ne disent rien de significatif ? Quelque chose comme : « Hier, j’ai travaillé sur quelques tâches. Aujourd’hui, je vais travailler sur quelques tâches. Pas de bloqueurs. »
J’ai entendu cela trop de fois pour les compter. Et ça ne vaut rien.
1. Recherchez les détails
Quand quelqu’un donne une mise à jour comme celle-ci, vous devez le pousser sur les détails. S’ils disent simplement qu’ils ont « travaillé sur certaines tâches », demandez-leur de nommer les tâches spécifiques. Ou si vous êtes physiquement avec un tableau des tâches sur Kanban, demandez-leur de pointer vers les lignes ou les cartes spécifiques.
2. Revenez à la structure
Posez une question à la fois aux personnes qui donnent des mises à jour vagues. Si votre équipe suit la convention de parler des progrès, des plans et des problèmes, posez d’abord des questions sur les progrès.
Ne laissez pas cette personne vous parler des trois aspects de son travail. S’ils commencent à se transformer en plans ou en problèmes, ramenez-les d’abord au progrès. Dites quelque chose comme : « C’est génial, et nous voudrons tous en savoir plus dans une minute sur votre plan pour aujourd’hui, mais sur quelles tâches spécifiques avez-vous travaillé hier ? » Ramenez-les à un seul sujet.
Donnez une structure et rappelez-la souvent.
Souvent, quelqu’un qui donne une mise à jour vague, comme dire qu’il a travaillé sur certaines tâches, est introverti. Et je peux comprendre : moi aussi. Mais ce qu’il faut savoir sur les introvertis, c’est que même si nous redoutons les bavardages, la plupart d’entre nous se débrouillent bien avec les conversations structurées. Alors, renforcez la structure de ces réunions.
Si vous voulez que les gens parlent des progrès, des plans et des problèmes, mettez l’accent sur cette structure en posant des questions sur chacun d’entre eux à tour de rôle.
Une autre façon d’ajouter de la structure à la réunion est de demander aux gens de donner leurs mises à jour dans un ordre connu. Et envisagez de demander aux membres de l’équipe, calmes et vagues, de passer en premier. Ou vous pouvez même y aller en premier vous-même. (Oui : je pense que les Scrum Masters et les coachs devraient aussi donner des mises à jour.)
Une bonne façon de le faire est de commencer par quelque chose comme : « OK, écoutons d’abord Ajay, puis Astrid, mais je vais commencer. » Ensuite, donnez votre propre mise à jour, ce qui donne aux deux personnes que vous avez nommées une chance de préparer les leurs.
Pourquoi est-ce que j’aime commencer par les gens qui donnent des mises à jour vagues? Parce que sinon, ils sont nerveux tout au long de la réunion à l’idée qu’ils seront appelés ensuite. Il est préférable de leur faire savoir quand ils parleront. Et quand vous y allez en premier, vous leur offrez un moment pour rassembler leurs pensées.
4. Renforcez l’objectif
Une autre mesure que vous pouvez prendre est de renforcer l’objectif des réunions debout quotidiennes. Il ne s’agit pas de microgérer une équipe. Les daily scrum ne sont pas des réunions d’étape conçues pour vérifier l’état des choses. Ce sont des réunions de synchronisation. Les membres de l’équipe synchronisent leurs efforts pour s’assurer que rien d’important n’est négligé et que deux personnes ne font pas la même chose sans être conscientes l’une de l’autre.
Lorsque les gens connaissent le but d’une réunion, ils sont plus susceptibles de comprendre la bonne façon de participer, en ne parlant ni trop ni trop peu, mais juste assez !
« Merci pour votre commentaire Serge Amon. Vous soulignez un défi crucial dans la gestion Agile des projets CRM : L’engagement profond et la disponibilité des équipes métier, souvent compliqués par un manque d’acculturation au mode projet Agile. »
Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture.
The Spotify Model of Scaling – Spotify Doesn’t Use It, Neither Should You par Mark Levison
Le « modèle Spotify » n’est probablement pas un modèle et n’est absolument pas ce qui est actuellement pratiqué chez Spotify aujourd’hui. (Certains suggèrent que cela n’a jamais été le cas.)
L’image ci-dessous a été rendue célèbre dans des vidéos d’Henrik Kniberg, où il explique comment le travail était organisé en escouades, tribus et guildes (Squads, Tribes, and Guilds).
Spotify Engineering Culture – Part 1&2 (aka the « Spotify Model »)
Beaucoup de gens voient la structure et essaient de l’imiter dans leur organisation. Pire encore, beaucoup tentent d’obtenir le bénéfice supposé en renommant les structures organisationnelles existantes avec ces nouvelles étiquettes.
La structure n’est pas le plus important. La culture dévorera n’importe quelle structure. (Indice : c’est pourquoi le fait de renommer vos équipes en « Escouades » et d’appeler les responsables de service « Chefs de chapitre » n’a jamais aidé.)
Cela dit, si je ne résume pas ici ces étiquettes, vous irez les chercher ailleurs de toute façon, alors c’est parti…
Squad : En fait une équipe Scrum avec un nouveau nom. Lorsque l’article original a été publié, chaque escouade possédait une petite partie de l’interface utilisateur ou du comportement du système. Ils possèdent cette partie du produit et peuvent mener des expériences sans dépendre d’autres équipes. Les personnes qui sont familières avec LeSS remarqueront que les escouades sont des équipes fonctionnelles.
Tribu : Un ensemble d’escouades qui travaillent dans un domaine connexe. Elle est conçue pour avoir une collaboration optimale entre les escouades avec peu de dépendances avec d’autres tribus. Les tribus sont limitées à 100 personnes afin de minimiser « les règles restrictives, la bureaucratie, la politique, les couches supplémentaires de management et autres gaspillages ».
Chapitre : Personnes d’un même domaine de compétence au sein d’une tribu, par exemple les testeurs ou les développeurs qui travaillent avec une certaine technologie. Les chapitres se réunissent régulièrement pour discuter des problèmes et partager les apprentissages dans leur domaine.
Guilde : une communauté d’intérêts plus large. Les guildes incluent généralement les chapitres, mais toute personne intéressée par un sujet peut rejoindre une guilde. Lorsque l’article original a été écrit, ils avaient des guildes pour la technologie Web et la guilde des coachs agiles.
Structurellement, il s’agit d’une façon parfaitement saine d’organiser les équipes. L’obstacle est si vous changez les étiquettes sans les changements culturel et de mentalité qui vont avec. Et la formation seule ne réalisera pas ce changement.
S’agit-il simplement d’un autre modèle matriciel, le genre de chose que les coachs agiles déconstruisent depuis des années ?
Oui, c’est le cas, mais c’est un autre type de matrice. Dans d’autres modèles matriciels, la relation horizontale est la relation principale. Par exemple, un développeur relève d’un responsable de développement ; un testeur à un manager des tests, etc. L’affiliation avec l’équipe ou les équipes avec lesquelles ils travaillent est plus lâche.
Spotify a inversé cette tendance. La relation principale est celle de membre d’une équipe stable et interfonctionnelle.
Le responsable du chapitre (ce n’est pas un bon choix de nom) est un coach, qui se concentre sur les compétences et l’excellence technique. En théorie, c’est génial. Dans la pratique, c’est le premier endroit où de nombreuses organisations commettent une erreur. Les responsables de votre chapitre ne devraient pas être d’anciens managers qui ont obtenu un nouveau titre de poste.
Il y a une myriade d’autres erreurs que les gens commettent en lisant un livre blanc et en regardant une vidéo. La liste serait plus longue que l’article original. Ce problème est si populaire qu’il a même son propre mème :
Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture. De plus, toutes les tentatives de documentation d’une culture sont des simplifications qui manquent des détails importants.
Au lieu de copier le modèle Spotify ou le modèle d’une autre entreprise au hasard (par exemple, FitBit, John Deere), développez votre propre modèle Agile. C’est la seule voie à long terme vers le succès.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Concentrez-vous sur les choses que Spotify avait dans son moteur
Apporter de la valeur. Toutes les améliorations apportées au système doivent être testées en se posant les questions suivantes : Cette amélioration ou cette expérience nous aide-t-elle à créer de la valeur ?
Amener de la valeur au produit. Ceci nécessite de mener des expériences et de voir ce qui fonctionne pour les utilisateurs finaux réels.
Autonomie plutôt qu’ordres et contrôle. Sans autonomie, il n’y a pas d’apprentissage, d’amélioration, d’innovation ni de capacité à s’adapter à des circonstances changeantes.
Alignement. Au lieu de dire aux gens ce qu’ils doivent faire pour les fonctionnalités et l’architecture du produit, concentrez-vous sur le fait d’amener les équipes à s’aligner sur un objectif produit commun. Envisagez d’avoir plusieurs équipes travaillant à partir d’un objectif produit commun.
Équipes interfonctionnelles orientées produit (alias Feature Teams). Plutôt que de constituer des équipes en fonction de leur souche fonctionnelle (par exemple, base de données, logique métier, interface utilisateur).
Une culture d’ingénierie qui met l’accent sur la qualité et la simplicité. Créez un pipeline de livraison continue qui permet aux équipes de créer de la valeur indépendamment les unes des autres. Au lieu d’un pipeline qui nécessite d’attendre que l’ équipe DevOps le déploie pour eux. Astuce : Dans de nombreuses organisations, DevOps est une équipe en aval de l’équipe de développement de fonctionnalité, qui déploie l’application. Il s’agit d’un anti-modèle bien connu.
Sécurité psychologique. L’article original l’appelait « expérimentation conviviale ». (experiment friendly). L’élément clé de l’expérimentation conviviale est la création d’un environnement où nous pouvons reconnaître la valeur de la prise de risques et l’apprentissage du processus. Le nom à la mode pour cela est « sécurité psychologique ».
L’amélioration continue en tant que caractéristique du système. Les équipes n’ont jamais fini de s’améliorer. Nous devons créer des cultures qui favorisent cet état d’esprit.
Le moral. Appelé à l’origine bonheur, il s’agit de la volonté et de la persévérance des membres de l’équipe à travailler pour le bien commun.
Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps. Pourquoi devriez-vous vous en soucier ?
In Agile, Where Change is Valued, Why Is a Stable Team So Important? par Mark Levison
Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps.
Pourquoi devrions-nous nous en soucier ? Scrum n’est-il pas comme le basket-ball où vous pouvez changer les joueurs sur le terrain à chaque fois qu’il y a une interruption ? Découvrons-le…
Les équipes très performantes, ou les équipes qui font des choses avec une qualité incroyablement élevée, est l’objectif de beaucoup de ceux qui arrivent dans Scrum en s’attendant à obtenir des performances incroyables de leur système. Mais construire une équipe performante à partir de zéro prend du temps. L’image populaire du modèle de formation d’équipe de Tuckman montre une équipe passant par les étapes de formation/constitution à tension à normalisation puis exécution/production. (Mise en garde : l’image existe pour simplifier la compréhension. La dynamique d’une vraie équipe sera plus désordonnée qu’on ne le montre ici).
Il est facile de former une équipe, puis de passer à toute vitesse à travers la phase de tension. La phase de tension est caractérisée par des conflits, car les gens appréhendent les rôles et les relations.
La normalisation et l’exécution sont considérablement plus difficiles dans les équipes instables, et elles s’y produisent à plusieurs reprises. Chaque fois qu’il y a un changement dans la composition de l’équipe, il y a de fortes chances de revenir à la phase de tension en raison de la nouvelle dynamique interpersonnelle. J’avertis les organisations que, lorsqu’elles doivent apporter des changements, il y a un risque que le changement les renvoie non seulement à la tension, mais qu’il soit également suffisamment dommageable pour que l’équipe ne s’en remette pas du tout. Combien de fois voulez-vous tenter la chance ?
La plupart des travaux de la littérature académique traitent de la familiarité, et non de la stabilité. Grosso modo, cela signifie « nous avons suffisamment travaillé ensemble dans le passé pour nous comprendre en tant qu’individus ». Que vous l’appeliez familiarité ou stabilité, la prémisse est la même : Les gens ont besoin de temps pour apprendre à se comprendre et à communiquer efficacement, la clé est que la familiarité est plus faible que la stabilité.
Lorsque les membres de l’équipe se connaissent, vous en voyez les bénéfices dans le niveau de qualité du travail de cette équipe. Prenons, par exemple, la chirurgie. J’espère que la plupart des équipes Scrum font un travail moins risqué que les interventions chirurgicales, mais la chirurgie (pour des raisons évidentes) est bien étudiée, ce qui nous donne une bonne source de données.
Il y a un chirurgien orthopédiste qui opère plus de 500 chirurgies du genou par an, soit 2,5 fois plus que n’importe qui d’autre dans son hôpital. Il a mis en place des dizaines de techniques pour améliorer ses interventions. Au lieu de travailler avec un groupe changeant d’infirmières et d’anesthésistes, il dispose de deux équipes dédiées et il dit que « peu des méthodes qu’il a mises au point seraient pratiques si elles n’étaient facilitées par la familiarité de travailler avec les mêmes personnes tous les jours ».[1]
Tuer le patient est l’erreur ultime. Ne pas les tuer est une barre assez basse de succès côté qualité. Néanmoins, les chirurgiens cardiaques qui travaillaient dans plusieurs hôpitaux mais maintenaient des équipes stables avaient un taux de mortalité plus faible, même avec davantage d’opérations chirurgicales effectuées. Les auteurs de l’étude ont attribué ce niveau de qualité du travail en partie à la familiarité de l’équipe.[2]
L’aviation et l’aéronautique sont également des domaines largement étudiés avec des données qui soutiennent l’importance d’équipes stables. « 73 % des accidents pour lesquels des informations étaient disponibles se sont produits le premier jour où le commandant de bord et le copilote ont volé ensemble. »[3]
Une étude de la NASA a révélé que les équipages fatigués qui avaient l’habitude de travailler ensemble commettaient environ deux fois moins d’erreurs que les équipages composés de pilotes reposés qui n’avaient jamais volé ensemble avant.[4]
Et pour redescendre sur terre, une étude de la société d’externalisation de logiciels Wipro a révélé qu’une familiarité accrue réduisait les défauts de 19%.[5]
Comment les équipes stables affectent-elles la prévisibilité ?
Il n’y a pas de données sur la prévisibilité des chirurgiens, ce qui, à mon avis, pourrait être une bonne chose.
L’étude de Wipro a montré que « les écarts par rapport au budget ont diminué de 30% ». Ignorons l’accent mis sur le budget, alors qu’il devrait s’agir de la construction du bon produit, mais cela montre que la familiarité facilite la prévisibilité.
Dans l’étude « Impact of Agile Quantified »[6], Larry Maccherone a montré que les équipes stables avaient une prévisibilité supérieure de 40%.
Incidence des équipes stables sur la productivité
Nous ne devrions pas vraiment courir après « plus de fonctionnalités produites plus rapidement » comme résultat. Au lieu de cela, nous devrions nous concentrer sur une meilleure valeur et de meilleurs résultats. Cela dit, je n’ai jamais rencontré quelqu’un qui ne voulait pas voir son équipe réaliser plus de choses.
Chez Wipro, « nous avons également constaté que la familiarité était un meilleur indicateur prédictif de performance que l’expérience individuelle des membres de l’équipe ou des managers de projet ». Des données plus impressionnantes du « The Impact of Agile Quantified » ont montré que les équipes stables sont 60% plus productives. Dans de nombreuses organisations, c’est le levier qui nous permet d’aller vers les équipes stables.
N’oubliez pas de vous concentrer sur les résultats plutôt que les productions.
Pourquoi les équipes stables fonctionnent-elles ?
L’esprit d’équipe (ou modèle mental partagé). Nous savons ce que les autres savent et sur qui on peut compter pour faire certaines choses.
La coordination et une meilleure collaboration sont plus faciles lorsque nous nous connaissons bien.
Flexibilité. L’esprit d’équipe et la capacité à collaborer permettent à l’équipe de s’adapter plus facilement lorsque des changements plus importants dans les produits se matérialisent.
L’amélioration continue nécessite les mêmes personnes, ainsi nous ne continuons pas à réexaminer des choses que nous avons apprises il y a des mois.
L’esprit d’équipe et le processus d’apprentissage continu approfondissent la connaissance de l’équipe de son domaine de travail, ses compétences techniques et sa connaissance de sa base de code.
Pourquoi les équipes stables peuvent-elles être difficiles ?
Donc, si les équipes stables sont une bonne chose, qu’est-ce qui rend difficile de les atteindre ?
Organisation matricielle. Lorsque les membres de l’équipe relèvent de différents managers, chaque manager aura des agendas/besoins différents. Par conséquent, les membres de l’équipe peuvent être réaffectés, même si une solution plus élégante pourrait fonctionner et leur permettre de rester dans l’équipe.
Dépendance à l’égard d’experts externes. Lorsqu’une équipe fait appel à une aide extérieure pour acquérir des compétences spécialisées, elle essaie souvent d’inclure « l’expert » dans l’équipe. Cela fonctionne rarement bien. Une meilleure solution est de les utiliser comme consultant/coach, mais de ne pas leur faire faire le travail pratique. Au lieu de cela, ils enseignent aux membres de l’équipe comment effectuer le travail en question, en maintenant la dynamique de l’équipe et en améliorant les compétences en même temps.
Politique organisationnelle. Berk. J’en ai assez dit.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Quand des équipes stables ne sont-elles pas souhaitables ?
Dans certains cas, lorsque la complexité du problème (voir : La complexité et le cadre Cynefin) est telle que les compétences des membres de l’équipe évoluent rapidement, les équipes stables peuvent ne pas être une priorité. Dans ce cas, nous pourrions sacrifier les performances, la réduction des erreurs, etc., pour avoir une chance de nous attaquer d’abord au problème. Les problèmes de cette nature sont incroyablement rares. S’il vous plaît contactez-moi si vous pensez en avoir trouvé un, je veux vérifier.
Reconstruire les équipes
Parfois, le produit sur lequel on travaille n’est plus aussi important et l’organisation doit réduire les coûts et déplacer les membres de l’équipe. Redgate Software a mis au point une technique permettant d’équilibrer la stabilité et l’adaptation à l’évolution des conditions du marché [7], où l’organisation prend chaque année des décisions stratégiques quant aux domaines sur lesquels se concentrer. Une fois les décisions prises, les membres de l’équipe peuvent choisir eux-mêmes l’équipe dans laquelle ils souhaitent travailler.
Préférez une appartenance stable à une équipe plutôt qu’un assemblage changeant de personnes. Lorsque vous n’avez pas le choix, examinez les circonstances et assurez-vous que l’organisation comprend ce à quoi elle renonce.
[1] The Firm Specificity of Individual Performance: Evidence from Cardiac Surgery – Robert S. Huckman and Gary P. Pisano
[2] A Review of Flightcrew-Involved, Major Accidents of U.S. Air carriers 1978 Through 1990 – NTSB
Permettez-moi de partager avec vous le processus que je suis pour comprendre les besoins des entreprises et explorons les différents outils et techniques que j’utilise pour y parvenir.
N’oubliez pas qu’il s’agit surtout d’art dans un cadre de travail défini.
Interrogez les principales parties prenantes
La première étape pour comprendre les besoins et les exigences de l’entreprise consiste à interroger les principales parties prenantes. Il peut s’agir de chefs de service, d’utilisateurs finaux et de cadres exécutifs.
L’objectif de ces entretiens est de comprendre les processus métier, les flux de travail et les points faibles que votre projet Agile va résoudre.
Le Product Owner doit préparer une liste de questions à l’avance pour guider la discussion et s’assurer que tous les sujets pertinents sont couverts.
Faites vos devoirs
À la suite des entretiens avec les parties prenantes, une chasse aux informations supplémentaires commence. L’une des tâches clés du Product Owner est de bien connaître la situation actuelle et d’identifier les domaines à améliorer ou à optimiser.
Voici quelques-uns des éléments que le Product Owner examinera :
Cartes ou diagrammes des processus métier actuels
Manuels ou guides d’utilisation existants
Résultats de précédents sondages (ou lancement d’un nouveau)
Commentaires des utilisateurs ou tickets de demandes d’assistance
Données historiques ou rapports sur l’utilisation du système actuel et performances des processus
En examinant ces documents et ces données, et en recueillant les informations des parties prenantes, le Product Owner peut mieux comprendre l’état actuel des processus métier et identifier les domaines à améliorer ou à optimiser. Cela permettra au Product Owner de travailler plus efficacement dans la phase d’atelier et plus tard avec l’équipe de développement pour concevoir et mettre en œuvre de manière Agile des solutions qui répondent aux besoins spécifiques de l’entreprise.
Animez des ateliers
Une fois que les principales parties prenantes ont été interrogées et que le Product Owner s’est formé, il ou elle peut animer des ateliers pour approfondir les exigences. Les ateliers peuvent être utilisés pour identifier les lacunes dans les processus métier actuels, hiérarchiser les caractéristiques et les fonctionnalités nécessaires, et définir les histoires utilisateurs.
Voici quelques-unes des meilleures pratiques pour assurer le succès des ateliers :
Préparez-vous et soyez ouverts d’esprit,
Posez des questions ouvertes,
Les ateliers ne doivent pas durer plus de 1h30,
Permettez aux participants de discuter des désaccords, mais rappelez-leur aussi ce qu’ils ont en commun.
Voici une liste d’ateliers qui peuvent être réalisés avec une proposition d’ordre du jour. Veuillez noter que ces séances peuvent être ajustées en fonction des besoins et des objectifs spécifiques du projet, et que l’ordre du jour peut être affiné en fonction des retours des principaux intervenants.
Atelier 1 : Introduction et examen des processus métiers et business
L’objectif de cet atelier est de cartographier les processus métier et les flux de travail de l’organisation, et d’identifier les opportunités d’automatisation et d’optimisation à l’aide de votre nouvelle solution. Cela permettra de s’assurer que le nouveau système est adapté aux besoins spécifiques de l’organisation et qu’il apporte une réelle valeur ajoutée. Bien que le Product Owner ait recueilli pas mal d’informations à partir d’entretiens et de données existantes, la réalité est souvent différente de ce qui est sur papier.
Accueil et présentations (10 min)
But et objectifs de l’atelier (10 min)
Revue des processus métiers actuels (30 min)
Identification des principaux défis et points faibles de l’entreprise (20 min)
Discussion sur les améliorations potentielles des processus existants (20 min)
Atelier 2 : Cartographie du parcours utilisateur
L’objectif de cet atelier est de comprendre les besoins et les difficultés des utilisateurs, et de cartographier leur parcours tout au long des processus de l’organisation. Cela permettra de s’assurer que le nouveau système est conçu de manière intuitive et conviviale, améliorant ainsi l’adoption et l’efficacité par les utilisateurs.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Identification des personas d’utilisateurs clés (20 min)
Cartographie des parcours utilisateurs pour chaque persona (40 min)
Discussion sur les points faibles et les possibilités d’amélioration dans chaque parcours (20 min)
Atelier 3 : Hiérarchisation et définition des fonctionnalités
Cet atelier consiste à définir et à hiérarchiser les fonctionnalités et les exigences nécessaires à la nouvelle solution, en fonction de l’évaluation de l’état actuel, de la cartographie des processus métier et des exercices de cartographie du parcours utilisateur. L’objectif est de définir le Produit Minimum Viable (MVP) qui peut être livré aux utilisateurs le plus rapidement possible tout en répondant à leurs besoins. Cela permettra de s’assurer que le système est conçu et construit de manière à s’aligner sur les besoins de l’organisation et à apporter une réelle valeur ajoutée.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Hiérarchisation des fonctionnalités en fonction de la valeur business et des besoins des utilisateurs (20 min)
Définition des fonctionnalités clés et des exigences pour chaque fonctionnalité prioritaire (40 min)
Discussion sur les concessions et compromis potentiels (20 min)
Atelier 4 : Exigences techniques et récapitulatif
Les problèmes complexes ont souvent de multiples solutions et chemins pour les atteindre.
Cet atelier se concentre sur la définition des exigences techniques du produit en fonction des fonctionnalités prioritaires et des contraintes identifiées. L’objectif est d’identifier les défis techniques potentiels et les solutions qui doivent être prises en compte au cours du processus de développement. Les contraintes, telles que le budget, l’échéancier et la disponibilité des ressources, doivent être discutées, ainsi que les solutions potentielles pour y remédier. L’atelier se termine par un résumé du processus de collecte des exigences et un plan pour aller de l’avant avec le développement.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Identification des exigences ou contraintes techniques (30 min)
Discussion sur les solutions potentielles pour répondre aux contraintes techniques (30 min)
Récapitulatif des principaux points à retenir de la série d’ateliers (10 min)
Mesures à prendre et prochaines étapes (20 min)
Documentez les exigences
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
Une fois les ateliers terminés, le Product Owner doit documenter les exigences. Cela inclut la création d’histoires utilisateur, la définition de critères d’acceptation et la création d’un arriéré de produit (product backlog). Le Product Owner doit travailler avec les parties prenantes pour s’assurer que les exigences sont exactes, complètes et alignées sur les besoins de l’entreprise.
Hiérarchisez les exigences
Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.
Affinez les exigences (Précisez les besoins)
Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.
Anticipez les difficultés auxquelles le product owner sera confronté
Imaginez une entreprise avec plusieurs divisions, chacune avec son propre processus de vente unique. L’équipe de vente de la division A a besoin d’un ensemble d’informations différent de celui de l’équipe de vente de la division B pour collecter un ensemble d’informations différent de celui de l’équipe de vente de la division B. Cependant, l’entreprise souhaite maintenir une instance de votre solution unifiée à des fins de reporting et d’analyse.
Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.
En tirant parti de cette flexibilité, le Product Owner peut combler efficacement le fossé entre les différents processus métier de chaque division et s’assurer que la solution globale est optimisée pour la réussite dans l’ensemble de l’entreprise.
La compréhension des besoins et des exigences de l’entreprise est essentielle à la réussite de votre projet quel qu’il soit.
Le Product Owner doit interviewer les principales parties prenantes, organiser des ateliers, documenter les exigences, hiérarchiser celles-ci, et examiner et affiner les besoins tout au long du processus de développement.
En suivant ces étapes, le Product Owner peut s’assurer que le système répond aux besoins de l’entreprise et des utilisateurs finaux et qu’il apporte une réelle valeur ajoutée.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
CertYou est partenaire de DantotsuPM, allez voir les formations et certifications Agile dont celles de Product Owner
partagez ce billet avec vos amis, collègues et relations professionnelles
C’est d’ailleurs de là que vient le nom du blog car le mot Dantotsu que j’ai croisé lors de voyages professionnels au pays du soleil levant signifie en Japonais « rechercher en permanence le meilleur du meilleur ». 
Je sélectionne, traduit en français et publie sur ce blog des billets liés au management de projets, programmes, Project Management Office (PMO) et Portfeuilles de projets (PPM), aux soft skills, à l’agilité, à l’analyse des besoins business et au leadership.
Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.
Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.
Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.
DantotsuPM.com 