83 % des praticiens Agile utilisent l’IA, mais la plupart y consacrent au plus 10 % de temps car ils ne savent pas où elle se situe. Stefan Wolpers
Le rapport AI4Agile Practitioners 2026 inclut des analyses détaillées des réponses par rôle, taille d’organisation et niveau d’agilité. Vous y découvrirez une analyse qualitative complète des défis, préoccupations, réussites et priorités.
Cette enquête auprès de 289 praticiens Agile identifie les véritables obstacles à l’adoption et montre où l’Intelligence Artificielle crée une valeur sur laquelle vous pouvez agir.
How to Provide a Release Plan Without Losing Agility by Mike Cohn
Une feuille de route est un plan, pas une promesse.
Je m’apprête à partir pour un road trip entre l’Idaho et le Colorado : un trajet de 16 heures.
Je sais où je vais, et mon itinéraire général, mais je ne connais pas chaque virage que je vais prendre — et ça me va.
C’est ainsi que les équipes agiles devraient traiter les plans de livraison et les feuilles de route.
Mon itinéraire est un plan, pas une promesse. Il n’est pas gravé dans le marbre. Les virages que j’ai pris et mon temps estimé pouvaient varier en fonction des travaux sur les routes, des embouteillages, d’une opportunité de détour excitant, ou même une crevaison. Plus je dois parcourir de la distance, plus je devrais m’attendre à être ces incertitudes.
Les plans agiles sont identiques. Nous ne pouvons pas prédire chaque éventualité, mais nous pouvons fournir une prévision. Nous pouvons donner une idée générale de la direction que nous envisageons, une plage prévue de moments où nous atteindrons probablement des étapes clés, ainsi que notre niveau de confiance dans le plan.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi les parties prenantes poussent pour avoir des garanties.
La plupart des équipes agiles savent qu’il y a trop d’incertitude pour tout garantir. En même temps, elles pensent qu’une garantie est la seule chose que les parties prenantes accepteront.
Voici ce que les équipes agiles pourraient manquer : les parties prenantes ont leurs propres plans à établir. Et elles sont tout aussi inquiètes que les équipes Agiles de devoir rendre des comptes sur leurs prévisions.
Les parties prenantes ont besoin de dates de livraison et de jalons justes (notez que je n’ai pas dit précis). Elles recherchent la prévisibilité.
Parfois, on a l’impression qu’elles demandent une garantie. Mais en vérité, la seule façon de leur donner une certitude absolue est de :
Charger nos estimations (comme dire à quelqu’un que mes 16 heures de route en prendront 24 heures, juste au cas où), ou
Refuser de vous adapter lorsque les conditions changent.
Aucun n’est bon ni pour le produit ni pour l’équipe.
Le chemin vers l’alignement commence par l’empathie.
Alors, que pouvez-vous faire lorsqu’une partie prenante semble vouloir une garantie plutôt qu’une prévision ? Essayez ceci : parlez aux parties prenantes en termes qu’elles comprennent. Voici une technique que j’ai trouvée utile :
Comparez leurs demandes à celles de prévisions similaires dans leur propre domaine.
Par exemple :
Demandez à un commercial quel serait son niveau de confort s’il devait garantir précisément combien il vendra — et avec quels clients il conclura — pour chacun des six prochains mois, ou durant la première année de sortie d’un produit.
Demandez à un responsable marketing quelles seraient ses préoccupations si on lui demandait de s’engager sur des résultats de campagne précis avec des délais précis.
Ne soyez pas dans la confrontation. L’objectif n’est pas de les piéger, c’est de montrer que l’incertitude existe partout, et que l’agilité est une force, pas une faiblesse.
Donnez aux parties prenantes ce dont elles ont besoin pour réussir.
Ensuite, partagez mon analogie de road trip avec vos parties prenantes. Dites-leur que vous ne pouvez pas leur donner de garantie, mais que vous pouvez présenter une feuille de route pour les 3 à 6 mois. La feuille de route montrera l’objectif de l’équipe, le niveau de progrès que vous pensez pouvoir faire à quel moment (exprimé en fourchette), ainsi que la confiance de votre équipe dans le plan.
Rappelez aux parties prenantes que, comme les itinéraires suggérés lors d’un long trajet, les feuilles de route agiles offrent de la visibilité, alignent les attentes et aident les gens à planifier — sans prétendre que chaque virage est connu à l’avance.
Libérer votre équipe d’attentes irréalistes peut accélérer leur transition de bon à excellent niveau.
P.S. Si votre équipe a du mal à concilier agilité avec attentes des parties prenantes, amenez Mountain Goat dans votre organisation pour un atelier de planification de sortie. Nous aidons les équipes à construire des feuilles de route flexibles et à haute confiance — sans trop s’engager. Vous avez besoin d’aide pour communiquer vos projets ? Essayez notre outil de visualisation de plans, gratuit pour tous les membres de MGS Essentials.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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 :
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.
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.
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.
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.
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 :
Stratégie – Le Pourquoi – Une description claire et transparente des éléments de valeur (économiques), d’entreprise, de technologie et d’exploitation.
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.
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.
Cycle de la Valeur – Les pratiques qui permettent la découverte agile, la livraison de produits, ainsi que les opérations et le support.
(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.
(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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Technical skills fade. Soft skills compound and improve everyone around you.
Quiconque a travaillé dans le développement de produits pendant plus de quelques années a vu le même schéma se répéter. Les compétences techniques essentielles d’aujourd’hui deviennent progressivement — ou parfois brusquement — obsolètes. Les outils changent. Les cadres de travail tombent en désuétude. Des architectures qui semblaient autrefois modernes commencent à paraître datées.
Ce n’est pas nouveau, mais cela s’accélère. La durée de vie des compétences techniques ne cesse de diminuer. Dans les années 1980, il fallait 10 ans pour que la moitié de ce que l’on connaissait devienne obsolète. Aujourd’hui, il s’agit de 4 ans, et cela tombera bientôt en dessous de 2 ans selon un professeur de Stanford.
Cette réalité soulève une question importante pour les leaders :
Où l’investissement dans les personnes a-t-il le plus grand impact à long terme ?
Les compétences techniques sont nécessaires. Mais elles sont rarement durables. Les compétences relationnelles ou soft skills, en revanche, ont tendance à durer et même à se renforcer avec le temps.
La courte demi-vie des compétences techniques dans le développement de produits.
Quand quelqu’un apprend un nouveau langage de programmation, un nouveau framework ou un nouvel outil, cette compétence a une date d’expiration. Elle peut être utile un moment, mais il devra finalement être remplacée. C’est tout simplement la nature de la technologie.
Les compétences relationnelles se comportent différemment. Quand quelqu’un apprend à collaborer efficacement, à prendre de meilleures décisions, à animer des discussions ou à guider les autres, ces compétences ne s’effacent pas. Au lieu de cela, elles deviennent une partie intégrante du fonctionnement de cette personne.
Apprendre à apprendre est un bon exemple. Une fois que quelqu’un développe cette capacité, elle lui reste. Il en va de même pour la prise de décision, le leadership et la collaboration. Ces compétences peuvent continuer à s’améliorer, mais elles ne deviennent pas sans importance. Au fil de la vie d’une équipe — ou d’une carrière — cette différence compte.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi les compétences relationnelles comptent-elles plus que jamais dans les équipes produit ?
J’ai assisté une fois à une réunion où un programmeur présentait de nouvelles fonctionnalités à un groupe d’infirmières. Pendant la démonstration, il a montré un exemple à l’écran suggérant qu’un nouveau-né grognon devrait recevoir des crackers (ce qui est clairement cliniquement inapproprié).
Le programmeur a essayé d’expliquer que ce n’était qu’un texte provisoire. Le véritable but, a-t-il dit, était que le système fournirait au final des conseils aux infirmières. Le texte de l’exemple précis n’avait pas d’importance.
Pour les infirmières, cela comptait énormément.
Leur identité professionnelle repose sur le principe de « ne pas nuire ». Ce qu’elles voyaient à l’écran violait ce principe. Elles n’ont pas pu passer outre et étaient prêtes à faire remonter le problème et à annuler complètement le projet.
Ce qui a sauvé le projet, ce n’est pas une correction technique. C’était les compétences relationnelles du chef de projet. Il a calmé la situation, reconnu les inquiétudes des infirmières, expliqué ce qui s’était passé et les a convaincues de revenir une semaine plus tard pour une démonstration révisée.
La véritable défaillance n’était pas technique. C’était un manque d’empathie. Si le programmeur avait pu se mettre à la place des infirmières (ou simplement validé l’exemple avec l’une d’elles au préalable) la situation ne se serait probablement jamais produite.
Comment les compétences relationnelles réduisent-elle les risques dans le développement de produits ?
Le développement de produits est plein d’incertitudes. Les équipes travaillent avec des besoins évolutifs, des informations incomplètes et des utilisateurs dont la confiance doit être gagnée et maintenue.
Les compétences relationnelles réduisent les risques dans ces environnements. L’empathie aide les équipes à comprendre les utilisateurs et les parties prenantes. Une communication claire instaure la confiance. La collaboration évite que de petits malentendus ne deviennent de gros échecs.
Lorsque ces compétences sont faibles, les équipes les paient souvent plus tard par des travaux à refaire, des relations endommagées ou des opportunités manquées. Quand elles sont fortes, les équipes naviguent dans l’incertitude avec beaucoup moins de friction.
Pourquoi les dirigeants sous-estiment-ils le retour sur investissement des compétences relationnelles ?
De nombreuses organisations sous-investissent dans les compétences relationnelles car les bénéfices sont plus difficiles à mesurer. Il est relativement facile d’envoyer quelqu’un prendre un cours technique et de confirmer qu’il a appris quelque chose de nouveau. Il est beaucoup plus difficile de savoir si quelqu’un est devenu un meilleur collaborateur ou un meilleur facilitateur tant que l’équipe n’est pas sous pression.
Il y a aussi une hypothèse fréquente que les gens devraient déjà posséder ces compétences au moment d’entrer sur le marché du travail. En conséquence, les manquements sont ignorés jusqu’à ce qu’ils apparaissent aux pires moments possibles.
Ironiquement, ce sont à ces moments-là que les compétences relationnelles comptent le plus.
Les compétences relationnelles améliorent la performance de l’équipe, pas seulement des individus.
Quand quelqu’un apprend une nouvelle compétence technique, le bénéfice reste souvent cantonné à cette personne. Mais quand quelqu’un apprend à mieux collaborer, toute l’équipe en bénéficie.
Une meilleure collaboration améliore la communication, la prise de décision et la confiance au sein du groupe. Tout le monde s’améliore, pas seulement la personne qui a suivi la formation. Cet effet multiplicateur est l’un des avantages les plus négligés de l’investissement dans les compétences relationnelles.
Pourquoi les compétences relationnelles solides sont les plus importantes sous pression ?
Certains leaders pensent que l’amélioration des compétences relationnelles peut attendre que les choses se calment. Cela peut être le cas, mais vous ne pouvez pas attendre qu’une crise vous oblige à améliorer vos compétences relationnelles. Quand une équipe est sous pression est le moment où leur absence coûte le plus.
Les équipes dotées de solides compétences relationnelles peuvent avoir des conversations difficiles quand cela est important. Leurs membres peuvent discuter ouvertement des options, être en désaccord de manière productive et prendre de meilleures décisions sous pression parce que la confiance s’est construite plus tôt.
Les équipes dépourvues de ces compétences se renferment souvent, évitent les conflits ou optent par défaut pour la solution la plus rapide plutôt que la meilleure.
Quels postes en développement produit nécessitent le plus de fortes compétences relationnelles ?
Tous les membres d’une équipe de développement produit bénéficient de solides compétences relationnelles, mais certains postes en dépendent plus que d’autres.
Les Scrum Masters s’appuient sur des compétences en facilitation pour aider les équipes à réfléchir clairement et à bien travailler ensemble. Les Product Owners s’appuient sur des compétences de leadership pour aligner les parties prenantes, guider la prise de décision et créer une compréhension partagée. Les coachs et les leaders façonnent chaque jour l’environnement dans lequel ces compétences sont pratiquées.
Quand les détenteurs de ces rôles sont faibles en compétences relationnelles, toute l’équipe le ressent.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Investir dans les compétences relationnelles est le choix le plus durable que les leaders puissent faire.
C’est pourquoi les organisations efficaces de développement de produits ne laissent pas les compétences relationnelles au hasard. Elles les considèrent comme des capacités qui doivent être développées intentionnellement.
Les compétences techniques compteront toujours mais elles ont une durée de vie limitée. Les compétences relationnelles persistent. Elles s’ajoutent avec le temps, renforcent des équipes entières et montrent leur valeur de façon plus évidente quand la pression est forte.
Les leaders qui souhaitent des équipes capables de s’adapter, de collaborer et de prendre de bonnes décisions sur le long terme doivent investir délibérément dans ces compétences. Cela signifie considérer la collaboration, la facilitation et le leadership comme des capacités à développer et non comme des compétences à assumer présentes.
Si vous souhaitez de l’aide pour développer ces compétences auprès de vos Product Owners, Scrum Masters et équipes, Mountain Goat Software collabore avec des organisations pour y parvenir précisément.
partagez ce billet avec vos amis, collègues et relations professionnelles
« 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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vos événements Agile n’échouent parce que les gens manquent de formation.
Ils échouent parce que votre organisation a adopté les rituels tout en rejetant la transparence, la confiance et l’adaptation qui les font fonctionner.
Et souvent, le dysfonctionnement des cérémonies mécaniques n’est pas un défaut : C’est une fonctionnalité.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
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.
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.
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.)
Rythme durable : Comment l’équipe peut-elle s’assurer de s’engager dans un travail réaliste dans le Sprint ?
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.
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é.)
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.
Célébrer les réussites : Comment l’équipe célébrera-t-elle les succès ?
Gestion des désaccords : Établissez des protocoles pour gérer les désaccords au sein de l’équipe.
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 :
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).
Passez votre page à la personne suivante. Elle examine votre liste et ajoute toutes les compétences qu’elle estime que vous avez manquées.
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.
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.
Les noms des membres de l’équipe sont notés sur un axe, les domaines de compétence sur l’autre.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
« 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cette bibliothèque de connaissances (Articles, documents, vidéos, formations sur Agile et plus particulièrement Scrum) a été récemment améliorée en se basant bien sûr sur les retours de ses utilisateurs.
Un design audacieux et épuré qui facilite l’exploration et la découverte d’articles, de vidéos et d’autres ressources. Vous bénéficierez toujours des mêmes caractéristiques et fonctionnalités qu’auparavant, mais avec une apparence considérablement améliorée.
Des balises (tags) intuitives en haut pour que vous puissiez filtrer instantanément par articles, vidéos, webinaires, communiqués de presse ou collections, ou afficher tous les types de ressources.
Des filtres thématiques sur la gauche de l’écran pour une recherche ciblée. Vous pouvez sélectionner un ou plusieurs de ces filtres en fonction de ce qui vous intéresse à explorer.
Une barre de recherche simple pour trouver des ressources par mot(s) clé(s) ou titre complet.
Bien que ces huit postures soient précieuses, trois d’entre elles constituent le socle d’un Scrum Master efficace : Coach, Formateur et Mentor. Ces rôles sont souvent combinés, mais chacun a un objectif distinct pour aider les équipes à se développer et à prospérer.
Le Scrum Master en tant que coach.
Le coaching consiste à libérer le potentiel de l’équipe, et non à fournir toutes les réponses. Un Scrum Master en tant que coach doit développer sa patience, ses capacités d’écoute et sa capacité à guider sans diriger.
Ce que cela donne au quotidien.
Écoute activement et patiemment.
Aborde le coaching avec la conviction que l’équipe a déjà les réponses.
Guide systématiquement sans intervenir pour faire le travail.
Apporte une perspective holistique dans les conversations.
Comprend que les changements significatifs sont graduels et nécessitent plus que des processus documentés.
Les compétences de coaching ne se construisent pas du jour au lendemain. Elles nécessitent de la pratique, de la réflexion et des années de perfectionnement. L’expérience en leadership aide, mais l’essence du coaching est la confiance, c’est-à-dire permettre aux équipes de trouver leurs propres réponses.
Le Scrum Master en tant que formateur.
Sans expérience pertinente, il est difficile pour un Scrum Master d’enseigner efficacement. La formation implique le transfert de connaissances, parfois sur Scrum lui-même, d’autres fois plus largement sur les pratiques de produit et de développement.
Ce que cela donne au quotidien.
Enseigne aux équipes les événements Scrum, les valeurs et autres pratiques agiles.
Guide les Product Owners dans les techniques de management de produit comme le backlog slicing.
Initie les développeurs à des pratiques collaboratives telles que mob programming ou le TDD.
Soutient les testeurs en leur montrant des moyens de mieux collaborer avec les développeurs.
Ici, l’expérience compte. Un Scrum Master qui a travaillé dans des organisations de produits peut enseigner avec crédibilité et une perspicacité pratique, rendant les concepts abstraits plus concrets.
Le Scrum Master comme mentor.
Alors que la formation consiste à transférer des connaissances, le mentorat va plus loin : Il consiste à accompagner l’apprenant. Contrairement au coaching, où le Scrum Master pose principalement des questions, le mentorat consiste souvent à partager des conseils, des expériences et même à modéliser les bonnes pratiques.
Ce que cela donne au quotidien.
Aide les membres de l’équipe à devenir de meilleurs animateurs d’événements Scrum.
Guide les individus pour résoudre leurs propres obstacles.
Offre des conseils et une perspective aux équipes qui naviguent entre les différentes options.
Le mentorat accélère la croissance parce qu’il fournit à la fois des connaissances et des exemples vécus. Il dit : « Voici comment je l’ai fait – maintenant, essayons-le ensemble. »
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi ces postures sont importantes.
Les Scrum Masters qui manquent de compétences en matière de coaching, de formation et de mentorat ont souvent du mal à avoir un impact. C’est pourquoi j’encourage les nouveaux Scrum Masters à acquérir de l’expérience dans d’autres rôles au sein d’une équipe Scrum avant d’entrer dans ce rôle. Une exposition plus large vous fournit des informations pour coacher avec empathie, enseigner avec autorité et mentorer avec confiance.
Bien sûr, aucun Scrum Master n’est un expert en tout. Il y a des moments où il est logique de s’associer à d’autres pour combler vos lacunes en matière de compétences. Par exemple, j’ai une formation en développement, mais je m’appuie sur des développeurs ou des architectes seniors lorsque l’équipe a besoin d’une expertise approfondie en conception de logiciels. Cette collaboration ne diminue pas le rôle du Scrum Master, mais l’améliore en veillant à ce que l’équipe reçoive les bons conseils.
Réflexions finales.
Être un Scrum Master n’est pas une question de titres ou de cérémonies. Il s’agit de permettre aux personnes et aux équipes de se développer. Le coaching permet à l’équipe d’être une meilleure version d’elle-même, la formation fournit de nouvelles connaissances et le mentorat s’appuie sur ces connaissances pour créer des capacités durables au sein de l’équipe.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
J’anime plusieurs cours sur le leadership agile et Scrum, si vous souhaitez en savoir plus sur le cadre de travail Scrum, consultez la page de la ValueHut Consulting Academy
partagez ce billet avec vos amis, collègues et relations professionnelles
Ces termes sont si fréquemment utilisés (et mal utilisés) que leur impact peut être perdu, mais comprendre comment chaque approche fonctionne (et pourquoi leur combinaison est si puissante) est essentiel pour créer de meilleurs logiciels, plus rapidement.
Cet article décompose chaque approche, utilise des analogies du monde réel et explore pourquoi la combinaison des deux est plus efficace que l’une ou l’autre seule.
Qu’est-ce que le développement itératif ?
Un processus itératif progresse par le raffinement.
Une approche itérative du travail commence par une version approximative d’une fonctionnalité ou d’un produit, puis l’améliore grâce à des cycles répétés, chacun se rapprochant peu à peu de la forme finale.
Par exemple, un sculpteur qui aborde le travail de manière itérative peut commencer par sculpter grossièrement un bloc de pierre. À chaque passage, il affine la forme, ajoutant des détails, lissant les bords et s’améliorant continuellement jusqu’à ce que la sculpture atteigne sa forme finale. La sculpture n’est pas terminée tant que l’ensemble de la pièce n’est pas terminé.
Qu’est-ce que le développement incrémental ?
Un processus incrémental permet de créer et de livrer des fonctionnalités et des produits en plusieurs parties. Chaque élément, ou incrément, représente un sous-ensemble complet de fonctionnalités.
Les incréments peuvent être petits ou grands. L’objectif est de terminer chaque incrément de fonctionnalité dans son intégralité avant de passer au suivant, sans qu’il soit nécessaire de revenir en arrière et de repasser sur ce travail plus tard. Chaque incrément terminé peut être livré seul.
Pour en revenir à l’analogie de la sculpture, un sculpteur incrémental choisirait un élément de la sculpture et se concentrerait sur celui-ci jusqu’à ce qu’il soit terminé. Il peut choisir de petits incréments (d’abord le nez, puis les yeux, puis la bouche, et ainsi de suite) ou de grands incréments (tête, torse, jambes puis bras). Cependant, quelle que soit la taille de l’incrément, le sculpteur incrémental tenterait de terminer le travail de cet incrément aussi complètement que possible avant de passer à autre chose.
Les équipes agiles combinent incrémental et itératif.
Le développement agile combine les deux approches pour obtenir le meilleur des deux mondes :
C’est itératif parce que le plan est que chaque pièce soit affinée et améliorée au fil du temps.
C’est incrémental car des logiciels fonctionnels utilisables sont livrés tout au long du projet.
Cette combinaison permet aux équipes d’apporter de la valeur dès le début, d’obtenir des retours et de s’adapter.
La vidéo ci-dessous montre comment le comédien Jerry Seinfeld aborde son travail d’une manière à la fois incrémentale et itérative.
Exemple concret : Création d’une application de rencontres.
Imaginez que vous développez un site de rencontres. Voici comment chaque approche fonctionnerait.
Purement itératif
Vous construisez et bénéficiez d’un peu de toutes les fonctionnalités : Profils, recherche, chat, etc.
Vous revenez en arrière et améliorez chacun d’entre eux au cours de plusieurs cycles.
Au fil du temps, l’ensemble du système est perfectionné puis, finalement, livré.
Purement incrémental
Vous créez et fournissez une version parfaite de la fonction de gestion des profils. Vous ne commencez rien d’autre avant que ce soit terminé.
Vous construisez et livrez une version parfaite d’une deuxième zone, disons la recherche. Vous passez ensuite à la suivante.
Chaque fonctionnalité est parfaite avant le début de la suivante.
Itératif + Incrémental (Agile)
Vous commencez avec une version de base du profil utilisateur, vous la livrez. Vous obtenez des commentaires.
Vous ajoutez la possibilité d’ajouter une image au profil de l’utilisateur et de fournir une version de base de la fonctionnalité de recherche. Vous obtenez à nouveau des commentaires.
Vous réorganisez les champs sur le profil utilisateur pour améliorer l’expérience utilisateur. Vous ajoutez des filtres à la fonctionnalité de recherche. Vous créez un schéma de la fonction de chat. Vous obtenez davantage de commentaires.
Les sprints suivants peuvent inclure des améliorations apportées aux fonctionnalités précédentes et des versions de nouvelles fonctionnalités utilisables. Ou les deux.
Une approche agile permet des mises en production précoces, des expérimentations à faible risque et des corrections de cap fréquentes, caractéristiques des équipes performantes.
L’agilité est itérative et incrémentale
Ni le développement incrémental ni le développement itératif n’apportent à eux seuls beaucoup de valeur. Mais ensemble, ils forment la colonne vertébrale de l’agilité.
L’itération aide les équipes à affiner et à s’adapter. L’incrémental garantit une progression constante et une création de valeur. Combinés, ils permettent d’obtenir de l’agilité, de la réactivité et des résultats concrets.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
PIAF 2026 se tiendra le 20 mars 2026. Une journée exceptionnelle pour explorer comment l’agilité, au-delà de l’IT, devient un levier stratégique pour délivrer de la valeur, innover et accompagner la transformation des organisations.
Prenez-y la parole ! Proposez une conférence, un atelier ou un sujet de panel. C’est l’occasion idéale de partager vos pratiques, vos retours d’expérience et vos idées pour enrichir la communauté. Voici le lien : https://sessionize.com/piaf-2026 .
Dans le contexte actuel, un projet ne peut plus être considéré comme une suite linéaire de tâches à exécuter selon un plan figé.
Le projet évolue dans un environnement mouvant, souvent incertain, où les variables économiques, sociales, techniques et humaines interagissent en permanence. C’est pourquoi un projet doit aujourd’hui être compris comme un système adaptatif complexe.
Un tel système est constitué d’un ensemble d’acteurs autonomes — qu’il s’agisse d’équipes, de métiers, de prestataires ou de parties prenantes — qui interagissent selon des règles souvent locales, propres à leurs compétences, à leur culture de travail ou à leurs objectifs.
Ces interactions ne sont pas uniquement coordonnées par le haut.
Elles génèrent des effets globaux émergents, qui ne sont pas nécessairement prévisibles à partir des seules règles de départ.
Dans ce type de projet, l’environnement extérieur joue un rôle crucial.
Il n’est pas simplement un cadre passif, mais un élément dynamique qui évolue en fonction des actions du projet et en retour, influence ses trajectoires. Ainsi, le projet ne se contente pas de « suivre un plan » : Il s’ajuste en permanence à l’évolution de son contexte, à la manière d’un organisme vivant qui s’adapte à son milieu pour survivre et évoluer.
Ce pilotage adaptatif repose sur un principe fondamental : L’apprentissage en boucle.
Pour fonctionner efficacement, le système projet doit être capable d’observer son propre fonctionnement en temps réel. Pour cela, il s’appuie sur une base d’indicateurs de performance, construite autour de deux dimensions complémentaires :
D’une part, des indicateurs techniques, qui renseignent sur l’avancement, les coûts, la qualité, la charge ;
D’autre part, des indicateurs humains, qui donnent des signaux sur la motivation des équipes, les tensions organisationnelles, la clarté des rôles ou encore le climat de collaboration.
Ces indicateurs ne prennent tout leur sens que lorsqu’ils sont mis en rapport avec des consignes réalistes, c’est-à-dire des objectifs adaptatifs, définis non pas comme des normes rigides mais comme des seuils d’alerte intelligents, ajustés aux spécificités du projet et de son environnement.
Lorsqu’un écart apparaît entre la mesure et la consigne, cela ne signifie pas forcément un échec, mais signale un besoin d’ajustement.
Ce signal déclenche alors un processus structuré de résolution de problème.
Des méthodes éprouvées comme l’AMDEC (analyse des modes de défaillance et de leurs effets), les arbres des causes ou les 5 pourquoi permettent d’identifier les origines profondes des écarts constatés. À partir de là, des plans d’action ciblés sont construits. Ces actions ne sont pas imposées de façon descendante mais redistribuées intelligemment aux acteurs du projet : Elles sont affectées à des services, à des équipes, à des personnes, selon leurs compétences, leur responsabilité ou leur place dans la dynamique de travail.
Chaque action corrective devient alors une nouvelle donnée d’entrée pour le système, et contribue à le faire évoluer. Cette dynamique produit de l’apprentissage collectif. Les bonnes pratiques identifiées, les erreurs comprises, les seuils ajustés ou les innovations de terrain sont capitalisés. Ils alimentent la mémoire du projet, mais aussi plus largement celle de l’organisation. Ainsi, à chaque cycle de régulation, le système augmente sa résilience.
Progressivement, à force de réajustements, de diagnostics, de réinjections d’expérience, l’entreprise devient plus apte à résister aux aléas, à intégrer le changement, à transformer ses pratiques en continu. Elle devient ce que l’on appelle une organisation apprenante, c’est-à-dire une entité capable de se transformer par l’usage intelligent de ses propres retours d’expérience.
Ce que l’on observe ici, c’est une commande adaptative intégrée.
Elle ne repose pas sur un pilotage centralisé rigide, mais sur une régulation distribuée, fondée sur la circulation de l’information, l’analyse des signaux faibles, la réactivité locale et la diffusion d’une vision commune. L’enjeu n’est plus simplement de « tenir un cap », mais de coordonner des trajectoires multiplesvers une direction stratégique partagée, en conservant la capacité d’adaptation à chaque instant.
Ainsi, le projet cesse d’être une construction mécanique, pour devenir une forme vivante, auto-régulée, intelligente, guidée par ses boucles d’observation, d’action et d’apprentissage.
Cette approche change en profondeur la posture du chef de projet, du manager et des équipes :
On passe d’un modèle de contrôle à un modèle de résonance, d’un plan à une dynamique, d’un programme à une forme d’intelligence collective.
C’est un Contrôle statistique de processus qui en entreprise peut s’appliquer à divers processus (gestion de projets, marketing, veille technologique). Une entreprise est caractérisée par un produit ou service. Une organisation et des processus sont établis afin de concevoir, développer, produire et vendre un produit ou un service. Cela a un coût : Le prix de revient (PR). Le prix de vente (PV) est lié à l’équilibre économique de la concurrence. Le bénéfice (B = PV − PR) est à optimiser, ce qui exige de réfléchir à la commande des processus afin de limiter les coûts de non-qualité (entropie de l’entreprise, désordre organisationnel, gaspillage [qu’il s’agisse d’activités, de ressources ou de matière]). Un contrôle statistique met en œuvre la commande du processus et permet de garantir une efficacité du processus en minimisant les coûts de non-qualité générés par celui-ci.
Dans ces 3 cas d’applications, la modélisation conduit à une estimation de paramètres pertinents. Leur estimation en temps réel (apprentissage) conduit à un pilotage adaptatif et optimal de ces systèmes en vue de finalités opérationnelles. L’application opérationnelle de ces méthodes est une commande adaptative de ces systèmes.
Nous pourrions la modéliser par le schéma suivant :
La complexité des systèmes temps réel et processus d’entreprise conduit à élargir les techniques traditionnelles d’analyse et de pilotage afin d’ optimiser l’efficacité du système (estimation, prédiction interprétation) , cela par le biais de la commande adaptative. C’est un mode particulier de commande optimale
Alain Chautard est ingénieur en data science dans le groupe Thalès. Il a travaillé pendant 20 ans dans les services d’Études Avancées où il a été acteur dans la modélisation et la simulation de systèmes complexes. Depuis 15 ans, il participe au développement et la mise en œuvre des systèmes d’information, notamment dans le domaine de la Gestion de projet. Dans ce cadre, il est en charge d’études concernant l’utilisation des données capitalisées et leur modélisation à des fins de prédictions pour la conduite du changement et l’amélioration continue.
partagez ce billet avec vos amis, collègues et relations professionnelles
Stan, un client potentiel, a eu du mal à trouver le temps de participer à notre session de découverte. (C’est la session de travail où le client et moi discutons des limites d’une mission de conseil.) Après qu’il ait annulé trois appels programmés, j’ai soupçonné que nous ne travaillerions pas ensemble.
Mais ensuite, il m’a demandé une conversation un soir, après sa « journée de folie ». (Ses mots, pas les miens.)
Lorsque nous avons discuté après nos heures normales de travail, j’ai appris plusieurs choses importantes sur son organisation.
Tout le monde était surchargé. Les équipes avaient trop de projets et de travail de support. Les managers avaient trop de décisions à prendre.
En conséquence, leur débit était assez faible. Cela signifiait que leurs boucles de rétroaction étaient trop longues. (Ils souffraient des effets de Loi de Little avec un en-cours élevé, un long encourt et un faible débit.)
Il était certain qu’il allait perdre des gens s’il ne changeait rien. Et il ne savait pas par où commencer.
Au cours de notre conversation, il a convenu avec moi qu’il devait mener ces changements. Ces changements étaient d’atteindre plus de résilience dans le système de chacun, plus de marges dans le système, et que tous fassent tout ce qu’ils peuvent pour créer des boucles de rétroaction plus rapides.
Commençons par ce que j’entends par plus de résilience dans le système.
Astuce #1 : Résilience du système.
Beaucoup de personnes pensent que la résilience leur permet de rebondir après des moments difficiles. Au lieu de cela, considérez la résilience comme un moyen de vous projeter vers l’avant. Si c’est le cas, vous pouvez vous libérer pour prendre des décisions différentes, et peut-être meilleures.
Lorsque Stan a repensé ses idées sur la résilience, il s’est rendu compte que l’organisation avait créé un système fragile, peu susceptible de rebondir du tout, sans parler d’aller de l’avant.
Stan a identifié ce qui rendait le système fragile :
Des feuilles de route longues et détaillées pour la plupart des produits.
Des promesses spécifiques que les ventes avaient faites à plusieurs clients, ce qui a forcé à maintenir ces feuilles de route en place. Parce que les feuilles de route étaient si longues, les gens ont continué à y ajouter davantage de fonctionnalités.
À la suite de toutes ces promesses, tout le monde regardait en arrière, pas en avant.
Cette perspective, de toujours regarder en arrière, rendait difficile, voire impossible, la réévaluation d’une décision. Après avoir discuté des problèmes, Stan a décidé de reconsidérer toutes les différentes promesses faites aux clients. Comme il l’a dit :
« Nous avons déjà rompu les promesses de date de livraison. Autant tout négocier. »
Lentement, en supprimant les ancres autour des engagements de chacun, Stan a pu réduire le nombre de projets actifs et créer un peu de marge dans le système.
Astuce #2 : Intégrez de la marge dans le système
Stan et moi avons reparlé dans la soirée. Même si les équipes ont réussi à dégager un peu de marges, Stan avait toujours l’impression que le travail le submergeait. Mais maintenant, il avait besoin d’informations pour garder ces marges dans le système. Pendant si longtemps, les gens avaient été si occupés qu’ils ne savaient pas quoi faire de leur temps « supplémentaire ».
Je lui ai demandé : « Coachez-vous les gens pour qu’ils prennent certaines de vos décisions ? Ou est-ce que vous devez encore prendre toutes les décisions ? »
Il s’est arrêté et a dit :
« Je suppose qu’il est temps pour moi de déléguer certaines décisions, n’est-ce pas ? »
« Vous n’obtiendrez pas de boucles de rétroaction plus courtes tant que vous n’aurez pas intégré un peu de mou dans votre système », ai-je dit. « Il suffit de regarder notre relation de conseil. Vous me payez cher pour travailler avec moi en dehors de vos heures de travail normales. C’est comme une taxe de décision. Je parie que vous avez beaucoup plus de ces taxes de décision chaque jour que nos simples discussions.
J’ai su qu’il comprenait quand il a émis un grognement. Mais cette idée lui a permis de raccourcir de nombreuses boucles de rétroaction.
Astuce #3 : Raccourcissez les boucles de rétroaction
Lorsque j’ai parlé pour la première fois avec Stan, son temps de prise de décision et celui de toute la direction exécutive éclipsaient tout le temps de travail sur les projets.
Comme les équipes ont travaillé sur moins de projets et sur moins de fonctionnalités, elles ont raccourci leurs boucles de rétroaction internes. Cela leur a permis de montrer des démos et de livrer plus souvent en production, ce qui a permis aux chefs de produit de réduire le contenu du backlog et des feuilles de route. Cela a aussi permis aux chefs de produit d’être beaucoup plus réactifs aux besoins des clients et de terminer les projets plus rapidement. Plus les équipes terminaient les projets rapidement, plus il était facile de modifier le portefeuille de projets.
Aujourd’hui, en repensant leur approche de la résilience et en créant davantage de marges dans le système, Stan pouvait constater que l’organisation était plus efficace. Il avait encore du travail à faire avec son équipe de direction, mais elle était sur la bonne voie.
L’efficacité mène à l’agilité de l’entreprise
Lors d’une conversation récente (pendant les heures normales de travail !), Stan a dit qu’il avait enfin l’impression que l’organisation était plus efficace. Et qu’il avait plus d’options, ce qui était le point de l’agilité business.
Nous nous réunissons maintenant pendant nos journées de travail, et non le soir. Stan a l’air plus détendu. Il a dit qu’il prenait des décisions plus rapidement et mieux, ce qui était le but de notre engagement.
Il se peut que vous ne souhaitiez pas ou n’ayez pas besoin d’une « véritable » agilité business. Cependant, je soupçonne que vous voulez être plus efficace.
Considérez ces idées :
Utilisez la résilience pour vous projeter vers l’avant.
Intégrez des marges dans le système pour ne pas être frénétique.
Raccourcissez les boucles de rétroaction, en particulier les boucles de rétroaction de la direction.
Si vous mettez en œuvre es conseils, partagez comment cela se passe.
Êtes-vous nouveau sur la newsletter de Pragmatic Manager ? Voir les éditions précédentes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le rapport AI4Agile Practitioners 2026 inclut des analyses détaillées des réponses par rôle, taille d’organisation et niveau d’agilité. Vous y découvrirez une analyse qualitative complète des défis, préoccupations, réussites et priorités.
DantotsuPM.com 