83 % des praticiens Agile utilisent l’IA, mais la plupart y consacrent au plus 10 % de temps car ils ne savent pas où elle se situe. Stefan Wolpers
Le rapport AI4Agile Practitioners 2026 inclut des analyses détaillées des réponses par rôle, taille d’organisation et niveau d’agilité. Vous y découvrirez une analyse qualitative complète des défis, préoccupations, réussites et priorités.
Cette enquête auprès de 289 praticiens Agile identifie les véritables obstacles à l’adoption et montre où l’Intelligence Artificielle crée une valeur sur laquelle vous pouvez agir.
How to Provide a Release Plan Without Losing Agility by Mike Cohn
Une feuille de route est un plan, pas une promesse.
Je m’apprête à partir pour un road trip entre l’Idaho et le Colorado : un trajet de 16 heures.
Je sais où je vais, et mon itinéraire général, mais je ne connais pas chaque virage que je vais prendre — et ça me va.
C’est ainsi que les équipes agiles devraient traiter les plans de livraison et les feuilles de route.
Mon itinéraire est un plan, pas une promesse. Il n’est pas gravé dans le marbre. Les virages que j’ai pris et mon temps estimé pouvaient varier en fonction des travaux sur les routes, des embouteillages, d’une opportunité de détour excitant, ou même une crevaison. Plus je dois parcourir de la distance, plus je devrais m’attendre à être ces incertitudes.
Les plans agiles sont identiques. Nous ne pouvons pas prédire chaque éventualité, mais nous pouvons fournir une prévision. Nous pouvons donner une idée générale de la direction que nous envisageons, une plage prévue de moments où nous atteindrons probablement des étapes clés, ainsi que notre niveau de confiance dans le plan.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi les parties prenantes poussent pour avoir des garanties.
La plupart des équipes agiles savent qu’il y a trop d’incertitude pour tout garantir. En même temps, elles pensent qu’une garantie est la seule chose que les parties prenantes accepteront.
Voici ce que les équipes agiles pourraient manquer : les parties prenantes ont leurs propres plans à établir. Et elles sont tout aussi inquiètes que les équipes Agiles de devoir rendre des comptes sur leurs prévisions.
Les parties prenantes ont besoin de dates de livraison et de jalons justes (notez que je n’ai pas dit précis). Elles recherchent la prévisibilité.
Parfois, on a l’impression qu’elles demandent une garantie. Mais en vérité, la seule façon de leur donner une certitude absolue est de :
Charger nos estimations (comme dire à quelqu’un que mes 16 heures de route en prendront 24 heures, juste au cas où), ou
Refuser de vous adapter lorsque les conditions changent.
Aucun n’est bon ni pour le produit ni pour l’équipe.
Le chemin vers l’alignement commence par l’empathie.
Alors, que pouvez-vous faire lorsqu’une partie prenante semble vouloir une garantie plutôt qu’une prévision ? Essayez ceci : parlez aux parties prenantes en termes qu’elles comprennent. Voici une technique que j’ai trouvée utile :
Comparez leurs demandes à celles de prévisions similaires dans leur propre domaine.
Par exemple :
Demandez à un commercial quel serait son niveau de confort s’il devait garantir précisément combien il vendra — et avec quels clients il conclura — pour chacun des six prochains mois, ou durant la première année de sortie d’un produit.
Demandez à un responsable marketing quelles seraient ses préoccupations si on lui demandait de s’engager sur des résultats de campagne précis avec des délais précis.
Ne soyez pas dans la confrontation. L’objectif n’est pas de les piéger, c’est de montrer que l’incertitude existe partout, et que l’agilité est une force, pas une faiblesse.
Donnez aux parties prenantes ce dont elles ont besoin pour réussir.
Ensuite, partagez mon analogie de road trip avec vos parties prenantes. Dites-leur que vous ne pouvez pas leur donner de garantie, mais que vous pouvez présenter une feuille de route pour les 3 à 6 mois. La feuille de route montrera l’objectif de l’équipe, le niveau de progrès que vous pensez pouvoir faire à quel moment (exprimé en fourchette), ainsi que la confiance de votre équipe dans le plan.
Rappelez aux parties prenantes que, comme les itinéraires suggérés lors d’un long trajet, les feuilles de route agiles offrent de la visibilité, alignent les attentes et aident les gens à planifier — sans prétendre que chaque virage est connu à l’avance.
Libérer votre équipe d’attentes irréalistes peut accélérer leur transition de bon à excellent niveau.
P.S. Si votre équipe a du mal à concilier agilité avec attentes des parties prenantes, amenez Mountain Goat dans votre organisation pour un atelier de planification de sortie. Nous aidons les équipes à construire des feuilles de route flexibles et à haute confiance — sans trop s’engager. Vous avez besoin d’aide pour communiquer vos projets ? Essayez notre outil de visualisation de plans, gratuit pour tous les membres de MGS Essentials.
partagez ce billet avec vos amis, collègues et relations professionnelles
Technical skills fade. Soft skills compound and improve everyone around you.
Quiconque a travaillé dans le développement de produits pendant plus de quelques années a vu le même schéma se répéter. Les compétences techniques essentielles d’aujourd’hui deviennent progressivement — ou parfois brusquement — obsolètes. Les outils changent. Les cadres de travail tombent en désuétude. Des architectures qui semblaient autrefois modernes commencent à paraître datées.
Ce n’est pas nouveau, mais cela s’accélère. La durée de vie des compétences techniques ne cesse de diminuer. Dans les années 1980, il fallait 10 ans pour que la moitié de ce que l’on connaissait devienne obsolète. Aujourd’hui, il s’agit de 4 ans, et cela tombera bientôt en dessous de 2 ans selon un professeur de Stanford.
Cette réalité soulève une question importante pour les leaders :
Où l’investissement dans les personnes a-t-il le plus grand impact à long terme ?
Les compétences techniques sont nécessaires. Mais elles sont rarement durables. Les compétences relationnelles ou soft skills, en revanche, ont tendance à durer et même à se renforcer avec le temps.
La courte demi-vie des compétences techniques dans le développement de produits.
Quand quelqu’un apprend un nouveau langage de programmation, un nouveau framework ou un nouvel outil, cette compétence a une date d’expiration. Elle peut être utile un moment, mais il devra finalement être remplacée. C’est tout simplement la nature de la technologie.
Les compétences relationnelles se comportent différemment. Quand quelqu’un apprend à collaborer efficacement, à prendre de meilleures décisions, à animer des discussions ou à guider les autres, ces compétences ne s’effacent pas. Au lieu de cela, elles deviennent une partie intégrante du fonctionnement de cette personne.
Apprendre à apprendre est un bon exemple. Une fois que quelqu’un développe cette capacité, elle lui reste. Il en va de même pour la prise de décision, le leadership et la collaboration. Ces compétences peuvent continuer à s’améliorer, mais elles ne deviennent pas sans importance. Au fil de la vie d’une équipe — ou d’une carrière — cette différence compte.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi les compétences relationnelles comptent-elles plus que jamais dans les équipes produit ?
J’ai assisté une fois à une réunion où un programmeur présentait de nouvelles fonctionnalités à un groupe d’infirmières. Pendant la démonstration, il a montré un exemple à l’écran suggérant qu’un nouveau-né grognon devrait recevoir des crackers (ce qui est clairement cliniquement inapproprié).
Le programmeur a essayé d’expliquer que ce n’était qu’un texte provisoire. Le véritable but, a-t-il dit, était que le système fournirait au final des conseils aux infirmières. Le texte de l’exemple précis n’avait pas d’importance.
Pour les infirmières, cela comptait énormément.
Leur identité professionnelle repose sur le principe de « ne pas nuire ». Ce qu’elles voyaient à l’écran violait ce principe. Elles n’ont pas pu passer outre et étaient prêtes à faire remonter le problème et à annuler complètement le projet.
Ce qui a sauvé le projet, ce n’est pas une correction technique. C’était les compétences relationnelles du chef de projet. Il a calmé la situation, reconnu les inquiétudes des infirmières, expliqué ce qui s’était passé et les a convaincues de revenir une semaine plus tard pour une démonstration révisée.
La véritable défaillance n’était pas technique. C’était un manque d’empathie. Si le programmeur avait pu se mettre à la place des infirmières (ou simplement validé l’exemple avec l’une d’elles au préalable) la situation ne se serait probablement jamais produite.
Comment les compétences relationnelles réduisent-elle les risques dans le développement de produits ?
Le développement de produits est plein d’incertitudes. Les équipes travaillent avec des besoins évolutifs, des informations incomplètes et des utilisateurs dont la confiance doit être gagnée et maintenue.
Les compétences relationnelles réduisent les risques dans ces environnements. L’empathie aide les équipes à comprendre les utilisateurs et les parties prenantes. Une communication claire instaure la confiance. La collaboration évite que de petits malentendus ne deviennent de gros échecs.
Lorsque ces compétences sont faibles, les équipes les paient souvent plus tard par des travaux à refaire, des relations endommagées ou des opportunités manquées. Quand elles sont fortes, les équipes naviguent dans l’incertitude avec beaucoup moins de friction.
Pourquoi les dirigeants sous-estiment-ils le retour sur investissement des compétences relationnelles ?
De nombreuses organisations sous-investissent dans les compétences relationnelles car les bénéfices sont plus difficiles à mesurer. Il est relativement facile d’envoyer quelqu’un prendre un cours technique et de confirmer qu’il a appris quelque chose de nouveau. Il est beaucoup plus difficile de savoir si quelqu’un est devenu un meilleur collaborateur ou un meilleur facilitateur tant que l’équipe n’est pas sous pression.
Il y a aussi une hypothèse fréquente que les gens devraient déjà posséder ces compétences au moment d’entrer sur le marché du travail. En conséquence, les manquements sont ignorés jusqu’à ce qu’ils apparaissent aux pires moments possibles.
Ironiquement, ce sont à ces moments-là que les compétences relationnelles comptent le plus.
Les compétences relationnelles améliorent la performance de l’équipe, pas seulement des individus.
Quand quelqu’un apprend une nouvelle compétence technique, le bénéfice reste souvent cantonné à cette personne. Mais quand quelqu’un apprend à mieux collaborer, toute l’équipe en bénéficie.
Une meilleure collaboration améliore la communication, la prise de décision et la confiance au sein du groupe. Tout le monde s’améliore, pas seulement la personne qui a suivi la formation. Cet effet multiplicateur est l’un des avantages les plus négligés de l’investissement dans les compétences relationnelles.
Pourquoi les compétences relationnelles solides sont les plus importantes sous pression ?
Certains leaders pensent que l’amélioration des compétences relationnelles peut attendre que les choses se calment. Cela peut être le cas, mais vous ne pouvez pas attendre qu’une crise vous oblige à améliorer vos compétences relationnelles. Quand une équipe est sous pression est le moment où leur absence coûte le plus.
Les équipes dotées de solides compétences relationnelles peuvent avoir des conversations difficiles quand cela est important. Leurs membres peuvent discuter ouvertement des options, être en désaccord de manière productive et prendre de meilleures décisions sous pression parce que la confiance s’est construite plus tôt.
Les équipes dépourvues de ces compétences se renferment souvent, évitent les conflits ou optent par défaut pour la solution la plus rapide plutôt que la meilleure.
Quels postes en développement produit nécessitent le plus de fortes compétences relationnelles ?
Tous les membres d’une équipe de développement produit bénéficient de solides compétences relationnelles, mais certains postes en dépendent plus que d’autres.
Les Scrum Masters s’appuient sur des compétences en facilitation pour aider les équipes à réfléchir clairement et à bien travailler ensemble. Les Product Owners s’appuient sur des compétences de leadership pour aligner les parties prenantes, guider la prise de décision et créer une compréhension partagée. Les coachs et les leaders façonnent chaque jour l’environnement dans lequel ces compétences sont pratiquées.
Quand les détenteurs de ces rôles sont faibles en compétences relationnelles, toute l’équipe le ressent.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Investir dans les compétences relationnelles est le choix le plus durable que les leaders puissent faire.
C’est pourquoi les organisations efficaces de développement de produits ne laissent pas les compétences relationnelles au hasard. Elles les considèrent comme des capacités qui doivent être développées intentionnellement.
Les compétences techniques compteront toujours mais elles ont une durée de vie limitée. Les compétences relationnelles persistent. Elles s’ajoutent avec le temps, renforcent des équipes entières et montrent leur valeur de façon plus évidente quand la pression est forte.
Les leaders qui souhaitent des équipes capables de s’adapter, de collaborer et de prendre de bonnes décisions sur le long terme doivent investir délibérément dans ces compétences. Cela signifie considérer la collaboration, la facilitation et le leadership comme des capacités à développer et non comme des compétences à assumer présentes.
Si vous souhaitez de l’aide pour développer ces compétences auprès de vos Product Owners, Scrum Masters et équipes, Mountain Goat Software collabore avec des organisations pour y parvenir précisément.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pensez en dehors des sentiers battus par Mike Cohn
C’est devenu un autre cliché business surutilisé et cela me dérange pour une autre raison : La créativité vient souvent de la pensée à l’intérieur de la boîte « Thinking inside the box ».
C’est particulièrement vrai dans les ateliers d’écriture des histoires utilisateurs agile
Trop d’histoires, pas assez de focus
La différence entre un atelier d’écriture réussi et un atelier qui ne délivre pas se résume souvent à un seul facteur :
Le product owner a-t-il ou pas définit un objectif clair et significatif : Une « boîte » dans laquelle l’équipe peut penser.
Les ateliers sans poser de limites explorent souvent l’ensemble du produit. Les équipes peuvent générer une longue liste d’histoires utilisateurs, mais ces histoires manquent de cohésion ou de but. Il est difficile de les prioriser, et encore plus difficiles de les mettre en action.
La créativité a besoin de contraintes
Les ateliers les plus productifs commencent par une simple phrase de présentation du product owner, comme : « Nous sommes ici pour réfléchir à ce sous-ensemble spécifique du produit. »
Voilà ! Une limite bien définie et soudain l’équipe est alignée, concentrée et génère de meilleures et plus précieuses idées.
Au début de la vie du produit, cette limite pourrait concerner l’identification de ce qui est nécessaire pour livrer un Minimum Viable Product (MVP).
Plus tard, cela pourrait se concentrer sur une Fonctionnalité Minimale Commercialisable Minimum Marketable Feature (MMF), quelque chose d’assez petit pour être livré mais assez précieux pour avoir de l’importance.
Vous voulez commencer l’année avec un arriéré de produit propre et aligné ?
Lorsque les ateliers sont centrés sur un objectif significatif, il n’est pas nécessaire de les organiser à chaque sprint. Je les publie généralement environ une fois par trimestre car une session bien organisée génère un flux régulier d’histoires à forte valeur.
Que vous organisiez votre propre atelier d’écriture d’histoires ou que vous nous invitiez à vous aider, rappelez-vous que penser à l’intérieur des sentiers battus est un moyen puissant de faire passer les équipes de bonnes à excellentes,
Vos événements Agile n’échouent parce que les gens manquent de formation.
Ils échouent parce que votre organisation a adopté les rituels tout en rejetant la transparence, la confiance et l’adaptation qui les font fonctionner.
Et souvent, le dysfonctionnement des cérémonies mécaniques n’est pas un défaut : C’est une fonctionnalité.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Il existe de très nombreuses certifications qui vous permettent d’approfondir et étendre vos connaissances et d’être davantage reconnu professionnellement.
Intelligence Artificielle dans les projets, Projets de construction, Management du changement, management des risques, extension du Scrum Guide, nouvel examen de business analysis…
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMP® et bien d’autres.
Voici plusieurs billets publiés en 2025 sur les classiques comme les plus récentes formations et certifications dans le domaine des projets.
Lorsque les équipes se réunissent pour travailler vers un objectif commun, elles ont forcément des idées et des opinions différentes. La facilitation est un excellent outil pour aider à naviguer dans des conflits sains. C’est l’une des raisons pour lesquelles il est toujours utile d’avoir un ScrumMaster. J’ai déjà écrit à ce sujet de nombreuses fois. Cette fois, je veux vous présenter un outil qui n’est pas si courant, mais qui est très utile à avoir dans votre boîte à outils ScrumMaster. Thomas-Kilmann Conflict Mode Instrument (TKI) est un outil qui aide les gens à comprendre comment ils managent les conflits et à garder leurs équipes productives et heureuses.
5 modes différents de gestion des conflits.
Compétition
Le mode Compétition se situe dans le quadrant assertif et non coopératif. Prendre des décisions importantes sans l’accord de l’équipe peut nuire à la confiance et causer des problèmes. Par exemple, un Product Owner effectue des changements soudains sans en parler à l’équipe, ce qui entraîne de la colère et des problèmes de qualité. Ou un membre de l’équipe pousse ses idées sans écouter les autres, ce qui interrompt le travail et crée des tensions. D’un autre côté, il n’y a pas de mal à prendre des décisions rapides quand vous en avez vraiment besoin. Par exemple, un Scrum Master peut rapidement arrêter une discussion pour s’assurer que l’équipe atteint un objectif, ou un développeur peut dire que la sécurité est importante, même si d’autres sont plus axés sur la rapidité.
Collaboration
Le mode Collaboratif se situe dans le quadrant assertif et coopératif. Essayer de mettre tout le monde d’accord peut ralentir les choses et rendre les équipes moins efficaces. Par exemple, si vous passez trop de temps à faire du brainstorming et à essayer de plaire à tout le monde, cela peut retarder les décisions et provoquer une condition appelée « paralysie de l’analyse ». Ou, si vous essayez d’inclure les opinions de chacun, cela peut élargir la portée du projet au-delà de ce qui est réellement nécessaire. D’un autre côté, ce mode est idéal pour rassembler différentes perspectives et établir un consensus lorsqu’une équipe travaille ensemble pour s’assurer que les décisions techniques s’alignent sur les objectifs de l’entreprise. Cela peut améliorer la livraison du produit et la satisfaction des clients, ou lorsque les développeurs et le Product Owner collaborent pour s’assurer que les user stories sont claires et correctement hiérarchisées.
Compromis
Le mode Compromis est intermédiaire dans les quadrants de l’assertivité et de la coopération. Accepter des solutions partielles peut conduire à des opportunités manquées d’obtenir les meilleurs résultats. Par exemple, lorsque l’équipe se met d’accord sur une solution qui satisfait partiellement tout le monde mais ne répond pas pleinement aux besoins techniques ou business importants, ou lorsque l’équipe sacrifie la couverture des tests pour atteindre un objectif de délai de sprint, ce qui entraîne des corrections ultérieures et une dette technique. Cependant, il peut être utile pour parvenir à des règlements temporaires, comme la négociation d’un ensemble de fonctionnalités minimum viable avec les parties prenantes pour respecter les délais de livraison ou le partage du temps entre la refactorisation et la livraison de nouvelles fonctionnalités pour équilibrer la santé technique et la création de valeur.
Évitement
Le mode évitement se situe dans le quadrant non assertif et non coopératif. Ignorer les problèmes récurrents peut aggraver les choses et nuire à la qualité de la collaboration de l’équipe. Par exemple, si l’équipe continue d’ignorer les mêmes problèmes, cela peut entraîner une dette technique ou si un Scrum Master évite de gérer les conflits, l’équipe peut continuer à rester bloquée. Mais il y a des moments où il est acceptable d’ignorer les petits problèmes ou lorsque les autres membres de l’équipe sont mieux placés pour gérer certains conflits. Par exemple, s’il y a un débat sur un processus non essentiel qui peut attendre la rétrospective, ou si un développeur doté d’une expertise approfondie peut gérer un désaccord technique mineur sans impliquer toute l’équipe.
Serviabilité
Enfin, le mode serviable se situe dans le quadrant non assertif et coopératif. Essayer de trop plaire à tout le monde peut conduire à oublier des choses importantes comme les besoins techniques et de livraison. Par exemple, si un développeur continue d’accepter des délais impossibles pour satisfaire tout le monde, cela peut provoquer un épuisement professionnel, ou bien l’équipe fait toujours passer les exigences des parties prenantes en premier, même si cela signifie ignorer la dette technique. D’un autre côté, il est parfois bon de garder l’harmonie et les relations au premier plan. Par exemple, accepter de petites demandes de fonctionnalités pour créer de la bonne volonté avec les parties prenantes ou lorsqu’un développeur senior laisse un membre de l’équipe junior diriger une tâche pour qu’il puisse acquérir de l’expérience.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Les équipes agiles sont axées sur le travail d’équipe, et il est important que tout le monde sache comment il gère habituellement les conflits et comment le fait de s’orienter vers différents modes peut changer la dynamique de l’équipe. Par exemple, si vous avez un ScrumMaster qui est très fort en matière d’évitement et de serviabilité, il se peut qu’il ignore des problèmes de l’équipe, qu’il ne parvienne pas à éliminer les obstacles et qu’il compromette les principes agiles pour satisfaire tout le monde pendant un certain temps. En un mot, il n’aide pas vraiment l’équipe et les organisations à changer.
Les excellents ScrumMasters doivent avoir un profil équilibré avec un niveau de collaboration élevé pour intégrer les idées de l’équipe et favoriser le consensus, et une appétence modérée de la concurrence et du compromis pour protéger l’équipe, maintenir des principes agiles et gérer efficacement les équilibres.
Dans la vraie vie, les gens possèdent un mélange de tendances. Par exemple, imaginez que vous avez un Product Owner qui est très fort en matière de collaboration et d’adaptation. Il coopérera bien avec les clients et établira d’excellentes relations, ce qui est génial, mais en même temps, il essaie de rendre tout le monde heureux et ne peut pas définir une direction claire ou prendre une décision pourtant nécessaire.
Alors, par où commencer ?
Encouragez les membres de l’équipe à passer l’évaluation TKI pour mieux comprendre leurs styles de conflit par défaut. Comprendre ses tendances naturelles peut aider les individus à choisir consciemment l’approche la plus efficace dans diverses situations.
J’anime généralement des ateliers pour discuter des cinq modes de gestion des conflits et explorer les scénarios où chaque mode pourrait être le plus efficace. L’utilisation de jeux de rôles aide les membres de l’équipe à s’entraîner à changer de mode et à comprendre les points de vue des autres.
Les grands Scrum Masters sont d’une grande aide. Ils sont doués pour reconnaître les modes de conflit et sont capables d’aider les équipes à trouver la façon la plus constructive de manager les conflits. Ils incitent les individus à réfléchir sur leurs tendances et les aident à créer un meilleur équilibre. Ce sont eux qui s’assurent que tout le monde se sent en sécurité pour partager ses pensées, et ils interviennent lorsque les choses commencent à devenir trop animées.
Cette bibliothèque de connaissances (Articles, documents, vidéos, formations sur Agile et plus particulièrement Scrum) a été récemment améliorée en se basant bien sûr sur les retours de ses utilisateurs.
Un design audacieux et épuré qui facilite l’exploration et la découverte d’articles, de vidéos et d’autres ressources. Vous bénéficierez toujours des mêmes caractéristiques et fonctionnalités qu’auparavant, mais avec une apparence considérablement améliorée.
Des balises (tags) intuitives en haut pour que vous puissiez filtrer instantanément par articles, vidéos, webinaires, communiqués de presse ou collections, ou afficher tous les types de ressources.
Des filtres thématiques sur la gauche de l’écran pour une recherche ciblée. Vous pouvez sélectionner un ou plusieurs de ces filtres en fonction de ce qui vous intéresse à explorer.
Une barre de recherche simple pour trouver des ressources par mot(s) clé(s) ou titre complet.
Bien que ces huit postures soient précieuses, trois d’entre elles constituent le socle d’un Scrum Master efficace : Coach, Formateur et Mentor. Ces rôles sont souvent combinés, mais chacun a un objectif distinct pour aider les équipes à se développer et à prospérer.
Le Scrum Master en tant que coach.
Le coaching consiste à libérer le potentiel de l’équipe, et non à fournir toutes les réponses. Un Scrum Master en tant que coach doit développer sa patience, ses capacités d’écoute et sa capacité à guider sans diriger.
Ce que cela donne au quotidien.
Écoute activement et patiemment.
Aborde le coaching avec la conviction que l’équipe a déjà les réponses.
Guide systématiquement sans intervenir pour faire le travail.
Apporte une perspective holistique dans les conversations.
Comprend que les changements significatifs sont graduels et nécessitent plus que des processus documentés.
Les compétences de coaching ne se construisent pas du jour au lendemain. Elles nécessitent de la pratique, de la réflexion et des années de perfectionnement. L’expérience en leadership aide, mais l’essence du coaching est la confiance, c’est-à-dire permettre aux équipes de trouver leurs propres réponses.
Le Scrum Master en tant que formateur.
Sans expérience pertinente, il est difficile pour un Scrum Master d’enseigner efficacement. La formation implique le transfert de connaissances, parfois sur Scrum lui-même, d’autres fois plus largement sur les pratiques de produit et de développement.
Ce que cela donne au quotidien.
Enseigne aux équipes les événements Scrum, les valeurs et autres pratiques agiles.
Guide les Product Owners dans les techniques de management de produit comme le backlog slicing.
Initie les développeurs à des pratiques collaboratives telles que mob programming ou le TDD.
Soutient les testeurs en leur montrant des moyens de mieux collaborer avec les développeurs.
Ici, l’expérience compte. Un Scrum Master qui a travaillé dans des organisations de produits peut enseigner avec crédibilité et une perspicacité pratique, rendant les concepts abstraits plus concrets.
Le Scrum Master comme mentor.
Alors que la formation consiste à transférer des connaissances, le mentorat va plus loin : Il consiste à accompagner l’apprenant. Contrairement au coaching, où le Scrum Master pose principalement des questions, le mentorat consiste souvent à partager des conseils, des expériences et même à modéliser les bonnes pratiques.
Ce que cela donne au quotidien.
Aide les membres de l’équipe à devenir de meilleurs animateurs d’événements Scrum.
Guide les individus pour résoudre leurs propres obstacles.
Offre des conseils et une perspective aux équipes qui naviguent entre les différentes options.
Le mentorat accélère la croissance parce qu’il fournit à la fois des connaissances et des exemples vécus. Il dit : « Voici comment je l’ai fait – maintenant, essayons-le ensemble. »
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi ces postures sont importantes.
Les Scrum Masters qui manquent de compétences en matière de coaching, de formation et de mentorat ont souvent du mal à avoir un impact. C’est pourquoi j’encourage les nouveaux Scrum Masters à acquérir de l’expérience dans d’autres rôles au sein d’une équipe Scrum avant d’entrer dans ce rôle. Une exposition plus large vous fournit des informations pour coacher avec empathie, enseigner avec autorité et mentorer avec confiance.
Bien sûr, aucun Scrum Master n’est un expert en tout. Il y a des moments où il est logique de s’associer à d’autres pour combler vos lacunes en matière de compétences. Par exemple, j’ai une formation en développement, mais je m’appuie sur des développeurs ou des architectes seniors lorsque l’équipe a besoin d’une expertise approfondie en conception de logiciels. Cette collaboration ne diminue pas le rôle du Scrum Master, mais l’améliore en veillant à ce que l’équipe reçoive les bons conseils.
Réflexions finales.
Être un Scrum Master n’est pas une question de titres ou de cérémonies. Il s’agit de permettre aux personnes et aux équipes de se développer. Le coaching permet à l’équipe d’être une meilleure version d’elle-même, la formation fournit de nouvelles connaissances et le mentorat s’appuie sur ces connaissances pour créer des capacités durables au sein de l’équipe.
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.
J’anime plusieurs cours sur le leadership agile et Scrum, si vous souhaitez en savoir plus sur le cadre de travail Scrum, consultez la page de la ValueHut Consulting Academy
partagez ce billet avec vos amis, collègues et relations professionnelles
Ces termes sont si fréquemment utilisés (et mal utilisés) que leur impact peut être perdu, mais comprendre comment chaque approche fonctionne (et pourquoi leur combinaison est si puissante) est essentiel pour créer de meilleurs logiciels, plus rapidement.
Cet article décompose chaque approche, utilise des analogies du monde réel et explore pourquoi la combinaison des deux est plus efficace que l’une ou l’autre seule.
Qu’est-ce que le développement itératif ?
Un processus itératif progresse par le raffinement.
Une approche itérative du travail commence par une version approximative d’une fonctionnalité ou d’un produit, puis l’améliore grâce à des cycles répétés, chacun se rapprochant peu à peu de la forme finale.
Par exemple, un sculpteur qui aborde le travail de manière itérative peut commencer par sculpter grossièrement un bloc de pierre. À chaque passage, il affine la forme, ajoutant des détails, lissant les bords et s’améliorant continuellement jusqu’à ce que la sculpture atteigne sa forme finale. La sculpture n’est pas terminée tant que l’ensemble de la pièce n’est pas terminé.
Qu’est-ce que le développement incrémental ?
Un processus incrémental permet de créer et de livrer des fonctionnalités et des produits en plusieurs parties. Chaque élément, ou incrément, représente un sous-ensemble complet de fonctionnalités.
Les incréments peuvent être petits ou grands. L’objectif est de terminer chaque incrément de fonctionnalité dans son intégralité avant de passer au suivant, sans qu’il soit nécessaire de revenir en arrière et de repasser sur ce travail plus tard. Chaque incrément terminé peut être livré seul.
Pour en revenir à l’analogie de la sculpture, un sculpteur incrémental choisirait un élément de la sculpture et se concentrerait sur celui-ci jusqu’à ce qu’il soit terminé. Il peut choisir de petits incréments (d’abord le nez, puis les yeux, puis la bouche, et ainsi de suite) ou de grands incréments (tête, torse, jambes puis bras). Cependant, quelle que soit la taille de l’incrément, le sculpteur incrémental tenterait de terminer le travail de cet incrément aussi complètement que possible avant de passer à autre chose.
Les équipes agiles combinent incrémental et itératif.
Le développement agile combine les deux approches pour obtenir le meilleur des deux mondes :
C’est itératif parce que le plan est que chaque pièce soit affinée et améliorée au fil du temps.
C’est incrémental car des logiciels fonctionnels utilisables sont livrés tout au long du projet.
Cette combinaison permet aux équipes d’apporter de la valeur dès le début, d’obtenir des retours et de s’adapter.
La vidéo ci-dessous montre comment le comédien Jerry Seinfeld aborde son travail d’une manière à la fois incrémentale et itérative.
Exemple concret : Création d’une application de rencontres.
Imaginez que vous développez un site de rencontres. Voici comment chaque approche fonctionnerait.
Purement itératif
Vous construisez et bénéficiez d’un peu de toutes les fonctionnalités : Profils, recherche, chat, etc.
Vous revenez en arrière et améliorez chacun d’entre eux au cours de plusieurs cycles.
Au fil du temps, l’ensemble du système est perfectionné puis, finalement, livré.
Purement incrémental
Vous créez et fournissez une version parfaite de la fonction de gestion des profils. Vous ne commencez rien d’autre avant que ce soit terminé.
Vous construisez et livrez une version parfaite d’une deuxième zone, disons la recherche. Vous passez ensuite à la suivante.
Chaque fonctionnalité est parfaite avant le début de la suivante.
Itératif + Incrémental (Agile)
Vous commencez avec une version de base du profil utilisateur, vous la livrez. Vous obtenez des commentaires.
Vous ajoutez la possibilité d’ajouter une image au profil de l’utilisateur et de fournir une version de base de la fonctionnalité de recherche. Vous obtenez à nouveau des commentaires.
Vous réorganisez les champs sur le profil utilisateur pour améliorer l’expérience utilisateur. Vous ajoutez des filtres à la fonctionnalité de recherche. Vous créez un schéma de la fonction de chat. Vous obtenez davantage de commentaires.
Les sprints suivants peuvent inclure des améliorations apportées aux fonctionnalités précédentes et des versions de nouvelles fonctionnalités utilisables. Ou les deux.
Une approche agile permet des mises en production précoces, des expérimentations à faible risque et des corrections de cap fréquentes, caractéristiques des équipes performantes.
L’agilité est itérative et incrémentale
Ni le développement incrémental ni le développement itératif n’apportent à eux seuls beaucoup de valeur. Mais ensemble, ils forment la colonne vertébrale de l’agilité.
L’itération aide les équipes à affiner et à s’adapter. L’incrémental garantit une progression constante et une création de valeur. Combinés, ils permettent d’obtenir de l’agilité, de la réactivité et des résultats concrets.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Je continue de travailler avec des gens qui ont de la difficulté avec leur approche agile. Ils me disent que l’estimation relative ne fonctionne pas pour eux. Ils continuent à repousser des items de l’arriéré de produit, d’un sprint à l’autre. Ils ont reconduit certains articles 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 résoudre la situation.
C’est à ce moment-là que je leur recommande d’utiliser les métriques de flux au lieu de l’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles ne les aident pas.
Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces indicateurs mettent en évidence les principes de l’agilité. Lorsque les équipes mesurent ces quatre indicateurs, 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 comptent pour les équipes et les managers.
Tout d’abord, voyons ce que sont les métriques de flux.
Métriques de flux
Voici les quatre indicateurs de flux :
Work InProgress (WIP), travail en cours. Tous les travaux en cours : commencés et pas encore terminés.
Throughput, débit : Nombre d’éléments de travail qu’une équipe/un responsable peut effectuer par unité de temps.
Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
Vieillissement : Depuis combien de temps un travail est en cours.
Bien que les indicateurs de flux soient indépendants, ils créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager.
Commençons par une équipe.
Comment les métriques de flux interagissent
Imaginez une équipe qui termine régulièrement un élément chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense que l’on 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 autre article 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, simplement parce qu’elle a commencé un élément supplémentaire.
En fait, leur débit a diminué parce qu’ils travaillent sur deux articles en parallèle et n’ont terminé aucun des deux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux articles plus anciens, ce qui augmente l’âge moyen de tous les articles.
La demande de travail augmente, tout cela parce que l’équipe n’a pas terminé « assez » d’items.
C’est une boucle de rétroaction qui se renforce. À mesure que le WIP augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des articles plus vieux. Tout cela augmente leur WIP.
Nous tournons en rond, créant un environnement de plus en plus mauvais pour l’équipe.
Si vous avez déjà vu une équipe « basculer » le travail d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse n’aident pas, mais la mesure du temps de cycle fonctionne.
La bonne nouvelle, c’est que l’équipe peut intervenir à n’importe quel endroit et apporter des améliorations.
Interventions de l’équipe.
Voici les questions que l’équipe peut poser :
Quelle est lachose sur laquelle nous devrions travailler et terminer ? (Commencer par WIP.)
Quel âge a notre item le plus ancien ? A-t-il encore de la valeur ? (Commencez par le vieillissement.)
Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Focus sur le temps de cycle.)
Comment pouvons-nous augmenter notre débit ? (Focus sur le débit.)
boucle de renforcement positif
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 en-cours à un seul élément, elle doit changer sa façon de travailler. (J’ai abordé ce problème de collaboration dans le conseil 3 en Trois conseils pratiques pour commencer votre prochaine année en force.)
Ensuite, plus l’en-cours est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens items est réduit. C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.
Est-ce que « 1 item » est toujours le bon nombre pour les travaux en cours ? Non. Dans créez votre projet Agile réussi, je recommande à l’équipe de commencer par le nombre de personnes de l’équipe divisé par deux. Si vous avez un nombre impair de personnes, arrondissez au dessous. Donc, si vous avez cinq personnes, utilisez deux comme WIP maximum.
Mais votre équipe peut vouloir commencer par des changements d’équipe pour réduire le temps de cycle et augmenter le débit. Vous pouvez commencer n’importe où car il s’agit d’une boucle de rétroaction.
Les managers travaillent différemment. Aussi, les indicateurs ne changent pas, mais les interventions de la direction changent.
Interventions de la direction
Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne livrent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées présentées dans pourquoi minimiser le temps de décision de la direction ont tellement d’importance.
Plus les managers ont des de décisions en cours de réflexion (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus le WIP d’un manager 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 se 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 les travaux en cours.)
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 de rétroaction qui fonctionne pour eux, et non contre eux.
Les indicateurs de flux peuvent amener de meilleures décisions.
Lorsque les équipes et les managers voient le nombre de leurs travaux en cours, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils veulent changer. Est-il temps de collaborer davantage ? Peut-être commencer par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? ».
Les indicateurs de flux sont importants car ils permettent aux équipes et aux managers de voir et de gérer leur façon de travailler. Utilisez-les pour obtenir des informations sur les domaines dans lesquels vous pourriez choisir de modifier votre travail.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Cette lettre d’information aborde les sujets abordés dans les livres :
Êtes-vous nouveau sur la newsletter Pragmatic Manager ? Consultez les numéros précédents ou visualisez et écoutez ces newsletters sur la chaîne YouTube.
partagez ce billet avec vos amis, collègues et relations professionnelles
Avez-vous remarqué que certaines équipes semblent être plus efficaces que d’autres ?
La plupart du temps, elles gèrent leur WIP (Work in Progress). Ses membres apprennent ensemble. Souvent, ils collaborent à l’échelle de l’organisation. Mais le point majeur, c’est qu’ils ont tendance à livrer plus rapidement et plus souvent que les autres équipes moins efficaces.
Bien que la plupart de ces équipes efficaces soient interfonctionnelles, j’ai travaillé avec des équipes de composants qui ont démontré ce comportement. Chaque équipe était autonome, mais elle collaborait pour livrer quelque chose de plus grand que « son » seul composant.
Qu’est-ce qui crée ces équipes plus efficaces ?
Plusieurs caractéristiques :
Elles ont un objectif global clair.
Tout le monde collabore pour travailler vers cet objectif, et seulement vers cet objectif.
Les membres de l’équipe ont appris à donner et recevoir des commentaires les uns des autres. Ces commentaires aident l’équipe à apprendre et à s’améliorer.
Et comme très peu d’équipes peuvent livrer seules, elles peuvent aider les autres équipes à apprendre et à s’améliorer. Tout cela parce qu’elles créent et utilisent des plus petits réseaux. Ce sont des équipes autonomes.
Comment fonctionnent les équipes autonomes ?
Les équipes autonomes prennent leur objectif clair, se concentrent sur celui-ci et atteignent cet objectif. Elles décident comment travailler ensemble et comment manager les membres de l’équipe lorsqu’elles ne le peuvent pas. Lorsqu’elles ne peuvent pas livrer, elles vous en informent le plus tôt possible.
Si vous êtes manager, comment pouvez-vous créer ces équipes autonomes ?
Établissez et clarifiez l’objectif global de cette équipe.
Demandez à l’équipe si elle a besoin d’une certaine facilitation au début ou au fur et à mesure qu’elle persiste. Si certaines équipes autonomes n’ont pas besoin de facilitation, beaucoup en ont la nécessité. Surtout face aux exigences omniprésentes de multitâches.
Encouragez la création de communautés à l’échelle de l’organisation et de plus petits réseaux. Cela aide les personnes et les équipes à réfléchir à la manière dont elles peuvent apprendre à l’échelle de l’organisation. Et d’offrir des informations recueillies dans leur équipe aux personnes de l’ensemble de l’organisation.
Commençons par l’objectif global.
Définissez et clarifiez l’objectif global de l’équipe.
Les équipes de développement de produits ont souvent un objectif global axé sur le produit. C’est de la forme :
Cette version permettra au jeu de clients numéro un de résoudre les problèmes A, B et C dans cet ordre de classement. Bien que nous espérions pouvoir également résoudre les problèmes D, E et F, nous nous concentrons pour l’instant sur ce plus petit objectif spécifique. Parce que même si nous voulons accomplir D, E et F, nous pouvons également vouloir nous concentrer sur un jeu de clients différent lorsque nous terminerons A, B et C.
Vous pouvez décrire différemment l’objectif global de votre équipe. Cependant, ces objectifs sont souvent spécifiques, c’est pourquoi ils définissent un périmètre circonscrit autour du travail de l’équipe, afin que l’équipe puisse se concentrer uniquement sur son travail. Pas de multitâche. Pas d’interruptions.
Mieux encore, un périmètre circonscrit aide l’équipe à repousser ce qui est hors de celui-ci pour le moment. L’équipe ne se laisse pas distraire par un travail futur ou d’autres possibilités. Au lieu de cela, elle livre ce qu’elle doit livrer.
Si vous faites partie d’un programme, un ensemble de projets tous axés sur un livrable business global, vous avez probablement vu des équipes agir ainsi. Chaque équipe se concentre sur sa contribution pour que le produit global réussisse.
Alors que certaines équipes peuvent s’accaparer leur objectif global et le suivre, certaines équipes ont également besoin de facilitation.
Envisagez des rôles d’animation d’équipe.
Normalement, je ne considère pas le leadership de produit comme un rôle d’animation d’équipe. Mais parfois, c’est le cas. Surtout si les membres de l’équipe ont du mal à se concentrer sur le premier jeu de clients. Ou dans l’ordre de hiérarchisation des problèmes A, B et C.
Il y a longtemps, j’ai travaillé sur un programme où la direction avait décidé de reporter pour le moment plusieurs fonctionnalités intéressantes et de les considérer pour une future version. Cependant, un développeur était convaincu qu’il devait « sauver » le produit en continuant à travailler sur ces fonctionnalités intéressantes.
C’est à ce moment-là que le chef de produit a expliqué l’intérêt de reporter ces fonctionnalités intéressantes et ce que l’entreprise espérait gagner avec cette version plus limitée.
Une fois que le développeur a compris ceci, il fut heureux de se concentrer sur le travail de l’équipe, et non sur ses intérêts.
Parfois, les équipes ont besoin de liberté pour être autonomes. J’ai vu des managers bien intentionnés (et certains moins bien intentionnés) s’insérer dans le travail de l’équipe. Lorsque les managers font cela, l’équipe perd son autonomie. Au lieu de cela, un manager de projet facilitateur peut agir comme une boîte de délimitation pour l’équipe elle-même, protégeant l’équipe des personnes qui détruiraient l’autonomie de l’équipe.
Les managers de projet facilitateurs ne disent pas à l’équipe quoi faire ou comment travailler. Au lieu de cela, ils et elles créent l’environnement pour que tout le monde puisse contribuer. Parfois, cela signifie expliquer à des managers bien intentionnés que non, l’équipe ne peut pas en faire plus.
Parfois, ces animateurs et animatrices aident l’équipe à mieux travailler ensemble. Il peut s’agir de faciliter les accords de travail de l’équipe ou d’aider l’équipe à s’entraîner à donner et recevoir des commentaires. Il peut s’agir d’aider l’équipe à envisager des pratiques alternatives pour la rendre encore plus efficace.
Mais les leaders facilitateurs ne disent pas à l’équipe comment travailler. Ils et elles offrent des options. Souvent, l’une de ces options inclut les communautés de l’ensemble de l’organisation.
Construisez des communautés à l’échelle de l’organisation.
Lorsque je vois des équipes autonomes, je découvre souvent que ces équipes ont construit des réseaux à l’échelle de l’organisation. (Voir l’image en haut de cet article.) Non pas parce que quelqu’un leur a dit de le faire. Mais elles se rendent compte que Marie, là-bas, a des connaissances intéressantes. Et Fred, ici, a déjà résolu un problème comme celui-ci. Ou Suzanne, dans cette autre équipe, a déjà eu affaire à ce client.
Les équipes autonomes peuvent combler leurs lacunes en travaillant avec et auprès d’autres personnes, même si ces autres ne font pas partie de « leur » équipe.
J’aime particulièrement les groupes d’apprentissage ciblés. Envisagez les communautés de pratique formelles comme un moyen de commencer par un apprentissage ciblé. À l’époque où les entreprises avaient des cafétérias, j’apprenais beaucoup de choses de manière informelle au déjeuner. Non seulement j’ai appris à connaître les produits, mais j’ai aussi appris qui avait quels types de connaissances. Cela m’a aidé à décider par où commencer une quête sérieuse.
Bien que de nombreuses équipes autonomes n’aient pas besoin d’un leadership spécifique axé sur un projet ou une équipe, elles ont besoin du type de leadership qui peut définir l’objectif global.
Les équipes autonomes ont toujours besoin d’un leadership d’entreprise.
La grande chose dont les équipes autonomes ont besoin de la part de la direction est la suivante : L’objectif global et la durée de cet objectif.
Cela signifie que les équipes autonomes doivent comprendre le(s) objectif(s) du produit et la stratégie. Ces équipes doivent comprendre à quelle fréquence la direction de l’entreprise souhaite être en mesure de modifier ces objectifs de produit et/ou cette stratégie.
De plus, il arrive que des équipes se retrouvent en difficulté et qu’elles ne sachent pas comment s’en sortir. (Imaginez un membre de l’équipe qui cesse de venir travailler. Ce genre de problème.) C’est à ce moment-là que les managers peuvent soutenir l’équipe et les différents membres de l’équipe.
Les équipes autonomes ne fonctionnent pas en circuit ouvert. Au lieu de cela, elles montrent leur travail tôt et souvent. Elles utilisent un périmètre circonscrit pour se concentrer sur leur objectif et uniquement sur cet objectif. Et si quelqu’un demandait autre chose ? Elles ont des options, mais ces options incluent rarement le multitâche ou le fait de dire oui. Elles sont beaucoup plus susceptibles de dire non.
Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome. Votre équipe apprendra et s’améliorera, et contribuera à partager cet apprentissage et cette amélioration dans toute l’organisation.
Si les vraies priorités ne sont pas bien posées et comprises, l’équipe projet risque fort de travailler sur trop d’éléments en même temps et ne pas être très efficace.
How to Tell the Difference Between Rank-Order and Prioritization par Johanna Rothman
Trop de mes clients confondent deux termes spécifiques : Ordre de classement (Rank Order) et hiérarchisation. Trop souvent, cela signifie que l’équipe travaille sur trop d’éléments en même temps. Cela conduit à un en-cours élevé, à un temps de cycle court et à un faible débit.
Voici donc un visuel et une explication.
Voir la partie gauche de l’image « L’ordre de classement ». Lorsque nous classons les travaux par ordre d’ordre, nous choisissons une priorité #1, une priorité #2, une priorité #3, et ainsi de suite.
Nous ne choisissons qu’un seul élément à chaque priorité.
Oui, ce mot « priorité » fait partie du problème. Nous y reviendrons plus tard.
Comparez cette approche et cette explication avec le nombre d’organisations qui créent une « La liste priorisée » (Prioritization) (partie droite de l’image) :
Cette organisation a déclaré :
« Nous allons prioriser le travail, mais nous avons trop de travail pour vraiment faire la distinction entre chacun des éléments aux niveaux élevés, moyen et bas. Nous laisserons donc à l’équipe (ou au chef de produit) le soin de décider quand il sera temps pour eux de décider.
On dirait que l’équipe a de l’autonomie, n’est-ce pas ?
Pas si vite.
Cette équipe a trois éléments prioritaires « Forts». Selon la taille de chaque article, cela peut représenter l’équivalent d’un trimestre entier de travail. Ensuite, l’équipe a six éléments prioritaires « Moyens ». Combien de temps cela prendra-t-il ? Aucune idée.
Pire, l’équipe a 12 articles prioritaires « Faibles ». celle-ci peut aussi être une liste infinie.
Parlons de la « priorité » et de ce que cela signifie.
Ce que signifie la priorité
Lorsque nous disons « prioriser », nous sommes censés répondre à cette question : « Quelle est la préséance de cet élément par rapport à tous les autres éléments ? »
Lorsque nous classons le travail, avec un élément à chaque rang, nous pouvons le dire.
Mais lorsque nous classons le travail avec Fort, Moyen et Faible, nous commençons à peine à classer le travail. Si nous autorisons plusieurs articles à chaque rang (comme je le vois chez mes clients), nous n’avons pas terminé la hiérarchisation. Pire encore, certaines techniques pour décider quel travail faire maintenant, comme MoSCoW, aggravent encore la situation. (MoSCoW signifie : Must, Should, Could, Would.)
Lorsque nous priorisons plusieurs éléments à la fois, nous pouvons nous retrouver dans une très mauvaise situation avec beaucoup trop de WIP (travail en cours / en-cours).
Il y a des années, l’un de mes clients a commencé avec Fort, Moyen et Faible. Mais Fort n’était pas assez élevé, alors ils ont ajouté « Vraiment Fort ». Puis, « Ultra Fort ». Oui, ils ont commencé à utiliser « Mega Fort » quand je suis arrivée.
Les managers l’ont fait parce que l’équipe avait tellement d’en-cours que leur débit était assez faible. Voir la newsletter Flow Metrics.
J’ai demandé à tous les managers de créer silencieusement une liste classée de tous ces fiches d’éléments de travail avec une seule liste de fiches sur la table. Ils n’ont pas pu se mettre d’accord. Je leur ai donné trois minutes, et quand Buzz a été en désaccord avec Woody pour la troisième fois, je les ai arrêtés. Nous avons discuté du problème, et je leur ai présenté l’ordre de classement.
Ils pouvaient tous s’entendre sur les trois premiers éléments de leur liste beaucoup trop longue. C’était suffisant pour que l’équipe commence à travailler et à livrer. Ils doivent classer le travail, pas le hiérarchiser.
Classement du travail
Certains de mes collègues agiles recommandent qu’une équipe puisse commencer à répartir le travail entre Fort, Moyen et Faible. Mais cela en vaut-il la peine alors que si peu d’équipes atteignent les niveaux Moyen et Faible ? (Ou l’un des autres termes de hiérarchisation employé ?)
Pire encore, le chef de produit ou l’équipe n’a pas vraiment la capacité de dire « non » à l’un ou l’autre des éléments de travail. Cela signifie que l’équipe n’a pas l’autonomie nécessaire pour décider.
C’est pourquoi je recommande à l’équipe de classer le travail. Vous pouvez utiliser le temps de cycle ou compter le nombre de stories que votre équipe termine généralement dans un sprint. Ne classez – et planifiez – que pour ce nombre d’histoires. Ensuite, l’équipe sait ce qu’elle est censée faire maintenant. Cela permet au chef de produit de réduire les options pour le travail suivant.
J’aimerais que le classement et la hiérarchisation signifient la même chose. Trop d’organisations ne traitent pas ces deux activités de la même manière. Au lieu de cela, classez le travail avec un élément #1, un élément #2, etc. car cela vous permettra de limiter le WIP et de terminer le travail.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici deux descriptions pratiques de user stories efficaces que chaque équipe devrait connaître.
Les 3 C (par Ron Jeffries)
Une bonne user story a 3 C :
Carte – Une courte description écrite utilisée pour la planification et le suivi.
Conversation – Dialogue qui ajoute de la profondeur et de la compréhension à l’histoire.
Confirmation – Tests et critères d’acceptation qui vous indiquent quand l’histoire est terminée.
Ces trois éléments permettent de s’assurer que vos histoires sont exploitables et alignées sur la compréhension de l’équipe.
INVEST (adapté de Bill Wake)
Cet acronyme décrit six qualités des user stories fortes :
Indépendante – Autonome, ne dépend pas des autres histoires.
Négociable – Souple, pas un contrat rigide.
Valeur – Offre une valeur claire aux utilisateurs ou aux parties prenantes.
Estimable – Suffisamment compréhensible pour être estimée avec précision.
Dimensionnée de manière appropriée – Les stories devront éventuellement être suffisamment petites pour un sprint, mais doivent être dimensionnées à la hausse ou à la baisse, en fonction de leur position dans le backlog.
Testable – Dispose de critères clairs pour que l’équipe sache quand c’est terminé.
Il n’est pas nécessaire que toute les User Stories atteignent les 6 objectifs, mais celles situées en haut de l’arriéré devraient s’en approcher.
Gardez ces cadres de travail dans votre boîte à outils. Ils sont simples, pratiques et peuvent sérieusement améliorer la qualité de votre backlog et vous aider à réussir avec agile.
P.S. Vous cherchez des exemples de user stories à partager avec votre équipe ? J’ai rassemblé 200 échantillons de user stories de l’un de mes premiers projets Scrum. Certains ne sont pas ceux que j’écrirais aujourd’hui, mais j’ai noté lesquels, et pourquoi.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Chaque élément a un objectif spécifique et contribue à la valeur globale et aux résultats obtenus avec Scrum. Ce pack d’extension continuera d’évoluer régulièrement à l’avenir.
Ce document suppose d’être familier de Scrum et son langage associé, donc relisez le Guide Scrum 2020 avant de prendre en main ce document.
Ce pack d’extension est conçu pour traiter de tous les aspects de la livraison du produit par une équipe autogérée motivée par les besoins des parties prenantes en réponse à un problème ou une opportunité.
Bien qu’il soit à l’origine ancré dans le développement de produits logiciels, Scrum a été largement adopté dans divers domaines, pour générer de la valeur par le biais d’un travail collaboratif complexe. Au fur et à mesure que son utilisation se développe, des professionnels tels que des ingénieurs, des programmeurs, des chercheurs, des analystes, des avocats, des spécialistes du marketing et des scientifiques appliquent de plus en plus Scrum avec succès à leurs domaines.
Bonnes lectures (estivales et studieuses) !
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Scrum est un cadre de travail léger et centré sur l’équipe qui permet de résoudre des problèmes complexes et de générer de la valeur. Volontairement incomplet, Scrum est conçu pour être construit par l’intelligence collective des personnes qui l’utilisent.
Fondé sur l’empirisme et la pensée Lean, Scrum permet aux équipes de travailler élégamment, en s’adaptant aux exigences changeantes, tout en générant de la valeur pour l’utilisateur, tôt et fréquemment. Pour que cela réussisse, ceux qui mettent en œuvre Scrum doivent travailler avec focus et incarner certaines valeurs, y compris, mais sans s’y limiter, l’engagement, l’ouverture, le respect et le courage.
Le travail est effectué en courts « sprints », généralement d’une durée d’une à quatre semaines. Le sprint est le battement de cœur de Scrum, créant du rythme et permettant d’obtenir un retour rapide.
La mise en œuvre efficace de Scrum nécessite que les éléments suivants soient clairement établis.
L’équipe Scrum
L’unité fondamentale de Scrum est un petit collectif interfonctionnel autogéré avec trois responsabilités.
Développeurs : (3 à 8) personnes aux compétences différentes, qui créent en collaboration un incrément de valeur à chaque sprint.
Product Owner (PO) : (1) la voix du business ; le PO maximise la valeur du produit en parlant avec les clients, en fixant des objectifs de produit clairs et en manageant le backlog du produit.
Scrum Master : (1) agent de changement organisationnel ; s’assure que Scrum est appliqué efficacement et favorise un environnement propice à l’apprentissage continu et à la croissance personnelle.
Une remarque sur la mise à l’échelle : Si l’équipe devient trop grande, les développeurs doivent se réorganiser en plusieurs équipes cohésives, chacune se concentrant sur le même produit. Par conséquent, ils doivent partager le même objectif de produit, le même backlog de produit et le même product owner.
Engagements
Un objectif clair dirige le travail et rend l’intention visible à tous.
Objectif du produit : Décrit un état futur du produit : un engagement à donner une direction claire.
Sprint Goal : Un tremplin concret vers l’objectif du produit : un engagement envers la valeur incrémentale.
Définition de Done : Un engagement envers la qualité pour tous les éléments de travail.
Artefacts
Ces éléments apportent de la transparence. Chacun d’entre eux est revu régulièrement lors d’un ou plusieurs des événements Scrum.
Backlog de produit : Une liste évolutive et ordonnée d’articles, engagée dans l’objectif du produit ; ce backlog est régulièrement affiné et mis à jour.
Backlog de sprint : Eléments sélectionnés du backlog et plan d’action validés pour atteindre l’objectif du sprint.
Incrément : Eléments du backlog terminés qui concrétisent l’objectif du sprint et répondent à une définition convenue de Done.
Événements
Il y a trois événements de sprint, un événement quotidien et un méta-événement contenant les quatre autres. Ces événements permettent d’effectuer des inspections et des adaptations sur une base régulière, à différents niveaux de granularité.
Sprint : Une période de temps précise pour le travail et les quatre événements d’alignement ; le cœur de Scrum où les idées sont transformées en valeur.
Planification du sprint : Au début de chaque sprint. Le product owner et les développeurs définissent l’objectif du sprint et sélectionnent les éléments du backlog ; les développeurs peuvent créer une liste de tâches.
Daily Scrum : A lieu tous les jours ouvrables, idéalement à la même heure et au même endroit. Une courte conversation avec les développeurs pour inspecter/adapter le backlog de sprint au service de l’objectif du sprint.
Revue de sprint : A la fin de chaque sprint. Les parties prenantes inspectent l’incrément et offrent des commentaires ; l’équipe Scrum peut mettre à jour le backlog du produit.
Rétrospective de sprint : A lieu immédiatement après la revue de sprint. L’équipe Scrum repense au sprint et identifie les changements pour améliorer son efficacité.
Note de fin
Scrum est un conteneur d’agilité, invitant à d’autres techniques, méthodologies et pratiques. Le cadre de travail Scrum, adopté de manière holistique, permet aux équipes d’inspecter, d’adapter et de livrer des produits de valeur dans des environnements complexes.
Un guide simple de Scrum a été compilé par Tobias Mayer, inspiré par Bob Hartman, et avec des conseils, des suggestions et des orientations de membres de la communauté professionnelle Scrum, notamment Björn Jensen, Hector Feliciano, Joachim Atunwa, Joel Bancroft-Connors, Marcelo Lopez, Mike Vizdos, Natasha Baisiwala, Nick Perry et Tariq Juneja, à qui nous adressons nos remerciements.
Un guide simple de Scrum est une version abrégée et modifiée du Guide Scrum officiel, de Ken Schwaber et Jeff Sutherland, qui reste la source de vérité pour Scrum. Cette version résume et réorganise le contenu, mais n’ajoute pas de nouveaux éléments, ni ne supprime rien d’essentiel. Ce travail est conforme à la licence Attribution Share-Alike de Creative Commons, établie par le Guide officiel Scrum, 2020. Vous êtes libre d’utiliser le contenu comme vous le souhaitez, mais il vous est conseillé de lire l’accord original Scrum Guide Creative Commons et de le respecter.
Dans cette vidéo, Leticia Gasca demande aux leaders d’entreprises de s’ouvrir au sujet de leurs échecs, et plaide en faveur du remplacement de l’idée d’échouer rapidement par un nouveau mantra : Échouer consciemment.
Disponible avec sous titrages en français si vous préférez.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Très souvent, les gens s’attendent à ce que les changements se produisent instantanément. Mais les changements demandent du temps et des efforts continus dans la durée.
The Power of Continuous Improvement par Zuzi Sochová
Très souvent, les gens s’attendent à ce que les changements se produisent instantanément. Ils sont impatients, ils veulent tout maintenant. Mais les changements demandent du temps et des efforts.
Le changement n’est certainement pas une activité simple ; Cela ne se passe jamais comme vous l’avez prévu.
Pour réussir le changement dans votre organisation, vous devez être créatif, innovant et ludique. Et en plus de cela, vous devez être patient. L’une des raisons pour lesquelles j’aime Scrum, c’est qu’il est incrémentiel et itératif non seulement dans la création de valeur pour les clients, mais aussi dans sa propre mise en œuvre. Étape par étape, vous déterminez ce que signifie être agile pour nous, comment utiliser Scrum et comment vous devez mettre en œuvre les différents artefacts et événements. Il n’y a pas de recette de cuisine, vous devez trouver votre propre chemin.
Au début, ne cherchez pas la perfection, commencez simplement par tout ce qui est suffisamment bon. Vous devez avoir une équipe qui peut apporter au moins une sorte de valeur limitée. Une équipe qui a une chance de devenir au moins un peu interfonctionnelle. Une équipe qui, au fil du temps, peut prendre en charge la responsabilité et l’appropriation et devenir autogérée. Une fois que vous avez ce point de départ, une équipe prête à essayer, tout ce dont vous avez besoin est d’inspecter fréquemment et de vous adapter progressivement. De petites, petites itérations. À chaque itération, vous découvrez ce qui fonctionne et le faites rester ; Chaque itération révèle ce qui doit être amélioré et propose une étape exploitable pour le prochain sprint afin de l’améliorer. Il n’est pas nécessaire que ce soit un grand changement, bien au contraire. Les petits pas fonctionnent généralement beaucoup mieux. De cette façon, ils peuvent être essayés en toute sécurité et sont plus susceptibles de se produire. Ils n’ont pas l’air de pouvoir changer le monde instantanément, mais si vous regardez en arrière où vous étiez il y a six mois, vous vous rendez compte que vous avez fait un grand pas.
Dans l’ensemble, je dirais que si vous ne retirez rien du cadre de travail Scrum hormis les rétrospectives, que vous les faites régulièrement et que vous vous assurez qu’elles apportent des changements progressifs, vous vous retrouvez à un stade bien meilleur que vous ne l’avez été auparavant.
Être agile, c’est être adaptable.
Soyez créatif et allez-y une étape à la fois. Jouez avec le changement. Un changement progressif est la pratique clé qui peut vous rendre vraiment agile. Ce n’est pas une question d’outils. C’est une façon différente de penser, et les changements progressifs sont un élément clé de cette nouvelle façon de penser et d’aborder les choses.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
« Tout est une question d’arriéré de produit (Product Backlog). Le Product Owner doit le gérer. Donnez-lui la priorité. Remplissez-le de User Stories. »
Cela vous semble familier ? À certains stades de la transformation agile, il est typique de se concentrer sur la construction d’un arriéré ou backlog de produit. Et d’utiliser Jira pour cela. Vous trouverez de telles listes linéaires de tâches dans presque toutes les organisations au début de leur parcours agile. Et bien que le Product Backlog soit un outil très important car il apporte de la clarté et aligne les gens autour des mêmes objectifs business, c’est aussi l’un des outils les plus mal compris et les plus mal utilisés.
Cela part souvent par une bonne intention, le Product Owner demandant aux clients ce qu’ils veulent. Et ils réfléchissent à toutes les fonctionnalités possibles que vous pouvez imaginer, dans une bonne intention. Et le backlog/contenu ne cesse de croître alors que les attentes en matière de délais restent les mêmes. C’est le début très fréquent d’une grande déception avec Agile.
« Cela ne nous a pas aidés. Ce n’est pas plus rapide ! » disent les gens, et ils ont raison.
L’agilité n’est pas le moyen de fournir plus de fonctionnalités plus rapidement. Bien au contraire. C’est un moyen d’obtenir plus rapidement une valeur business plus élevée, et ce sont là deux choses différentes.
Donc, si vous voulez obtenir plus de valeur business, commencez par le backlog.
Mais cette fois-ci, vous ne demandez pas ce que vous voulez mettre en œuvre, mais plutôt les besoins et recherchez une fonctionnalité minimale à mettre en œuvre pour satisfaire ces besoins. 80 % de la valeur réside dans 20 % de la fonctionnalité et c’est exactement ce qu’un bon Product Backlog doit identifier. Les objets de plus grande valeur en premier, le reste plus tard ou jamais.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Un bon Product Backlog est co-créé en collaboration avec le client, les parties prenantes et les membres de l’équipe. Ils doivent tous découvrir les besoins de l’entreprise. Ils doivent tous développer une empathie pour les clients. Dans la plupart des cas, le Product Backlog qu’ils créent ensemble n’est pas une liste linéaire qui s’adapterait à des outils traditionnels comme Jira ou Excel, mais très souvent, nous utilisons la technique du Story Mapping pour créer des cartes multidimensionnelles, ou la technique de cartographie d’impact pour créer une carte mentale, ou visualiser le produit sous forme d’arbre et élaguer les branches. Rien qui ressemblerait à une liste linéaire de choses à faire.
Toutes les techniques ont une chose en commun ; Elles se concentrent sur la valeur commerciale et les besoins du client. Elles ne décrivent pas la solution.
Le comment dans Scrum doit être découvert lors du Sprint en collaboration d’équipe. Alors :
Oubliez les exigences, arrêtez de demander à vos clients ce qu’ils veulent, et concentrez-vous plutôt sur la découverte de leurs besoins et visualisez ensemble la valeur dans votre Product Backlog.
partagez ce billet avec vos amis, collègues et relations professionnelles
Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, mais certaines fois vous pourriez découvrir une chose qui est en train de tourner en mauvaise habitude.
#1 – Si vous voulez une garantie, achetez un grille-pain.
Mon premier conseil sur la façon de manager le travail inachevé est : Rappelez-vous que même les meilleures équipes agiles ratent parfois leurs objectifs. C’est OK et même souhaitable dans une certaine mesure.
Les objectifs de sprint ne sont pas garantis. (Comme le dit le personnage de Clint Eastwood, Nick Pulovski, dans The Rookie, « Si vous voulez une garantie, achetez un grille-pain ! »). Les dirigeants, les parties prenantes et même l’équipe elle-même peuvent avoir besoin d’un rappel occasionnel à ce sujet.
L’engagement d’une équipe envers un objectif de sprint est une promesse de faire de son mieux pour atteindre cet objectif. Si les membres de l’équipe sont perpétuellement contraints de donner une garantie, ils garantiront moins pour être en sécurité.
Parfois, une équipe a besoin de donner une garantie. Il peut arriver qu’un client ait besoin d’une fonctionnalité à une certaine date. Le groupe financier peut avoir besoin d’exécuter des rapports de fin d’année au début du mois de janvier, par exemple.
En général, cependant, nous ne voulons pas forcer une équipe à donner une garantie. Nous demandons à une équipe de s’engager dans quelque chose de raisonnable, puis nous comprenons si elle n’y parvient pas. Ne pas réussir occasionnellement n’est pas un échec, c’est généralement un signe de malchance ou d’une équipe qui s’efforce d’en faire trop.
#2 – Ne reportez pas le travail au prochain sprint automatiquement.
Mon deuxième conseil est : Résistez à l’envie de reporter automatiquement le travail inachevé au prochain sprint. Mettez-le plutôt dans le backlog du produit.
L’item peut être de retour dans le backlog du produit pendant une milliseconde, mais le product owner doit décider consciemment de continuer à travailler dessus.
(D’un point de vue logistique, je me fiche qu’il soit plus facile dans l’outil de votre choix de déplacer l’élément vers le sprint suivant plutôt que vers le backlog du produit en premier. L’essentiel est qu’il y ait une vraie décision de poursuivre le travail.)
Si le Product Owner décide que l’équipe doit travailler sur l’élément partiellement fini immédiatement lors du prochain sprint, importez l’élément du backlog de produit tel quel. Ne le réestimez pas. Ne le renommez pas. Ne prenez pas de crédit de vélocité partielle. Il suffit de mettre l’élément dans le sprint suivant et de prendre le crédit complet lorsqu’il est terminé.
Mais si l’article est reporté à plus tard, allez-y et divisez l’histoire en ce qui a du sens. Prenez un crédit partiel de vélocité pour le travail que vous avez effectué lors du dernier sprint, puis rédigez une nouvelle histoire qui décrit uniquement les fonctionnalités manquantes et estimez cette histoire.
#3 – Documentez la cause.
Mon dernier conseil pour manager le travail inachevé est le suivant : A chaque fois qu’un travail est inachevé à la fin d’un sprint, l’équipe doit prendre le temps de la rétrospective pour déterminer si ceci était évitable.
Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, comme un membre de l’équipe malade ou un problème découvert tard dans le sprint qui n’aurait pas pu être détecté plus tôt. Parfois, c’est juste le résultat d’une cible trop élevée pour un sprint.
Mais vous pourriez découvrir quelque chose qui devient une mauvaise habitude.
Quelle qu’en soit la cause, il est toujours utile de se demander si quelque chose peut être fait pour éviter que cela n’affecte les sprints futurs afin que votre équipe puisse réussir avec l’agilité.
Le rapport AI4Agile Practitioners 2026 inclut des analyses détaillées des réponses par rôle, taille d’organisation et niveau d’agilité. Vous y découvrirez une analyse qualitative complète des défis, préoccupations, réussites et priorités.
DantotsuPM.com 