Étiquette : scrum

Pourquoi les équipes intelligentes se sur-engagent et les leaders aggravent la situation.

Le par mopertodans agile, best practices, leadershipLaisser un commentaire

Cet article s’adresse aux leaders qui souhaitent des plans honnêtes de la part des équipes sans les pousser à une fausse certitude.

Why Smart Teams Overcommit And How Leaders Make It Worse par Mike Cohn

https://www.mountaingoatsoftware.com/blog/why-smart-teams-overcommit

La plupart des équipes n’ont pas besoin d’un leader pour les pousser à s’engager un peu trop.
Elles le font généralement d’elles-mêmes.

Cela peut sembler surprenant. Nous pensons souvent que les développeurs logiciels sont sceptiques ou cyniques. Mais d’après mon expérience, les développeurs sont souvent très optimistes. Ils croient en l’amélioration des choses. Ils ont vu comment la technologie peut améliorer des vies et transformer les entreprises. Cet optimisme fait partie de ce qui les rend bons dans ce qu’ils font.

Cela transparaît aussi dans leurs estimations.

Demandez à une équipe de choisir ce qu’elle peut faire en un sprint, en un trimestre ou d’ici la fin de l’année, et la plupart des équipes en choisiront un peu trop. Parfois, beaucoup trop.

Cela ne veut pas dire que ses membres sont négligents. Cela signifie qu’ils sont humains.

Et c’est précisément pour cela que les leaders doivent faire preuve de prudence. Si une équipe a déjà tendance à trop s’engager par elle-même, toute pression supplémentaire venant d’en haut peut pousser cette équipe à s’engager vraiment dramatiquement.

Je l’ai appris à mes dépens au début de ma carrière. Quand j’ai été promu pour la première fois à la tête d’une équipe, je pensais que les délais seraient assez simples à tenir. Ma philosophie de management, si on peut appeler ça ainsi, était la suivante : demander des estimations aux membres de l’équipe, supposer que ces estimations sont optimistes, puis tenir les gens à leurs propres estimations optimistes.

Cela n’a pas marché.

Le problème n’était pas que mon équipe était irresponsable. Le problème, c’est que je traitais l’optimisme comme un contrat.

Les équipes sont déjà optimistes.

C’est la première chose que je veux que les leaders comprennent : l’excès d’engagement commence généralement avant même qu’un leader ne prononce une parole.

Les équipes logicielles élaborent souvent des plans raisonnables basés sur des informations incomplètes. Elles font de leur mieux. Elles regardent le travail devant elles. Elles font des suppositions sur ce qui se passera bien. Elles imaginent un parcours pour réaliser ce travail et estiment en fonction de ce parcours.

C’est normal.

Mais parce que ses membres sont optimistes, l’équipe penche souvent vers le meilleur ou le presque meilleur scénario sans s’en rendre compte. Et parce que le travail logiciel comporte de l’incertitude, même un plan sensé peut échouer.

Prenez l’exemple de devoir traverser la ville en voiture pour vous rendre à un rendez-vous. Vous considérez la distance, l’heure de la journée et la circulation habituelle. Vous en concluez que 30 minutes suffisent, et la plupart du temps vous avez raison. Mais un jour, un incident bloque les voies pendant 10 minutes, et soudain vous êtes en retard.

Votre estimation n’était pas stupide. C’était la meilleure estimation. Ça a juste échoué dans ce cas-là à cause de la malchance.

La même chose arrive aux équipes.

Parfois, une équipe planifie vraiment mal. Mais parfois, l’équipe choisissait le résultat le plus probable et se ratait tout de même parce que l’incertitude apparaissait sous une forme peu prévisible.

Les leaders doivent faire de la place à cette réalité.

Comment la pression du leadership pousse les équipes à s’engager trop.

Parce que les équipes sont déjà optimistes, cette pression du management compte plus que ce que beaucoup de leaders réalisent.

Parfois, les leaders exercent une pression intentionnelle. Ils en veulent plus, ils le veulent plus tôt, et ils le disent directement.

Mais la pression apparaît aussi de façon involontaire.

Un leader peut créer de la pression avec une question, un ton de voix, ou même un langage corporel. J’ai travaillé une fois avec une leader nommée Erin, qui était une personne vraiment positive et dynamique. En traversant le bureau, elle saluait les gens avec des questions comme :

« Vas-tu produire beaucoup de livrables aujourd’hui ? »

Elle ne voulait rien faire de mal en disant cela. En fait, sa plus grande préoccupation était la qualité. Elle voulait que l’équipe ralentisse suffisamment pour bien travailler. Mais ce que l’équipe entendait, c’était une pression quotidienne sur la productivité.

Quand je lui ai fait remarquer, elle a changé son salut pour quelque chose de volontairement ridicule :

« Resteras-tu « bug free » aujourd’hui ? »

Ce petit changement comptait. Cela montrait ce qui comptait vraiment pour elle. Et parce que c’était presque humoristique, cela a brisé l’ancien schéma.

Cet exemple reste gravé dans ma mémoire car il montre à quel point il est facile pour les leaders de communiquer une chose et d’être entendus d’une autre manière.

Même un simple « Comment ça se passe ? » peut être perçu comme une mise sous pression si les membres de l’équipe l’entendent comme « Dis-moi que tu es dans les délais. »

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Ce que la pression fait aux équipes.

La pression ne supprime pas l’incertitude. Elle change la façon dont les équipes se comportent face à l’incertitude.

Lorsque les équipes ressentent de la pression, elles ont tendance à choisir leur estimation la plus optimiste plutôt que la plus réaliste. Elles deviennent moins enclines à exposer les risques. Elles cessent de chercher trop attentivement ce qui pourrait mal tourner, en partie parce que découvrir de mauvaises nouvelles devient inconfortable.

Les risques ne disparaissent pas. Ils passent simplement sous le tapis.

C’est l’un des effets les plus dangereux de la pression. Cela ne fait pas que déformer ce que disent les équipes. Cela déforme ce qu’elles sont prêtes à considérer.

Parfois, la pression pousse aussi les équipes à allonger les heures de travail. En cas de véritable crise, travailler un peu plus cette semaine peut être acceptable. Mais ce n’est pas une stratégie à long terme pour une productivité durable. Un effort excessif prolongé entraîne de la fatigue, des erreurs et une qualité inférieure.

Et une fois que la qualité commence à décliner, les équipes aggravent souvent la situation en se pressant. Ils commencent à dire des choses comme : « On nettoiera ça plus tard » ou « On peut faire ça dans un autre sprint. »

L’urgence est acceptable. Se précipiter ne l’est pas.

J’aime la distinction souvent attribuée à John Wooden :

Soyez rapide, mais ne vous pressez pas.

C’est exactement ce que les leaders devraient attendre des équipes. Avancez avec énergie, mais pas dans la panique.

Prévisions vs. Plan vs. Engagement.

Une des raisons pour lesquelles les leaders et les équipes ont des ennuis est qu’ils utilisent les mêmes mots pour signifier des choses différentes.

  • Une prévision est une prédiction de l’avenir.
  • Un plan est ce que nous espérons faire en fonction de cette prévision.
  • Un engagement est ce que nous sommes convaincus de pouvoir faire, avec suffisamment de marge pour que cela soit crédible.

Ces mots ne sont pas interchangeables.

Une équipe peut estimer les éléments individuels de l’arriéré de produit et, à partir de ces estimations, élaborer un plan de sprint ou des jalons sur trois mois. Ce plan peut être réfléchi, discipliné et utile. Mais il n’est toujours pas garanti.

Un engagement, c’est différent. Un engagement nécessite une marge.

Si je pense pouvoir traverser la ville en 30 minutes, c’est un plan. Si je dois vraiment m’engager à être à l’heure, je peux partir 40 minutes plus tôt. Le temps supplémentaire n’est pas une perte de temps. C’est le prix de la certitude.

Les leaders comprennent cette idée dans d’autres domaines de l’entreprise. Une société peut prévoir en interne des bénéfices de 5$ par action. Mais lorsqu’elle communique vers l’extérieur, elle peut s’engager de manière plus prudente à 4,50$. Même entreprise, mêmes leaders, même réalité. Ils comprennent que l’engagement nécessite de la marge si les choses devaient mal tourner.

Le développement logiciel ne fait pas exception.

Donc oui, les leaders peuvent demander des engagements. Ils peuvent demander un engagement pour un sprint, une fonctionnalité ou un objectif sur plusieurs mois. Mais ils doivent reconnaître que la portée sur laquelle l’équipe va s’engager doit être plus petite que la portée planifiée, et la portée planifiée doit généralement être plus petite que la portée optimiste.

Comment l’ancrage pousse les équipes à un sur-engagement.

L’une des façons les plus courantes dont les leaders provoquent un sur-engagement est l’ancrage.

L’ancrage se produit lorsqu’un leader formule la réponse avant que l’équipe n’ait fait sa propre réflexion.

Un leader demande :

« Pouvez-vous livrer ces fonctionnalités en trois mois ? »

Ça semble assez innocent. Mais ce n’est pas neutre. L’équipe a désormais entendu à la fois la quantité de travail et le délai souhaité. Ses membres savent quelle réponse le leader espère. Ils veulent être utiles. Ils veulent plaire aux gens. Ainsi, au lieu de déterminer en toute indépendance ce qui est réaliste, ils commencent à chercher un chemin vers le oui.

Je l’ai vu très clairement il y a des années, lorsque j’étais vice-président du développement dans une société cotée. Mon patron a demandé si un certain produit pouvait être livré d’ici la fin de l’année. Nous avions besoin de revenus pour l’année en cours, et ce produit pourrait aider.

Je suis retourné avec mon équipe et j’ai élaboré le plan. Notre réponse initiale était quelque chose comme mi-février. Nous avons coupé certaines choses, révisé le plan, et réussi à obtenir un plan qui indiquait mi-décembre. Super, nous avons pensé. Nous allions répondre aux besoins business.

Ce que je n’avais pas prévu, c’est que nos clients ne nous donneraient pas de testeurs bêta disponibles en novembre et décembre. Ils étaient trop occupés. Cela a repoussé la sortie jusqu’en janvier.

Maintenant, prenez du recul et regardez ce qui s’est passé. Sur un effort de 11 mois, nous avons manqué la date cible de seulement quelques semaines. C’est en fait une assez bonne planification. Mais comme le but était de faire entrer les revenus cette année-là, le résultat a été un échec.

Et je pense que l’échec a commencé par la question.

Si mon patron m’avait demandé : « Quand est-ce qu’on peut avoir ça ? », je serais probablement revenu avec une réponse en février ou mars. Cela aurait conduit à la bonne décision business : ne pas faire le projet dans ce but de livraison avant la fin de l’année. Mais « Pouvez-vous le faire d’ici la fin de l’année ? » nous a ancrés vers une réponse souhaitée, et nous (moi) avons trouvé un moyen de presque y parvenir.

Presque ne suffisait pas.

Demandez la vérité, pas la réassurance.

Les meilleurs leaders exposent très clairement ce qu’ils demandent.

Veulent-ils une prévision ? Un plan ? Un engagement ?

Ils rendent aussi sans danger d’y répondre par la vérité.

Cette sécurité ne vient pas du fait de dire : « Donne-moi de bonnes nouvelles », elle vient du fait de poser des questions qui invitent à la réalité :

  • Quelles hypothèses faites-vous qui pourraient ne pas être vraies ?
  • Qu’est-ce qui pourrait faire dérailler ce plan ?
  • Quelles dépendances sont intégrées dans ce plan ?
  • Est-ce votre estimation optimiste, le cas le plus probable ou pessimiste ?
  • Que devrais-je savoir sur le cheminement de votre réflexion derrière tout ça ?

Ce sont des questions très différentes de celles qui impliquent : « S’il te plaît, rassure-moi. »

La différence compte. Une vérification saine n’est pas une formalité qui fait dire à l’équipe que tout va bien. Une vérification saine est celle qui aide l’équipe à révéler ce qui ne va pas bien.

Et lorsqu’un leader entend une mauvaise nouvelle, sa première réponse la plus importante peut simplement être : « Merci de me l’avoir dit. »

Cette phrase montre à l’équipe que la vérité est valorisée.

Vous voulez une version pratique de cela ?

Téléchargez Overcommitment Toolkit for Leaders. Ce kit comprend un bref diagnostic, un guide simple sur prévision, plan et engagement, et mes 10 meilleures questions de planification.

La planification devrait être un problème partagé.

C’est l’habitude de leadership que je souhaite le plus changer.

Trop souvent, les leaders considèrent la planification comme un problème réservé à l’équipe. Le leader demande un plan. L’équipe en fournit un. Puis le leader accepte ou dit, en quelque sorte : « Ce n’est pas suffisant. Tenez tout de même la date souhaitée. »

Ce n’est pas de la planification. C’est de la pression.

La planification doit être un dialogue.

Une équipe doit présenter son plan. Le leader doit reconnaître l’effort qui y a été investi. Et si le leader espérait mieux, la réponse devrait être quelque chose comme : « J’espérais plus, plus tôt. Que puis-je faire pour nous aider à y parvenir ? »

Cela change tout.

La conversation devient alors collaborative. Peut-être qu’une grande fonctionnalité pourrait être supprimée. Peut-être qu’un résultat de moindre priorité peut être déplacé à une version ultérieure. Peut-être que quelques semaines supplémentaires changent radicalement le risque. Peut-être qu’ajouter une personne aide. Peut-être que l’application mobile viendra plus tard.

Le fait n’est pas que chaque problème ait une réponse facile. L’essentiel est que la réponse ne devrait pas être entièrement imposée à l’équipe.

La planification est un problème partagé.

Le coût d’un sur-engagement répété.

Lorsque les équipes se sur-engagent à répétition, les premiers dégâts que les leaders remarquent sont généralement des objectifs manqués.

Le dommage le plus profond est la perte de crédibilité.

Si une équipe échoue à atteindre son objectif de sprint ou son jalon sprint après sprint, finalement plus personne ne fait confiance au plan suivant. C’est dur pour tout le monde. C’est difficile pour les leaders car ils cessent d’obtenir des informations utilisables. C’est difficile pour les équipes car même quand elles disent enfin la vérité, personne ne les croit.

Un sur-engagement répété apprend à l’organisation à ne plus croire en la réalité.

C’est pourquoi cette question est si importante. Il ne s’agit pas seulement de faire mieux tourner un sprint. Il s’agit de préserver la capacité d’une équipe et de ses leaders à avoir des conversations honnêtes et utiles sur la planification.

Que devraient plutôt demander les leaders

Si vous êtes un leader, voici le changement le plus simple que je puisse proposer.

Arrêtez de poser des questions qui révèlent la réponse que vous souhaitez.

Quand un leader demande : « Pouvez-vous faire cela en trois mois ? », l’équipe est déjà ancrée. Ses membres connaissent désormais la date que souhaite le leader, et de nombreuses équipes commenceront à chercher un moyen de faire en sorte que cette réponse soit oui.

Une meilleure question est : « Voici ce dont j’ai besoin. Quand pouvez-vous le livrer ? »

Laissez l’équipe répondre d’abord à cette question. Puis comparez leur réponse à votre timing espéré. Si la réponse est plus tardive que ce que vous souhaitez, ne transformez pas cela en pression. Transformez-le en une conversation.

Posez ensuite des questions comme :

  • Qu’assumez-vous qui ça se passera bien ?
  • Qu’est-ce qui pourrait faire dérailler cela ?
  • Quelles dépendances sont importantes ici ?
  • Est-ce une prévision, un plan ou un engagement ?
  • Que pouvons-nous faire ensemble pour améliorer le résultat ?

Ces questions ne réduisent pas la responsabilité. Elles l’améliorent. Elles aident les équipes à réfléchir plus clairement, à parler plus honnêtement et à planifier de manière plus crédible.

C’est ce que les leaders devraient vouloir.

Les équipes ne s’engagent pas trop parce qu’elles sont irresponsables. Elles se sur-engagent parce que l’optimisme est naturel, alors que le travail logiciel est incertain, et le comportement du leadership influence ce que les équipes se sentent en sécurité à dire.

Les meilleurs leaders ne pressent pas plus fort. Ils créent les conditions pour la vérité. Ils distinguent les prévisions des engagements. Et ils considèrent la cible ambitieuse comme un problème commun à résoudre ensemble.

C’est comme ça qu’on obtient de meilleurs plans. Et, avec le temps, de meilleurs résultats.
Vous voulez de l’aide pour mettre cela en pratique ?

Téléchargez Overcommitment Toolkit for Leaders. Cette boite à outils comprend un diagnostic rapide pour repérer les schémas de sur-engagement, un guide pour séparer les prévisions des engagements, ainsi qu’un ensemble de questions de planification que vous pouvez utiliser pour obtenir des réponses plus honnêtes de la part des équipes.

Arrêtez de dire aux professionnels comment faire leur travail !

Le par mopertodans agile, leadershipLaisser un commentaire

La majeure partie du micro-management n’est pas un problème de contrôle : c’est un échec de clarté déguisé.

Stop Telling Professionals How to Do Their Job — Commander’s Intent at Work par Stefan Wolpers

Cet article présente l’Intention du Commandant : un modèle de briefing en cinq parties qui remplace les instructions prescriptives par un objectif commun, des contraintes strictes et une marge d’adaptation.

On n’embauche pas des gens intelligents pour leur dire quoi faire.

Dans des environnements complexes, la performance dépend moins d’instructions détaillées que d’une intention claire, de contraintes strictes et d’espace d’adaptation.

Vous avez engagé des gens intelligents. Ensuite, vous leur avez écrit un scénario.

Le Sprint Backlog est rempli de tâches décomposées à l’heure près. Les critères d’acceptation ressemblent à des instructions pour assembler les meubles. Le Daily Scrum devient un rituel de reporting pour des personnes extérieures à l’équipe. L’organisation, la seule chose qui rend le travail de connaissance productif, disparaît avant même que le Sprint ne commence.

La plupart des praticiens Agile reconnaissent cela comme du micro-management. Moins comprennent pourquoi cela arrive.

Le vrai problème n’est pas le contrôle.

Le micro-management peut être un délire de pouvoir, mais la plupart du temps, c’est un échec de clarté déguisé en contrôle.

Les managers prescrivent des méthodes et des résultats parce qu’ils ne font pas confiance à ce que l’intention soit suffisamment comprise. Les gens du produit surspécifient parce qu’ils craignent que le résultat réel soit ambigu. La personne qui donne les instructions ne parvient pas à exprimer ce que signifie « bien », alors elle dicte les étapes à la place.

Cette approche n’est pas un défaut de caractère. C’est une défaillance systémique : une tentative de fabriquer la certitude en verrouillant une méthode dans des conditions où le résultat lui-même reste incertain. Dans des environnements complexes, cette approche échoue de manière prévisible. La méthode commence à se dégrader dès que les conditions changent, et dans les travaux complexes, elles restent rarement immuables.

Il existe un meilleur modèle. Il s’appelle Commander’s Intent.

Que signifie l’intention du commandant ?

L’intention du commandant est simple en concept :

Communiquez l’état final souhaité, ses contraintes et le but de la mission. Puis faites confiance aux personnes qui font le travail pour déterminer comment y parvenir, s’adaptant au changement des conditions.

Cette approche ne vise pas à militariser le travail. C’est plutôt l’inverse : décentralisez l’exécution parce que le centre ne dispose jamais d’assez d’informations dans des conditions complexes.

Et ce n’est pas du théâtre d’autonomisation. L’Intention du Commandant est très précise là où elle compte et relâchée là où elle doit l’être. La différence avec le micro-management n’est pas moins de leadership, mais un leadership différent : une réflexion plus intense au départ, une communication plus claire et une retenue délibérée sur la méthode.

Un briefing utile basé sur l’intention du commandant comporte 5 parties :

  1. Résultat : À quoi ressemble « fait (done) » ?
  2. But : Pourquoi cela est-il important maintenant ? Qu’est-ce qui est en jeu ?
  3. Contraintes : Qu’est-ce qui est non négociable ?
  4. Critères de réussite : Comment allons-nous mesurer ?
  5. Déclencheurs d’escalade : Quels signaux devraient inciter à une conversation plutôt qu’à une décision unilatérale ?

Cette structure donne aux équipes suffisamment de contexte pour s’adapter intelligemment lorsque la réalité brise le plan.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Pourquoi les équipes Agiles en ont besoin.

Scrum est conçu pour cette réalité : dans un travail complexe, l’adaptation dépend du jugement local. Le Product Owner apporte une clarté sur la valeur, les résultats souhaités et les priorités. Les développeurs décident comment transformer cette intention en un incrément fonctionnel. L’équipe Scrum s’autogère dans ces limites.

Le Scrum Guide 2020 a explicitement rendu cet engagement structurel : l’objectif de Sprint (Sprint Goal) est l’engagement pour le Sprint Backlog, et il « offre de la flexibilité quant au travail exact nécessaire pour l’atteindre ». Le Sprint Goal est l’analogue le plus proche du Commander’s Intent, mais il ne fonctionne que lorsque l’équipe comprend aussi son but, les contraintes qui l’entourent et l’espace pour s’adapter.

En supprimant cette compréhension, on obtient le Scrum Theater : une équipe qui exécute les tâches, attend l’approbation et livre exactement ce qui a été spécifié, même lorsque la réalité a déjà évolué.

Chaque coach expérimenté a vu cela se produire : une partie prenante importante dicte les détails de la mise en œuvre, et l’équipe cesse de réfléchir pour se concentrer sur être payée. La partie prenante n’a pas le contexte nécessaire pour prendre de bonnes décisions. Le même schéma se répète : l’intention floue est remplacée par une méthode prescriptive.

La même erreur, un nouvel outil.

La raison pour laquelle ce principe est important au-delà de Scrum est simple : il s’applique chaque fois que l’exécution se fait plus proche de la réalité que la planification.

Considérez combien de personnes interagissent avec les agents IA : des requêtes qui ressemblent à des tickets Jira infusés de Gherkin, avec des instructions étape par étape, un format de sortie fixe et chaque paragraphe dicté à l’avance.

Comparez 2 approches :

  1. Prescriptif : « Rédigez un article de blog de 500 mots. Utilisez trois en-têtes. Commencez par une définition de l’agilité. Incluez une liste à puces de cinq avantages. Terminez par un appel à l’action. »
  2. Basé sur l’intention : « J’ai besoin d’un billet qui mette au défi les Scrum Masters d’arrêter de confondre la conformité aux processus avec l’agilité réelle. Le public connaît le cadre. Le ton doit être direct et inconfortable. »

Le premier prompt est plus susceptible de produire un résultat générique. Le second est plus susceptible de produire quelque chose qui vaut la peine d’être lu. Cela ne signifie pas que la structure est mauvaise. Cela signifie que sur-spécifier une méthode devient contre-productif lorsque la tâche nécessite du jugement ou une adaptation.

Le schéma est le même dans les deux cas : lorsqu’un avis est requis, la clarté de l’intention combinée à la latitude dans l’exécution l’emportent sur un script trop spécifié.

La compétence d’intention du commandant.

Si vous travaillez avec Claude, vous pouvez mettre en pratique l’Intention du Commandant dès maintenant. J’ai créé une « Commander’s Intent skill » gratuite qui s’exécute comme une couche invisible de pré-exécution sur chaque tâche que vous envoyez.

Au lieu de vous demander d’écrire des instructions détaillées, il identifie quand votre intention est floue et pose les bonnes questions avant d’exécuter, tout comme le ferait un collègue avisé. Quand votre intention est déjà claire, il s’efface et produit le résultat. Téléchargez la Commander’s Intent skill et voyez la différence entre dicter la méthode et communiquer l’intention : Téléchargez le Claude Skills Pack .

Conclusion : L’intention du commandant est le modèle opérationnel.

La prochaine fois que vous rédigez un objectif de Sprint, demandez-vous :

Transmet-il l’intention, ou est-ce qu’il dicte la méthode ?

Dans les systèmes complexes, le leader qui dicte la méthode devient le goulot d’étranglement. Le leader qui clarifie l’intention crée les conditions pour l’adaptation.

1 L’intention du commandant est enracinée dans la tradition prussienne de l’Auftragstaktik (tactiques par type de mission) : les leaders communiquent leur objectif et l’état final désiré, tandis que les leaders subordonnés conservent la liberté d’exécution en fonction des circonstances.

Téléchargez le rapport AI4Agile Practitioners 2026

Le par mopertodans agileLaisser un commentaire

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.

Pour en savoir plus, téléchargez gratuitement le rapport AI4Agile Practitioners Report 2026.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Comment fournir un plan de livraison sans perdre en agilité par Mike Cohn

Le par mopertodans agileLaisser un commentaire

Les parties prenantes veulent savoir ce qui sera livré, et quand. Votre équipe veut rester agile. Alors, comment créer une feuille de route ?

C’est-à-dire un plan de livraison ou un plan de jalons sans verrouiller chaque détail ?

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.   

Pourquoi les compétences relationnelles surpassent-elles les compétences techniques dans les équipes de développement produit

Le par mopertodans agile, experience sharing, formations et certificationsLaisser un commentaire

Les compétences techniques s’estompent. Les Soft Skills se développent et profitent à tous ceux qui vous entourent.

Why Soft Skills Outlast Technical Skills on Product Development Teams par Mike Cohn

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.

 

« Think outside the box ». Détestez-vous cette expression autant que moi ?

Le par mopertodans experience sharingLaisser un commentaire

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.

Découvrez comment commencer la nouvelle année avec un backlog produit prêt à être lancé.

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,

Copyright Mountain Goat Software©

Cliquez pour vous abonner à la newsletter de Mountain Goat Software.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Des cérémonies mécaniques aux conversations agiles

Le par mopertodans agileLaisser un commentaire

Pourquoi « mécanique » n’est pas « agile ».

From Mechanical Ceremonies to Agile Conversations par Stefan Wolpers

https://age-of-product.com/mechanical-ceremonies-agile-conversations/

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.

Les certifications dans les projets

Le par mopertodans formations et certificationsLaisser un commentaire

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.

Savez-vous manager des projets d’Intelligence Artificielle ?

7 considérations clés pour la planification stratégique en période de changement.

Apprenez à partir d’exemples concrets et d’avis d’experts sur les applications de l’IA dans les projets d’infrastructure et de construction.

Si vous envisagez de passer la certification du PMI® Risk Management Professional (PMI-RMP®), voici de quoi vous aider à réussir.

Management de produit et management de projet : Le manuel de collaboration du PMI®

Quelles sont les compétences les plus recherchées en 2025 ?

Pourquoi un nouveau pack d’extension du Scrum Guide ?

Savez-vous que l’examen de business analyste ECBA évolue ?

Le nouveau rapport « Global Project Management Talent Gap » plonge en profondeur dans la compréhension de la demande de professionnels de projet qualifiés dans toutes les régions et tous les secteurs par Lenka Pincot

Équipes agiles, conflits et Thomas-Kilmann Conflict Mode Instrument (TKI).

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Dans le monde de l’agilité, les conflits font naturellement partie du parcours de l’équipe vers l’innovation et l’efficacité.

Agile Teams, Conflicts, and TKI de Zuzi Sochova

https://agile-scrum.com/2025/10/01/agile-teams-conflicts-and-tki/

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.

Apprenez-en davantage sur la transformation des organisations, du leadership et de la culture avec Agile & Enterprise Coaching. Consultez les sessions de formation Scrum et Agile sur Sochova.com. Procurez-vous un exemplaire de The Great ScrumMaster : #ScrumMasterWay et The Agile Leader : Leveraging the Power of Influence.

Ami(e)s Agilistes, connaissez-vous The Scrum Alliance Resource Library ?

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

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.

Visitez The Scrum Alliance Resource Library.


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.

Copyright © 2025 Scrum Alliance Inc.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

 

« Scrum Master en tant que coach, formateur et mentor » par Sam Adesoga

Le par mopertodans agileLaisser un commentaire

3 postures constituent le socle d’un Scrum Master efficace : Coach, Formateur et Mentor.

Scrum Master as a Coach, Teacher and Mentor par Sam Adesoga

https://samadesoga.me/posts/scrum-master-as-a-coach-teacher-mentor/

Barry Overeem, dans son article sur les 8 postures d’un Scrum Master, décrit le Scrum Master comme un coach, un formateur, un mentor, un facilitateur, un agent de changement, un éliminateur d’obstacles, un manager et un leader serviteur.

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

Développement itératif ou incrémental : Pourquoi les équipes agiles ont-elles besoin des deux ?

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Des cadres de travail agiles tels que Scrum reposent sur deux principes fondamentaux : Le développement itératif et le développement incrémental.

Iterative vs. Incremental Development: Why Agile Teams Need Both par Mike Cohn

https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

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

  1. Vous construisez et bénéficiez d’un peu de toutes les fonctionnalités : Profils, recherche, chat, etc.
  2. Vous revenez en arrière et améliorez chacun d’entre eux au cours de plusieurs cycles.
  3. Au fil du temps, l’ensemble du système est perfectionné puis, finalement, livré.

Purement incrémental

  1. 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é.
  2. Vous construisez et livrez une version parfaite d’une deuxième zone, disons la recherche. Vous passez ensuite à la suivante.
  3. Chaque fonctionnalité est parfaite avant le début de la suivante.

Itératif + Incrémental (Agile)

  1. Vous commencez avec une version de base du profil utilisateur, vous la livrez. Vous obtenez des commentaires.
  2. 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.
  3. 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.
  4. 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.

Les indicateurs de flux et pourquoi ils sont importants pour les équipes et les managers.

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche.

Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman

https://www.jrothman.com/newsletter/2024/01/flow-metrics-and-why-they-matter-to-teams-and-managers/

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 :

  1. Work InProgress (WIP), travail en cours. Tous les travaux en cours : commencés et pas encore terminés.
  2. Throughput, débit : Nombre d’éléments de travail qu’une équipe/un responsable peut effectuer par unité de temps.
  3. Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
  4. 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 la chose 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 :

Livre sur Amazon
Livre sur Amazon

Nouveau sur le Pragmatic Manager ?

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

Comment les équipes autonomes aident-elles tout le monde à apprendre et à s’améliorer ?

Le par mopertodans agile, leadershipLaisser un commentaire

Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome.

How Autonomous Teams Help Everyone Learn and Improve par Johanna Rothman

https://www.jrothman.com/newsletter/2025/05/how-autonomous-teams-help-everyone-learn-and-improve/

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.

Lu dans la newsletter de Johanna Rothman pour le mois de mai 2025 de Pragmatic Manager.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Comment faire la différence entre un ordre de classement et une hiérarchisation des besoins ?

Le par mopertodans agileLaisser un commentaire

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

https://www.jrothman.com/mpd/2025/03/how-to-tell-the-difference-between-rank-order-and-prioritization/

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.

Vous êtes-vous déjà demandé ce qui fait qu’une user story est bonne ? Par Mike Cohn

Le par mopertodans agileLaisser un commentaire

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 :

  1. Carte – Une courte description écrite utilisée pour la planification et le suivi.
  2. Conversation – Dialogue qui ajoute de la profondeur et de la compréhension à l’histoire.
  3. 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 :

  1. Indépendante – Autonome, ne dépend pas des autres histoires.
  2. Négociable – Souple, pas un contrat rigide.
  3. Valeur – Offre une valeur claire aux utilisateurs ou aux parties prenantes.
  4. Estimable – Suffisamment compréhensible pour être estimée avec précision.
  5. 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.
  6. 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.

Pourquoi un nouveau pack d’extension du Scrum Guide ?

Le par mopertodans agile, formations et certificationsLaisser un commentaire

Ce pack d’extension Scrum Guide explique le quoi et le pourquoi de chaque élément de Scrum en se projetant vers l’avenir.

L’objectif annoncé est une adoption plus réussie grâce à des conseils supplémentaires et actualisés du Guide Scrum 2020 de Ken Schwaber et Jeff Sutherland.

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.

Vidéo de présentation de ce pack.

Un guide simple de Scrum par Tobias Mayer

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Volontairement incomplet, Scrum est conçu pour être construit par l’intelligence collective des personnes qui l’utilisent.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

A simple guide to Scrum par Tobias Mayer

https://scrum.academy/guide

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.

Tobias Mayer et Bob Hartman, 21 mars 2025

Un guide simple de Scrum, v1, 21 mars 2025. Attribution et crédits. Version PDF (en anglais)

N’échouez pas rapidement, échouez consciemment.

Le par mopertodans experience sharingLaisser un commentaire

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.

Le pouvoir de l’amélioration continue

Le par mopertodans leadership, outils et méthodesLaisser un commentaire

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á

https://agile-scrum.com/2025/04/22/the-power-of-continuous-improvement/

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.