Catégorie : agile

Méthodes, retours d’expérience, bonnes pratiques

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.

« Quand arrêter d’affiner votre backlog ? » par Mike Cohn

Le par mopertodans agile, outils et méthodes, pointeurs utilesLaisser un commentaire

Lors de la refonte du backlog produit, j’utilise une question simple :

Savons-nous assez pour croire que cet article peut probablement être terminé en sprint ?

C’est tout.

Je ne demande pas si nous avons répondu à toutes les questions possibles.

Je ne demande pas si nous avons finalisé toutes les décisions de conception.

Je demande si nous avons assez de compréhension pour prendre un engagement responsable.

Si la réponse est oui, nous arrêtons d’affiner.

Si la réponse est non, nous identifions la plus grande inconnue et la résolvons avant d’introduire l’objet dans le sprint.

L’affinement n’est pas affaire de certitude. C’est une question de confiance.

Lorsque les équipes essaient d’éliminer toute incertitude, l’affinement devient pesant. Les réunions durent longtemps. L’énergie chute. Et ironiquement, la prévisibilité ne s’améliore pas.

Mais lorsque l’affinement se concentre sur ce seul enjeu « assez de clarté pour tenir dans un sprint », la planification du sprint devient plus facile et les engagements plus réalistes.

Si vous souhaitez en savoir plus loin, j’ai écrit un guide complet sur l’affinement du backlog produit.
Et si vous voulez une checklist pratique que votre équipe peut utiliser lors de l’affinage, vous pouvez la télécharger ici.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Le par mopertodans agileLaisser un commentaire

Maniaques du contrôle : pourquoi la poigne la plus serrée est-elle celle qui perd souvent le plus ?

Le par mopertodans agile, leadershipLaisser un commentaire

Le contrôle, au-delà d’un certain point, produit le chaos qu’il est justement censé empêcher.

Control Freaks: Why the Tightest Grip Often Loses the Most par Bob Marshall

https://flowchainsensei.wordpress.com/2026/02/15/control-freaks-why-the-tightest-grip-often-loses-the-most/

Il existe un type particulier d’anxiété qui hante les organisations qui développent des logiciels. Cela se manifeste par des chaînes d’approbation sans fin, des demandes pour des demandes, des commissions de revue d’architecture qui se réunissent trimestriellement, et des processus de déploiement si baroques qu’ils nécessitent leur propre équipe de documentation.

Cela vient d’un endroit raisonnable. Le logiciel est invisible jusqu’à ce qu’il tombe en panne, et quand il tombe en panne, il le fait coûteusement. Alors nous cherchons à contrôler.

Le problème, c’est que le contrôle, au-delà d’un certain point, produit le chaos qu’il est justement censé empêcher.

L’illusion de sécurité

J’ai travaillé avec une équipe qui demandait sept approbations pour déployer un seul changement en ligne. La logique était irréprochable : plus d’yeux signifiait moins d’erreurs. En pratique, cela signifiait que les déploiements étaient regroupés en livraisons massives et peu fréquentes, chacune étant une terrifiante partie de roulette russe. Quand quelque chose se cassait, personne ne savait lequel des quarante changements en était la cause.

Pendant ce temps, une équipe au bout du couloir mettait en production des dizaines de fois par jour sans aucune validation. Leur secret n’était pas l’imprudence. C’était un investissement dans les tests automatisés, les feature flags* et le retour en arrière instantané. Ils avaient remplacé la surveillance humaine par la résilience systémique.

*feature flags – Les indicateurs de fonctionnalités (également appelés commutateurs ou interrupteurs de fonctionnalités) sont des morceaux de code logique if/else utilisés pour activer ou désactiver des fonctionnalités. Ils peuvent être activés ou désactivés manuellement ou lorsque certaines conditions sont remplies.

La première équipe se sentait en sécurité. La deuxième équipe était en sécurité.

Le contrôle comme symptôme

Lorsque vous constatez un contrôle excessif dans une organisation, vous observez un symptôme plutôt qu’une solution. Creusez sous la surface et vous trouverez :

  • Peur du blâme. Dans les cultures où l’échec est puni, les gens construisent des forteresses bureaucratiques. Chaque approbation est une responsabilité répartie. Si quelque chose tourne mal, au moins sept personnes l’ont approuvé.
  • Manque de confiance. Le micro-management est un problème de confiance caché sous des processus. Si vous faites confiance à vos ingénieurs, vous leur donnez des garde-fous et de l’autonomie. Sinon, vous leur donnez des listes de contrôle et de la surveillance.
  • Absence de boucles de rétroaction. Les mécanismes de contrôle se multiplient lorsque les organisations ne peuvent pas savoir si leur logiciel fonctionne réellement. Si vous disposez d’une surveillance robuste, d’alertes et d’un retour en arrière rapide, vous n’avez pas besoin qu’un comité approuve un changement de couleur de bouton.

Le paradoxe du couplage serré

L’architecture logicielle reflète la psychologie organisationnelle. Les équipes orientées contrôle construisent des systèmes orientés contrôle : des monolithes où chaque changement nécessite une coordination entre des dizaines de composants, des bases de données partagées qui rendent impossible un déploiement indépendant, des flux de travail d’approbation encodés dans le logiciel lui-même.

Ces systèmes semblent gérables car tout est visible et centralisé. Mais ils sont fragiles. Un point de défaillance unique devient un point unique de paralysie. L’organisation qui voulait le contrôle finit par être contrôlée par sa propre architecture.

L’alternative n’est pas le chaos : c’est un découplage réfléchi.

De petits services indépendants. Des contrats clairs. Des équipes qui livrent sans attendre l’autorisation de six autres équipes. Cela implique de renoncer au confort de tout savoir, et d’accepter que les systèmes distribués sont intrinsèquement plus difficiles à comprendre. Mais ce découplage échange un faux contrôle contre une vraie résilience.

À quoi ressemble un contrôle sain ?

Rien de tout cela ne signifie que le contrôle est mauvais. Les systèmes incontrôlés sont terrifiants à leur manière : codage de cowboy, bases de données de production accessibles aux stagiaires, déploiements qui ont lieu quand quelqu’un en ressent l’envie.

La distinction se situe entre contrôler les personnes et contrôler les résultats.

Les organisations saines s’obsèdent sur ce dernier :

  • Nous contrôlons la fiabilité en investissant dans la surveillance et la réponse aux incidents, et non en exigeant des tests manuels à chaque déploiement.
  • Nous contrôlons la sécurité en intégrant des mesures sécurisées par défaut sur nos plateformes, et non en obligeant les développeurs à remplir des questionnaires de sécurité qu’ils ne comprennent pas.
  • Nous contrôlons la qualité en recrutant bien, en fournissant un contexte clair et en créant des boucles de rétroaction rapides, pas en instituant une revue de code par des personnes très éloignées du travail.

Le but est de rendre la bonne chose facile et la mauvaise difficile. C’est un problème de conception, pas de permissions.

Lâcher prise

La partie la plus difficile pour réparer une culture obsédée par le contrôle, c’est qu’il faut que les personnes en contrôle l’abandonnent. C’est vraiment difficile à demander. Le contrôle est apaisant. L’autonomie — pour les autres — est stressante.

Mais voilà le truc : vous n’avez jamais vraiment eu le contrôle de toute façon. Vous aviez une apparence de contrôle, maintenu à un coût énorme en vitesse, en moral, et en l’attrition silencieuse de vos meilleurs éléments (qui partaient vers des endroits où on leur faisait confiance). Les réunions, les signatures, les commissions de revue, c’étaient un rituel, pas une sécurité.

La vraie sécurité vient des systèmes qui supposent que la panne va survenir et qui s’en remettent en douceur. D’équipes qui expérimentent sans permission et apprennent sans être blâmées. Des architectures qui se plient au lieu de se briser.

La poigne la plus ferme ne vous protège pas. Elle fatigue juste vos mains.

Les meilleures cultures d’ingénierie partagent un trait commun : elles sont obsédées par les résultats et décontractées quant aux méthodes. Elles précisent ce qui doit être vrai — le système doit être fiable, sécurisé, maintenable — puis s’écartent. Quand on explique aux gens intelligents à quoi ressemble le succès et qu’on leur donne les outils pour y parvenir, ils le font.

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.   

Conçue pour le changement : l’agilité d’entreprise n’est plus optionnelle !

Le par mopertodans agile, outils et méthodes, pointeurs utilesLaisser un commentaire

PMI Agile Alliance publie le Manifeste pour l’Agilité d’Entreprise.

PMI et Agile Alliance sont heureux de dévoiler le « Manifeste pour l’Agilité d’Entreprise », un guide de leadership destiné aux organisations confrontées à des perturbations fréquentes et à une pression croissante pour se réinventer.

https ://agilealliance.org/built-for-change-enterprise-agility-isn’t-optional-anymore/

https://www.linkedin.com/posts/pierre-le-manh-3a4158_enterprise-agile-manifesto-short-ugcPost-7434459654715330561-iQYb/

L’agilité de l’entreprise est la capacité à s’adapter à grande échelle sans perdre de cohérence – à décider rapidement, à rediriger délibérément les ressources et à maintenir la stratégie exploitable sous la pression réelle.  Pierre Le Manh, président et directeur général de PMI.

Téléchargez ce manifeste gratuitement

L’ambition est de révolutionner le management des entreprises et de mener des transformations à grande échelle dans un monde de disruption accélérée, avec une direction plus claire, des décisions plus rapides, des changements de ressources plus intelligents et une exécution alignée sur la stratégie.

Lancé lors du 25e anniversaire du Manifeste pour le développement logiciel agile, le Manifeste pour l’Agilité d’entreprise dépasse l’agilité au-delà des équipes et des projets à l’ensemble de l’entreprise. Cela inclut le comportement du leadership, les modèles opérationnels, la gouvernance et la culture.

Sa force vient de la simplicité : 4 valeurs et 9 principes qui rendent explicites les choix.

Même recette pour l’Agilité d’Entreprise.

Les 4 valeurs de l’Agilité d’Entreprise :

  1. Un objectif clair réalisé grâce à des plans adaptatifs. Mener avec un but clair et s’ajuster en chemin l’emporte sur la surplanification et l’illusion de contrôle.
  2. Des résultats d’entreprise partagés plutôt qu’optimisation fonctionnelle. Prioriser les objectifs à long terme et la collaboration interentreprises prime sur l’optimisation des KPIs départementaux à court terme.
  3. Réinvention continue plutôt que préservation. Remettre en question avec audace les modèles d’exploitation établis et l’innovation l’emporte sur l’inertie structurelle et la préservation du statu quo.
  4. Le centrage sur l’humain au cœur eu du changement. L’apprentissage continu, le développement de la résilience, l’autonomie et le leadership avec empathie et confiance l’emportent sur le fait de mener le changement uniquement par les processus.

Les 9 principes

Comportement de leadership

#1 – Créer une clarté d’objectif et s’aligner sur les résultats d’entreprise.
#2 – Étendre l’agilité entre partenaires et écosystèmes.
#3 – Adopter la technologie et les talents distribués.

Conception organisationnelle

#4 – Gouverner avec des garde-fous, pas des gardiens.
#5 – Financer le but et l’intention, pas l’exécution
des activités.
#6 – Concevoir pour l’adaptabilité, pas seulement l’efficacité.

Exécution

#7 – Déplacer l’autorité et la prise de décision vers le lieu où la valeur est créée.
#8 – Fournir de la valeur fréquemment et rendre le travail visible.
#9 – Percevoir tôt, apprendre vite, agir avec confiance.

Ce Manifeste est le fruit d’un travail collectif rigoureux à l’échelle mondiale.

Téléchargez-le et partagez-le aussi largement que possible.

« PMI », « Agile Alliance » et « Project Management Institute » sont des marques enregistrées de Project Management Institute, Inc.

 

Le modèle opérationnel du produit agile

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Les modèles d’exploitation traditionnels ne suffisent plus à une époque de changements constants et de complexité croissante.

The Agile Product Operating Model

https://www.scrum.org/resources/agile-product-operating-model

En combinant les idées du management de produit moderne, de la livraison agile et du management fondé sur les preuves, les organisations peuvent construire un modèle opérationnel produit clairement aligné sur leurs objectifs numériques. C’est là que le modèle opérationnel Agile des produits entre en jeu.

Le Modèle Opérationnel Agile des Produits est conçu pour aider les organisations à fournir de la valeur en continu, à s’adapter plus rapidement et à prospérer dans l’incertitude.

Le Modèle Agile de Fonctionnement du Produit (Agile Product Operating Model APOM) comprend les 4 domaines suivants :

  1. Stratégie – Le Pourquoi – Une description claire et transparente des éléments de valeur (économiques), d’entreprise, de technologie et d’exploitation.
  2. Personnes – Le Qui – Définir comment les gens sont organisés et développés, ainsi que la culture et le modèle d’incitation dans lesquels ils évoluent.
  3. Structure – Les règles et outils – La gouvernance nécessaire, la contractualisation avec des tiers, les processus et les systèmes et technologies qui les supportent.
  4. Cycle de la Valeur – Les pratiques qui permettent la découverte agile, la livraison de produits, ainsi que les opérations et le support.

The Guiding Principles of the Agile Product Operating Model: an Evidence-Based Approach

(Les principes directeurs du modèle de fonctionnement Agile du produit : une approche fondée sur des preuves).

Ce document détaille le Modèle Opérationnel Agile du Produit (APOM) et expose les principes directeurs pour aider les équipes à naviguer dans la complexité et maximiser la valeur livrée.

The Agile Product Operating Model (APOM) – an Evidence-Based Approach

(Le modèle de fonctionnement Agile Product (APOM) – une approche fondée sur des preuves.)

Ce livre blanc définit le Modèle Opérationnel Agile des Produits (APOM) et explore comment il est conçu pour aider les organisations à fournir continuellement de la valeur, s’adapter plus rapidement et prospérer dans l’incertitude.

Scrum.org provides education and certification in the field of agile development.

Pas de management de projet zombie par Alan Zucker

Le par mopertodans agileLaisser un commentaire

Les managers de projet zombies se contentent de faire semblant.

No Zombie Project Management par Alan Zucker

https://pmessentials.us/no-zombie-project-management/

Les zombies sont des morts-vivants.  Ils sont insensibles, sans vie et apathiques.  Les managers de projet zombies se contentent de faire semblant.  Ils et elles suivent les règles et les pratiques mais restent peu impliqués.

Le management de projet zombie infecte tous les types de projets.  Personne n’est à l’abri. Chefs de projet, scrum masters et responsables du développement peuvent tous devenir des zombies.  Nous menons nos projets sans comprendre « pourquoi » nous faisons quelque chose, ni nous interroger sur son efficacité.

Cet article décrit les symptômes du management de projet zombie et offre l’antidote au problème.  Le management de projet doit passer de la conformité ritualisée à des pratiques réfléchies et intentionnelles.

#1 – Trouvez les zombies

Trouver les zombies est facile.  Regardez-vous, vos collègues et votre organisation.  Souffrez-vous de l’un des symptômes suivants ?

  • L’organisation considère les standards comme des activités à cocher plutôt que comme des opportunités d’une revue réfléchie et d’une discussion significative.
  • Les équipes suivent des méthodologies prescrites sans les adapter et les exécutent ensuite sans réfléchir, échouant ainsi à produire la valeur escomptée.
  • Vous continuez à exécuter des processus inefficaces sans être interrogé.

Les zombies ont contaminé les projets traditionnels après avoir été victimes de l’idée reçue selon laquelle le respect d’un processus garantissait le succès. Cela découle de la conviction que les projets peuvent être gérés comme une usine. L’essor des outils de génie logiciel assisté par ordinateur (Computer-Assisted Software Engineering CASE) dans les années 1990 a marqué le point culminant de ce mouvement. Malheureusement, les projets sont uniques et dépendent des personnes, aucune de ces initiatives ne favorise la prévisibilité et la stabilité.

L’agilité a été infectée lorsque les équipes ont ignoré la première déclaration de valeur, favoriser « Individus et interactions par rapport aux processus et aux outils. » Mettre en œuvre des pratiques Agile sans changer la façon de travailler est la garantie de l’échec.  Les sprints qui ressemblent à des mini-cascades, des Daily Standup d’une heure, des pratiques de management de type commande et contrôle, ou des équipes non dédiées sont des anti-schémas courants avec Agile.

Ce ne sera qu’une question de temps avant qu’Hybrid ne soit lui aussi infecté. Les équipes ne parviendront pas à établir une structure et des pratiques suffisantes, et leur travail sera exécuté sans but. Réussir dans le juste milieu entre Prédictif et Agile nécessite une planification intentionnelle. Les processus et pratiques doivent être clairement définis ; sinon, le chaos s’ensuivra.

L’IA est déjà submergée par les zombies. « AI workslop » désigne des contenus de faible qualité générés par IA. Des exemples incluent des emails qui n’ont pas de sens, des graphiques contenant des données incorrectes ou fictives, ou des idées complètement absurdes.  Les gains de temps liés à l’utilisation de l’IA sont consommés par la reprise requise.  Bien que l’IA puisse automatiser de nombreuses tâches, il y a beaucoup de choses qu’elle ne peut pas faire, comme gérer les personnes.

#2 – Tuez les zombies

Stopper les zombies sera difficile. Cela nécessitera de surmonter l’inertie et de briser des habitudes bien ancrées. Des méthodologies et des cadres de travail ont été conçus pour établir des pratiques standards qui rendent les projets moins chaotiques et plus prévisibles, un objectif louable. La conséquence inattendue est la passivité. Au lieu de nous engager activement, nous sommes devenus captifs du processus.

Pour briser ce schéma, l’intentionnalité doit être intégrée comme compétence et routine fondamentales. La 8e édition du PMBOK® inclut le principe « Adopter une approche globale », qui nécessite un engagement proactif tout au long du cycle de vie du projet. La pensée systémique et l’analyse critique devraient être des compagnons permanents. Reconnaître les dépendances et relations même invisibles nous aide à « regarder dans les coins ». Comprendre le « pourquoi » derrière le projet et nos pratiques nous permet de saisir l’intention et de rester concentrés sur les « bonnes » choses.

#3 – Engagez le cerveau pensant

Des zombies ont infecté un grand contractant fédéral. Les managers de projet se sont plaints des normes prescrites, du stage-gate (points de passage de phases) et des évaluations périodiques des performances. Les équipes passent d’innombrables heures à créer des présentations et à se préparer. Cependant, les réunions sont formatées, avec des dialogues et des résultats prévisibles. Peu de valeur ou d’éclairage à en retirer.

Les entretiens avec les leaders de l’organisation ont révélé une autre histoire. Les pages du diaporama étaient recommandées mais non obligatoires. Les managers de projet et de programme devraient se sentir habilités à inciter les décideurs à fournir des analyses et des recommandations pertinentes.

Les Zombies de Complaisance ont contaminé les équipes et les critiques.  Le désengagement était le problème, pas les processus ou les normes.  Il était plus facile de faire semblant que de creuser profondément et de poser les questions difficiles.  Le remède était simple.  Moins d’informations mais plus exploitables. Changer la conversation de ce qui n’allait pas vers ce qui pourrait être amélioré.

Engager le cerveau pensant demande des efforts.  Cela nécessite de poser des questions difficiles, ouvertes et approfondies, d’examiner les hypothèses et de repérer les biais cognitifs. Attendez-vous à ce que ce soit inconfortable.

#4 – Établissez l’approche

Beaucoup de projets sont voués à l’échec avant même de commencer. L’approche et les choix du cycle de vie sont souvent faits à la légère, des options par défaut ignorent les besoins spécifiques du projet. Cela peut orienter le projet sur une mauvaise trajectoire et conduire à des pratiques incompatibles avec l’environnement opérationnel.

Le DSI d’une grande entreprise de services financiers a déclaré que 75% des projets seraient agiles d’ici la fin de l’année, ce qui pouvait être un excellent objectif ambitieux, mais c’était une décision de management Zombie.  Pour se conformer, des managers rationnels sont devenus des zombies et ont mis en place des pratiques dites agiles sur tous les projets.  Le résultat fut désastreux.  Beaucoup des anciennes applications étaient des mammouths physiquement incapables de se déplacer rapidement.

Disciplined Agile valorise la prise en compte du contexte, le fait que faire des choix est bon et le pragmatisme.  Chaque organisation, équipe de projet et projet sont uniques.  Les managers de projet doivent prendre de nombreuses décisions quant à la manière de diriger, manager et exécuter le projet.  Ces décisions doivent être adaptées au contexte, aux besoins du projet et aux options disponibles.

Évitez de tomber dans le biais cognitif de Maslow : « Si le seul outil dont vous disposez est un marteau, il est tentant de tout traiter comme un clou. »

Prenez des décisions éclairées.  Adaptez le plan de management de projet et les directives de développement requises.  Résistez, évitez le chemin de moindre résistance.

#5 – Managez le projet

Pendant la longue phase d’exécution du projet, le système immunitaire est supprimé, le rendant vulnérable aux infections.  Même les projets les mieux organisés posent des problèmes et doivent s’écarter du plan initial.  Il y a des retards, des événements imprévisibles, des conflits et, bien sûr, plus de travail que prévu.  Les risques, les problèmes et les actions commencent à être oubliés.  Passer en mode pilote automatique zombie est une réaction naturelle.

Résister à l’instinct zombie est essentiel.  Ripostez.  Restez engagés.  Engagez le cerveau.  Adoptez et adaptez.  Évitez les réactions impulsives.

La construction d’un immeuble de bureaux avait plusieurs mois de retard. Lors d’une visite de chantier, un cadre dirigeant a déclaré que la solution consistait à accélérer la livraison des matériaux de construction. Le manager de projet savait mieux quoi faire mais n’avait pas d’autre choix que de se conformer. L’accélération des livraisons a submergé la zone de déchargement, retardant des livraisons plus critiques. Certains matériaux prépositionnés ont été endommagés en raison d’un espace de stockage insuffisant.

Quand les choses se compliquent, il est temps de faire une pause, de réfléchir et d’être délibéré.  Découvrez la ou les causes profondes des problèmes.  Engagez-vous dans la pensée critique.  Interrogez les croyances et les suppositions.  Faites des ajustements réfléchis.  Ensuite, examinez les changements pour vous assurer qu’ils ont eu l’effet souhaité.

« La folie, c’est faire la même chose encore et encore en espérant des résultats différents. »

Bien que cette expression soit souvent attribuée à Einstein, on a jamais eu de preuve tangible qu’il ait jamais prononcé cette phrase.  Vérifie tes faits.  Ne sois pas un zombie.

© 2026, Alan Zucker ; Essentiels de la gestion de projet, LLC

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

« Faites le pont entre les flux de travail cliniques et la prestation Agile » par Sohail Bashir Chughtai

Le par mopertodans agile, experience sharing, leadershipLaisser un commentaire

Leçons pratiques issues de la transformation des technologies de l’information dans le domaine de la santé

Bridging Clinical Workflows and Agile Delivery

La transformation numérique dans le secteur de la santé est fondamentalement différente de celle de la plupart des autres secteurs.

Dans les banques ou la grande distribution, les erreurs système peuvent coûter cher. Dans les hôpitaux, des erreurs système peuvent affecter la sécurité des patients. La mise en œuvre d’un système de dossier médical électronique (DME) n’est donc pas seulement un déploiement informatique. C’est une initiative de changement clinique qui touche les médecins, les infirmières, les équipes financières et, en bout de ligne, les patients.

Après avoir dirigé de nombreuses initiatives informatiques en santé, notamment aux urgences (Emergency Room ER), les patients hospitalisés (Inpatient Department IPD), les modules infirmiers et les systèmes de facturation numérique, j’ai appris que la réussite de la transformation dépend d’une capacité essentielle : la capacité à relier les flux de travail cliniques avec une prestation Agile structurée.

La transformation, ce sont les personnes avant la technologie.

Les hôpitaux sont des écosystèmes complexes où l’autonomie professionnelle est profondément valorisée. Les médecins peuvent résister lorsque les systèmes augmentent le temps nécessaire pour la documentation. Les infirmières peuvent avoir du mal lorsque les formulaires numériques perturbent les routines de service établies. Les équipes financières ont besoin d’une logique de facturation traçable conforme aux normes réglementaires.

Le vrai défi est rarement la complexité technique ; C’est un alignement comportemental.

Avant de concevoir des solutions, les managers de projet doivent observer les réels flux de travail cliniques, identifier les parties prenantes influentes et traduire les points de douleur opérationnels en exigences structurées. La transformation des soins de santé réussit lorsque les utilisateurs se sentent compris plutôt que dirigés.

L’agilité dans le secteur de la santé doit être adaptée, pas copiée/collée.

Les cadres de travail Scrum classiques ne s’adaptent pas automatiquement aux environnements cliniques.

Les hôpitaux nécessitent des systèmes de production stables, en particulier dans les unités d’urgence et de soins intensifs. Les mises en production doivent être contrôlées. La documentation à des fins réglementaires et d’audit est obligatoire. Les flux de travail financiers doivent rester cohérents et traçables.

En pratique, une approche hybride fonctionne souvent mieux : une livraison agile de sprint combinée à des points de contrôle et d’approbation structurés, une documentation de conformité en parallèle et des phases de mise en service soigneusement planifiées. L’agilité dans le secteur de la santé signifie une flexibilité disciplinée, équilibrant réactivité avec sécurité et gouvernance.

Le managers de projet en tant que traducteur entre les mondes.

L’un des rôles les plus sous-estimés dans l’informatique de la santé est celui de la traduction.

Un clinicien pourrait dire : « Nous avons besoin d’une logique de facturation horaire pour les patients critiques aux urgences. » Derrière cette demande se trouvent des algorithmes de facturation basés sur le temps, des règles d’ajustement, des processus de remboursement, des traces pour les audits et des contrôles d’intégrité des bases de données.

Le manager de projet informatique de santé fonctionne entre ces différents langages professionnels. Vous devez comprendre simultanément la terminologie clinique, les contrôles financiers, l’architecture technique et les cadres de management des risques.

Vous ne gérez pas simplement la portée ; Vous connectez deux mondes distincts et vous veillez à ce qu’ils fonctionnent ensemble sans interruptions et interférences.

La gouvernance n’est pas de la bureaucratie : c’est une protection.

La gouvernance en informatique de santé est souvent perçue comme une surcharge administrative. En réalité, elle protège la confiance des patients et la crédibilité organisationnelle.

Les approbations de remboursement doivent être traçables. Les ajustements de facturation doivent préserver l’intégrité de l’audit. La documentation clinique doit être précisément alignée avec les services enregistrés. Les contrôles d’accès et les mécanismes de confidentialité des données doivent être robustes et conformes.

Des structures de gouvernance bien conçues ne ralentissent pas la transformation ; elles permettent une innovation durable et défendable.

Manager la résistance avec empathie.

La résistance dans les hôpitaux consiste rarement à rejeter la technologie en elle-même. Plus souvent, cela reflète des préoccupations liées à une charge cognitive accrue, à une perturbation des flux de travail ou à une perte d’efficacité.

Les leaders efficaces impliquent les cliniciens dès le début à travers la validation des prototypes, des pilotes au niveau départemental et des boucles de rétroaction structurées. Lorsque les professionnels de santé voient leurs connaissances reflétées dans la conception du système, l’adoption devient nettement plus fluide.

L’empathie, plus que la méthodologie, détermine le succès à long terme.

La technologie doit respecter les soins.

Les organisations de santé n’ont pas besoin de davantage de logiciels. Elles ont besoin de systèmes qui respectent le fonctionnement réel de la médecine.

La réussite de la transformation numérique nécessite une compréhension clinique, une gouvernance structurée, une prestation Agile adaptative et un leadership centré sur l’humain.

Faire le lien entre les flux de travail cliniques et l’exécution Agile n’est pas seulement une tâche technique ; C’est une responsabilité de leadership.

Lorsqu’elle est abordée avec réflexion, la transformation numérique améliore la sécurité, accroit l’efficacité opérationnelle et, en fin de compte, soutient de meilleurs résultats pour les patients.

À propos de l’auteur

Sohail Bashir Chughtai

Sohail Bashir Chughtai, PMP®, est chef de projet informatique dans le domaine de la santé avec plus de 12 ans d’expérience à la tête d’initiatives de transformation numérique dans des milieux hospitaliers. Il est spécialisé dans la mise en œuvre de DME/DES (Dossiers Médicaux Electroniques et Dossiers de Santé Electroniques) , la prestation Agile dans les systèmes de santé réglementés, l’optimisation des flux de travail cliniques et les plateformes de santé numérique d’entreprise.

Il a dirigé des équipes interfonctionnelles produisant des modules d’urgence, d’hospitalisation, d’infirmières et de facturation numérique dans des écosystèmes de santé complexes, alignant la stratégie technologique avec les opérations cliniques réelles.

En élargissant actuellement son engagement professionnel à travers l’Europe, Sohail est ouvert à la collaboration et aux opportunités de leadership dans la transformation informatique de la santé, la stratégie de santé numérique et le management de projets d’entreprise sur le marché européen.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

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.

 

Les synergies sont impératives entre le management de projet et le management de produit.

Le par mopertodans agile, best practicesLaisser un commentaire

« Les doubles motorisations du succès dans les projets » par PMI® Europe

Près de 40 % des projets actuels sont directement liés au développement de produit, pourtant de nombreuses équipes continuent d’opérer en silos.

Project Management Institute® vous aide à adopter l’état d’esprit d’aligner la livraison agile sur l’ensemble du cycle de vie du produit, garantissant que chaque résultat apporte une valeur qui vaut l’effort et le coût.

Prenez le leadership pour mener la transformation et aller au-delà de l’exécution pour atteindre le succès à long terme. Explorer ces enseignements pour mener la transformation.

“PMI” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

La simplicité, c’est PLUS de travail.

Le par mopertodans agileLaisser un commentaire

On ne peut rien enlever sans itération.

Simplicity is more work par Maarten Dalmijn

https://mdalmijn.com/p/simplicity-is-more-work

Cette phrase du manifeste Agile est souvent mal comprise :

« La simplicité — l’art de maximiser la quantité de travail non accomplie — est essentielle. »

Résumer la simplicité à atteindre simplement à « ne PAS faire le travail » est trompeur. La simplicité, ce n’est pas seulement « Vous n’en aurez pas besoin » (YAGNI : You Ain’t going to Need it).

La simplicité signifie PLUS de travail. Il est plus difficile de simplifier que de ne rien faire et de laisser les choses compliquées. La première version n’est presque jamais la version la plus simple.

Garder les choses simples signifie faire un travail acharné puis en faire encore plus pour éliminer votre travail acharné.

La simplicité est difficile car nous détestons retirer et perdre ce dans quoi nous avons mis tout notre cœur et notre âme.

Alors, facilitez-vous la tâche en n’ajoutant pas d’éléments inutiles dès le départ.

Mais ne vous laissez pas tromper : Quoi que vous fassiez, la simplicité ne sera pas facile.

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.

« Code is not enough » : Ce que l’entrepreneuriat a appris à Hafid Idrissi, un jeune ingénieur sur la Gestion de Projet

Le par mopertodans agile, experience sharingLaisser un commentaire

Projet réussi = Code propre + architecture élégante + patterns complexes + technologies de pointe ?

En sortant de l’école d’ingénieurs en 2024, ma vision de l’informatique était académique, précise et technique. Pour moi, un projet réussi était synonyme de code propre, d’architecture élégante, de patterns complexes et de technologies de pointe.

Le reste — le respect des délais, la gestion du budget, la relation client ou la conduite du changement — me semblait être une couche administrative nécessaire mais secondaire, voire une distraction.

Puis, je me suis lancé en tant qu’entrepreneur indépendant et professionnel libéral. La réalité du terrain m’a offert une leçon d’humilité immédiate. J’ai compris qu’en 2026, l’excellence technique ne suffit plus. Un code parfait qui ne répond pas au besoin ou qui arrive trois mois trop tard est un échec projet.

Voici 3 leçons de gestion de projet apprises « à la dure » par un jeune développeur, et pourquoi je pense qu’elles sont essentielles pour les profils techniques d’aujourd’hui qui souhaitent évoluer.

1. La technique doit servir le besoin (et non l’inverse)

À l’école ou dans les projets personnels, on cherche souvent la solution la plus complexe pour prouver sa compétence ou pour tester une nouvelle librairie à la mode. C’est intellectuellement satisfaisant, mais économiquement dangereux.

Dans la vraie vie, chaque heure passée à sur-optimiser une fonctionnalité que le client n’a pas demandée est une perte sèche pour le projet. J’ai appris à penser « produit » et « valeur » avant de penser « code ». Avant d’écrire une ligne, je me pose désormais systématiquement la question : « Quelle est la valeur ajoutée immédiate pour l’utilisateur final ? ».

Cette approche, proche du Value-Driven Development, change tout. Elle permet de prioriser les tâches non pas par intérêt technique, mais par impact business. Pour un Chef de Projet, avoir un développeur qui comprend cela est un atout majeur : Cela réduit les allers-retours, évite le « gold plating » (faire trop beau inutilement) et aligne toute l’équipe sur l’objectif réel.

2. La communication est un langage de programmation

On pense souvent à tort que les soft skills sont innées ou réservées aux commerciaux. C’est faux. Savoir dire « Non » à une demande irréaliste, savoir expliquer un retard technique sans utiliser de jargon incompréhensible, ou savoir lever une alerte (« flag« ) suffisamment tôt, cela s’apprend et se travaille.

En tant qu’indépendant, si je communique mal, je perds la confiance du client instantanément. J’ai réalisé que la transparence est l’outil numéro un de la gestion de projet. Un projet qui dérive ou qui rencontre un obstacle technique n’est pas un échec en soi si la communication a été fluide et que les attentes ont été réajustées en amont. Cacher la poussière sous le tapis jusqu’à la date de livraison est la pire des stratégies. C’est ce pont de confiance entre la technique et le métier que je m’efforce désormais de construire au quotidien.

3. L’Agilité n’est pas qu’une méthode, c’est une survie

L’agilité est souvent enseignée de manière théorique comme un ensemble de rituels (Daily, Sprint, Retro, Poker Planning). Mais sur le terrain, c’est surtout un état d’esprit face à l’imprévu.

Le cahier des charges initial survit rarement au premier contact avec la réalité du marché ou des utilisateurs. Au début, cela me frustrait. Aujourd’hui, j’ai appris à ne plus subir les changements de direction, mais à les accueillir comme faisant partie du processus normal de découverte du produit. Être un ingénieur « agile », c’est accepter de refactoriser ou de changer d’approche si le besoin métier évolue, tant que l’objectif final du projet est atteint. La rigidité technique est l’ennemie du succès projet.

Vers l’ingénieur hybride

Aujourd’hui, alors que je continue mon parcours professionnel, je garde précieusement cette casquette d’entrepreneur. Je suis convaincu que l’avenir appartient aux profils hybrides : Des ingénieurs passionnés par le code, mais pleinement conscients des contraintes du manager (coût, délai, qualité).

Comprendre la gestion de projet ne nous éloigne pas de la technique, au contraire :

Cela nous donne le contexte nécessaire pour construire des solutions logicielles qui ont du sens, de la valeur et qui aboutissent réellement.

__________________________________________________

À propos de l’auteur :

Hafid Idrissi est Ingénieur en Informatique (diplômé 2024). Après une expérience formatrice en tant qu’entrepreneur et professionnel libéral, il a développé une vision pragmatique alliant rigueur technique et exigences business. Passionné par les méthodologies qui font réussir les projets logiciels, il est aujourd’hui basé en France et à l’écoute d’opportunités en CDI pour apporter son dynamisme et sa double vision technique/produit à une équipe ambitieuse.

 

Comment construire une équipe forte en partant de zéro ?

Le par mopertodans agile, leadershipLaisser un commentaire

La plupart des équipes ne sont pas vraiment des équipes, ce sont des groupes de personnes qui travaillent ensemble.

How to Build a Powerful Team from Scratch par Mark Levison

https://agilepainrelief.com/blog/how-to-build-a-powerful-team-from-scratch/

Ce n’est pas parce que nous avons mis l’étiquette « équipe » sur un groupe de personnes que cela en fait une réalité, de la même manière que l’application de pratiques comme Scrum ou Kanban ne créent pas magiquement de super-pouvoirs. Un groupe de travail constitué de personnes ne devient une véritable équipe que lorsqu’elles franchissent un seuil de véritable collaboration.  C’est là que la magie entre en jeu.

Super-pouvoirs et magie des équipes.

Ce n’est pas aussi mystique que ça en a l’air. C’est de la science. Quand on met un groupe de personnes en place pour vraiment collaborer, et pas seulement travailler isolément, elles sont bien plus efficaces et productives. Elles résolvent collectivement des problèmes pour faire les bonnes choses plus rapidement. Connaître ses collègues et développer une base de confiance signifie qu’elles peuvent se sentir en sécurité pour discuter librement des idées, et la créativité n’est pas étouffée par la peur. Le sentiment partagé de but vers le même objectif est motivant. Se sentir partie d’un projet plus grand, avec une propriété et une responsabilité collective, réduit les frictions et renforce l’engagement et le moral.

Le défi, c’est que, dans l’ensemble, en tant qu’être humain, vous avez été conditionné à travailler en isolement, sans collaboration, jusqu’à ce que le problème soit trop important pour que vous puissiez le résoudre seul. C’est là que kick-off de l’équipe entre en ligne de compte.

Pourquoi investir dans un lancement d’équipe ?

Un kick-off d’équipe peut vous aider à franchir ce seuil et à devenir une véritable équipe plus rapidement et avec moins de friction. Indice : Ce n’est pas de la magie, il y a encore du travail acharné.

Les équipes performantes partagent plusieurs caractéristiques essentielles qui contribuent à leur succès, et un processus de lancement d’équipe est conçu pour garantir qu’elles sont en place dès le départ. Selon « The Wisdom of Teams: Creating the High-Performance Organization », ces équipes sont composées d’un petit nombre d’individus possédant des compétences complémentaires et engagés dans un but commun. Ils ont un objectif de performance précis et exigeant et se tiennent mutuellement responsables pour l’atteindre.

La performance de ces équipes repose sur une approche collective qui exige des contributions égales de tous les membres (effort égal plutôt que compétences égales). Elle favorise également l’interaction ouverte, la résolution de problèmes fondée sur des faits, l’évaluation basée sur les résultats, l’amélioration continue et la recherche systématique de nouvelles contributions et perspectives extérieures à l’équipe.

Organisez votre lancement d’équipe, étape par étape.

Voici les éléments majeurs et, dans certains cas, des exemples et des suggestions pour approfondir les détails. Évidemment, adaptez-les aux besoins spécifiques de votre équipe.

  • Introduction du sponsor – Le sponsor explique pourquoi il s’engage avec cette équipe.
  • Membres de l’équipe – Qui fait partie de l’équipe ? (Indice : Avoir des membres de l’équipe à temps partiel est une recette pour des retards et des défis futurs). N’oubliez pas qu’il existe des limites à la taille d’une équipe efficace. En théorie, le guide Scrum indique 3 à 9 personnes, excluant ScrumMaster et Product Owner. Ce n’est pas exclusivement une recommandation Scrum car, après avoir étudié les recherches sur ce sujet, les équipes de 4 à 7 semblent idéales, avec une limite stricte à 8 personnes (encore une fois hors ScrumMaster et PO). Bien sûr, si vous êtes 20-30 joueurs, vous pouvez toujours utiliser Scrum, vous aurez juste plus d’une équipe. Voir : Scrum à grande échelle
  • But – Pourquoi l’équipe existe-t-elle ? Quel est son objectif ? Au minimum, l’équipe doit s’accorder sur une vision et une stratégie produit  (souvent une Story Map initiale : Elle permet de mieux comprendre les besoins des utilisateurs et d’organiser la livraison des incréments en fonction de leur priorité). Sans vision  claire et une stratégie claire, l’équipe ne comprend pas ce qu’elle construit ni comment son travail quotidien contribue à l’objectif global du produit. Certaines équipes vont plus loin et créent une mission d’équipe qui expose leur contribution à la Vision Produit.
  • Propriétaire de produit ou Product Owner – Qui est le/la PO ? Quelle est sa disponibilité ? Que fait-on si elle n’est pas disponible pour répondre aux questions ou manque des Sprint planning ou revues de sprint ? Ou si elle est en vacances ? Ce sont toutes des choses qui, si elles sont discutées et connues à l’avance, peuvent éviter des problèmes à l’avenir.
  • Établissez des accords de travail afin que chacun ait une base commune d’attentes quant à la manière dont il collaborera (plus de détails ci-dessous).
  • Constituez l’équipe – Décrivez les compétences nécessaires pour livrer efficacement le produit à l’aide d’une matrice de compétences (plus de détails ci-dessous).
  • Créez une définition initiale de « Done ».
  • Événements Sprint – Examinez les événements Scrum et qui y participe (planification, daily Scrum, revue, rétrospectives et affinement du backlog produit). Décidez quand/où ils auront lieu. Vérifiez que les membres de l’équipe comprennent vraiment les événements. D’après mon amère expérience, environ 90 % d’entre eux ne les comprennent pas. Quand commence le Sprint ? Quels intervenants l’équipe invitera-t-elle à Revue de Sprint ?
  • Plan – Discutez de comment vous allez atteindre « Done » pour les premiers Sprints. Pair programming, Swarming, limiter les Travaux en cours ? Discutez de la manière dont vous allez tester le produit de votre travail. Préparer votre première structure de sprint backlog : Liste priorisée de tâches et d’histoires utilisateur que votre équipe de développement logiciel s’engage à réaliser au cours d’un sprint.

Comment créer des accords de travail de base ?

Nous savons par la littérature scientifique que  la sécurité psychologique est un élément essentiel pour les équipes qui fonctionnent efficacement. La sécurité psychologique est la conviction qu’il est possible de prendre des risques, de faire des erreurs, et qu’on ne vous en tiendra pas rigueur. Toutes les équipes, quel que soit l’environnement, font des erreurs. La question n’est pas de savoir si nous faisons des erreurs, mais comment notre équipe réagira-t-elle ? Dans des environnements à faible sécurité psychologique. Les gens essaient de cacher et de camoufler leurs erreurs. Dans des environnements à forte sécurité, ils sont plus susceptibles d’admettre leurs erreurs et toute l’équipe en tire des leçons. Les accords de travail sont une manière structurée de poser les bases nécessaires à la création d’un environnement psychologiquement sûr. (La sécurité psychologique ne signifie pas éviter les désaccords ou les conflits. Cela signifie affronter les défis sans être blâmé.)

Lors de la création de vos accords de travail de base, toute l’équipe doit être impliquée et contribuer.

Voici quelques suggestions de sujets courants à aborder et à intégrer dans votre accord :
  1. Processus décisionnel et règles : Établir un processus clair pour prendre des décisions, y compris des décisions basées sur le consensus ou des mécanismes de vote selon les besoins.
  2. Gestion des interruptions extérieures : Définissez des procédures pour gérer les interruptions pendant le Sprint lui-même, comme fixer les attentes avec les parties prenantes et limiter les distractions au sein de l’équipe.
  3. Protocoles et étiquette pour les événements d’équipe : Que ferez-vous si vous allez être en retard ? Comment l’équipe se sent-elle à l’idée de manger pendant les réunions ? Établissez des règles concernant l’utilisation de la caméra lors d’événements virtuels. (Indice : la collaboration est plus efficace quand on est face à face autant que possible, même si ce n’est qu’à travers une caméra.)
  4. Rythme durable : Comment l’équipe peut-elle s’assurer de s’engager dans un travail réaliste dans le Sprint ?
  5. Valeurs de l’équipe : Examinez les valeurs Scrum et décidez comment elles s’appliquent dans votre monde. Pour rappel, les valeurs de Scrum sont « Concentration, Engagement, Courage, Ouverture et Respect ». De nombreuses équipes abordent également des sujets tels que la collaboration, l’apprentissage continu et l’orientation client.
  6. Canaux de communication : Convenez des canaux de communication préférés (par exemple Slack, Microsoft Teams) pour les interactions quotidiennes et fixez les attentes concernant les délais de réponse. (Indice : Pour beaucoup de choses, la réaction instantanée est malsaine. Nous avons l’habitude de répondre si vite que nous sommes prêts à interrompre un travail concentré.)
  7. Outils de collaboration : Choisissez des outils appropriés (par exemple Mural, Miro) pour faciliter la collaboration en équipe et garantir l’accès de tous.
  8. Célébrer les réussites : Comment l’équipe célébrera-t-elle les succès ?
  9. Gestion des désaccords : Établissez des protocoles pour gérer les désaccords au sein de l’équipe.
  10. Violations des accords de travail : Définissez une règle simple pour signaler lorsqu’une personne ne respecte pas les accords de travail
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Qu’est-ce qu’une matrice de compétences et comment en créer une ?

La matrice de compétences est un outil pour vous et votre équipe afin d’identifier ce que l’équipe sait déjà faire. Cherchez les écarts entre les compétences actuelles et ce qui est nécessaire pour développer le produit. Prenez le temps de discuter des domaines où les gens souhaitent s’améliorer et comment cela peut être exploité pour combler les lacunes ou améliorer les performances. Sur le plan personnel, prenez le temps de réfléchir à la manière dont vous, en tant qu’individu, souhaitez accomplir cela, et ce que les autres doivent savoir sur le fait de travailler avec vous.

Bien que le Kanban/Scrum Board aide l’équipe à comprendre les challenges actuels et récents, cet outil ne répond pas aux domaines où l’équipe aura probablement besoin de nouvelles compétences à l’avenir, ni aux endroits où les membres souhaitent progresser.

Une matrice des compétences est un système d’auto-évaluation où les membres de l’équipe fournissent leur propre estimation de leurs compétences dans un domaine spécifique.

Pour créer une matrice de compétences, demandez à l’équipe de consacrer quelques heures et d’animer un atelier avec les étapes suivantes :
  1. Sur une grande feuille de papier, notez toutes les compétences que vous possédez personnellement et qui sont pertinentes pour le travail. Incluez votre compétence de super-héros (ou tout autre élément qui pourrait provoquer un sourire).
  2. Passez votre page à la personne suivante. Elle examine votre liste et ajoute toutes les compétences qu’elle estime que vous avez manquées.
  3. Répétez jusqu’à ce que les gens n’ajoutent plus de nouvelles compétences aux listes. En général, cela arrive après environ trois personnes.
  4. Compilez toutes les listes personnelles en une longue liste unique que tout le monde peut voir. Dans les domaines de compétences qui ont plus de valeur ou d’importance pour l’équipe, entrez dans les détails. Par exemple, dans Java Development, nous pouvons noter des bibliothèques ou outils spécifiques utilisés par les membres de l’équipe.
  5. Les noms des membres de l’équipe sont notés sur un axe, les domaines de compétence sur l’autre.
  6. Les membres de l’équipe évaluent eux-mêmes leur niveau de compétence dans chaque domaine.
N’importe quelle échelle peut être utilisée ; Par exemple, le mien part généralement de :
  • Blanc – Je ne veux pas apprendre ceci,
  • 0 à 1 – ne sachez rien mais êtes ouvert à apprendre,
  • 2 à 3 – peut accomplir de petites tâches sans aide d’un adulte,
  • 4 à 6 – expert dans le domaine et d’autres peuvent apprendre de moi

En calculant la moyenne pour chaque domaine de compétence, vous obtenez rapidement une image de la force et de l’expérience de l’équipe, et de celle où elle est la plus faible.

Matrice des compétences

Une matrice de compétences montrant à la fois les cas non techniques et techniques

J’aime créer une matrice de compétences chaque fois que je commence à travailler avec une nouvelle équipe. Une fois la matrice des compétences créée, je recommande aux équipes de la relire tous les x rétrospectives pour répondre à deux questions :

  • « Où avons-nous appris de nouvelles compétences qui nous permettraient de mettre à jour nos auto-évaluations ? »
  • « Où aimerions-nous ensuite concentrer notre énergie d’apprentissage ? »

Un point important à retenir avec la Matrice de compétences est qu’elle ne peut être utilisée que par l’équipe et pour celle-ci. Si elle est utilisée en dehors de l’équipe, les membres manipulent leurs numéros pour qu’ils soient mis en valeur, ce qui détruit la valeur même de l’outil. Trop souvent, j’entends parler d’organisations où les matrices de compétences sont une responsabilité des ressources humaines et où les informations servent à recruter des membres pour d’autres projets. Cette approche est à l’opposé de l’utilisation agile de l’outil. J’ai aussi vu ce système être mal utilisé par la direction pour faire pression sur les membres de l’équipe ou dans le processus d’évaluation de performance. Si cela arrive, toute sa valeur sera détruite. C’est un outil que l’équipe peut comprendre elle-même. Point final.

Dans une organisation suffisamment mature pour ne pas être mal utilisée, j’aime accrocher la Matrice des Compétences sur le mur de la salle d’équipe pour rappeler l’importance de l’apprentissage continu.

Conclusion

Que votre équipe débute tout juste ou qu’elle ait besoin d’une réinitialisation, un lancement d’équipe est un excellent moyen d’ancrer l’équipe et d’accélérer leur processus d’apprentissage. Constituer une équipe avec un design et une structure intentionnels sur lesquels travailler leur permet d’avoir une base de compréhension partagée, de but et de respect. Il ne s’agit pas seulement de rassembler les individus pour qu’ils soient plus productifs.

Il s’agit de créer un environnement où les gens s’épanouissent, se sentent soutenus et valorisés, et sont inspirés à donner le meilleur d’eux-mêmes.

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

« Le Recovery d’un Projet : Comment Redresser un Projet en Dérive » par Ophélie GOMES

Le par mopertodans agile, experience sharing, leadershipLaisser un commentaire

« Le projet a deux ans de retard et accumule une perte de 2 M€. Peux-tu voir ce que tu peux faire? »

Voici comment on m’a demandé pour la première fois de reprendre un projet. J’avais 2 ans d’expérience, autant dire que la pression était immense.

8 mois plus tard, l’équipe livrait le projet en production avec les remerciements du client.

Depuis, j’ai enchaîné les reprises de projets en difficulté. Et j’ai compris une chose : le PMI ne propose pas de « procédure officielle » de recovery. Il donne des bonnes pratiques pour mesurer la dérive et mener un plan d’action, mais quand tout devient trop complexe, un changement de manager de projet devient inévitable et la nécessité d’une approche spécifique.

Dans cet article, je partage les 3 conseils essentiels qui m’ont permis de réussir ces missions impossibles.

Conseil n°1 : Soyez une « Plante Verte » – Observer Sans Intervenir

La première erreur à ne pas commettre est de vouloir agir immédiatement. Certes, la situation est urgente, mais il faut prendre le temps de la compréhension et de l’observation. De plus, arriver avec « ses gros sabots » peut rendre l’équipe réticente à votre arrivée.

La phase « plante verte » consiste à observer avant d’agir tout en mesurant l’ampleur de la dérive.

Comment procéder ?

Restez en retrait : Assistez aux réunions, aux daily meetings, aux ateliers, mais ne prenez pas immédiatement les commandes.

Regardez l’équipe travailler : Observez les interactions, les dynamiques de groupe, les processus en place.

Avec le client, optez pour des réponses en deux temps : « Je prends note, je reviens vers vous » ou « Je vais creuser ce point ». Ces réponses vous protègent car votre interlocuteur tentera certainement de vous faire aller dans son sens.

Taisez-vous et ne jugez pas : Ce n’est pas le moment de critiquer ce qui a été fait. Vous n’étiez pas là, vous ne connaissez pas le contexte complet.

En parallèle, récupérez les informations sur la dérive : Budget, planning, périmètre, qualité. Construisez vos KPI de suivi dès maintenant.

Pourquoi cette phase est cruciale ?

Parce que ce sont ceux qui font qui savent. L’équipe qui a vécu le projet depuis le début possède une connaissance terrain que vous n’aurez jamais en lisant des rapports de suivi.

Cette phase d’observation vous permettra de :

  • Identifier les vrais problèmes (qui sont souvent différents de ceux qu’on vous a présentés)
  • Comprendre la dynamique de l’équipe
  • Gagner la confiance de l’équipe en montrant que vous ne débarquez pas en « redresseur de tort »

Combien de temps ? Entre 2 et 4 semaines selon la taille du projet. Ne vous précipitez pas, cette phase conditionne toute la suite.

Conseil n°2 : Crever l’Abcès – Rétrospective et Transparence

Il m’est arrivé d’intervenir sur un projet en difficulté sans que l’équipe ne le sache vraiment. L’équipe observait les tensions mais sans vraiment en mesurer l’ampleur.

La rétrospective est le bon moment pour crever l’abcès.

Vous avez observé, donc vous avez pu constater les dysfonctionnements. Vous avez peut-être même des idées de résolution (à ce stade, gardez-les pour vous). Vous avez également des mesures concrètes sur la dérive du projet. C’est le moment de la rétrospective.

Déroulement de la rétrospective en 3 étapes

 Étape 1 : Partagez les KPI

C’est une excellente introduction. Présentez factuellement où en est le projet : budget consommé, retard accumulé, dette technique, satisfaction client. Pas de jugement, juste des faits.

Étape 2 : Faites la rétrospective

De la plus classique (« Ce que l’on fait bien », « Ce que l’on veut arrêter », « Ce que l’on veut essayer », « Ce que l’on veut changer ») à la plus ciblée (diagramme d’Ishikawa pour identifier les causes racines).

Étape 3 : Debrief et confrontation douce

C’est le moment d’ajouter vos observations : « J’ai remarqué cela, je ne le vois pas sur le tableau, qu’en pensez-vous ? ». Cette approche non accusatrice permet de faire émerger les non-dits.

En sortie de rétrospective, vous aurez :

  • Une équipe consciente du problème et de son ampleur
  • Une vision complète du projet et de ce qu’il faut faire

Une fois cela fait, vous pouvez enchaîner sur le classique : « Plan, Do, Check, Act ».

Conseil n°3 : N’hésitez pas à Bousculer les Codes

Pendant mes recovery projets, j’ai pris des décisions radicales :

Supprimer tout un pan de l’application pour la reconstruire : 1,5 an de travail jeté à la poubelle. Pourquoi ? La dette technique était telle qu’il était plus rapide de reconstruire sur des bases saines que de corriger l’existant.

Supprimer toutes les spécifications pour repartir en mode agile : L’équipe perdait plus de temps à comprendre des documentations de 200 pages plutôt que de poser la question au client en direct.

Diminuer mon équipe alors qu’on me conseillait de l’augmenter pour aller plus vite : Trop de personnes = trop de coordination = perte d’efficacité. J’avais besoin d’une équipe restreinte.

Le paradoxe du recovery

C’est le plus gros avantage en recovery projet : Vous avez souvent les mains libres. Les clients et les directions veulent du changement, ils ont conscience que la situation ne peut pas empirer. Profitez-en pour proposer des approches audacieuses.

En Résumé : Les 3 Clés du Recovery

🌱 1. La phase « Plante Verte »

Observer sans intervenir pendant 2-4 semaines. Mesurer la dérive. Gagner la confiance.

🔍 2. Rétrospective et transparence

Crever l’abcès. Partager les KPI. Identifier collectivement les causes et les actions.

⚡ 3. Innover

Oser les décisions radicales. Profiter de la liberté du recovery.

Et vous, avez-vous déjà repris un projet en dérive ? Quelle a été votre première action ? Quelles leçons en avez-vous tirées ?

 Partagez votre expérience en commentaire. 👇

Ophélie GOMES

Ophélie GOMES

Je suis issue d’une filière technologique : Diplômée MIAGe à Lyon en 2002. J’ai commencé ma carrière dans une Entreprise de Services du Numérique (ESN) en tant que développeuse Java en mars 2003 tout en continuant en parallèle une thèse en Business Intelligence que j’ai soutenue en 2010.

J’ai occupé différentes fonctions dans l’IT pendant 15 ans chez Capgemini à Grenoble: Business Analyst, Chef de projet run, chef de projet build dans différentes technologies (java, SAP, Documentum, .Net) et différents secteurs (Services privés, Énergies, secteur public, industrie), directrice d’entité puis directrice régionale infrastructure. Depuis deux ans, je suis directrice des études et du digital chez Europ Assistance. En plus de mon rôle de manager, je suis coach agile certifiée SPC – Implementing SAFE et je donne des cours de gestion de projet.

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.