L’un des signes les plus clairs que Scrum fonctionne est que les gens apprécient son utilisation.
Cela ne veut pas dire que tout le monde aime chaque réunion. Je n’aime pas les réunions. L’une des raisons pour lesquelles j’ai lancé ma propre entreprise était d’en avoir moins.
Mais certaines réunions sont utiles.
Un événement Scrum utile doit apporter de la clarté, de l’énergie, ou les deux.
La planification des sprints devrait permettre aux gens de mieux comprendre ce que l’équipe cherche à accomplir et de se sentir plus confiants quant à la manière de commencer.
Le Daily Scrum devrait aider l’équipe à coordonner le travail de la journée.
La revue de sprint doit produire des retours qui peuvent influencer ce qui se passe ensuite.
La rétrospective devrait indiquer à l’équipe quelque chose qui mérite d’être amélioré.
Quand Scrum fonctionne, les gens voient que le framework les aide.
Quand Scrum ne fonctionne pas, les mêmes événements commencent à sembler du gaspillage.
Le Daily Scrum devient une réunion de statut d’avancement. Le sprint planning devient une négociation sur la quantité de travail que l’on peut y mettre. La revue de sprint devient une démo que personne n’utilise pour influencer la suite. La rétrospective devient un lieu où les mêmes sujets sont discutés toutes les deux semaines sans que rien ne change.
À ce stade, il n’est pas surprenant que les gens commencent à dire que Scrum a trop de réunions.
Souvent, on accuse le nombre de réunions. Mais, plus souvent, les réunions ne produisent pas assez de valeur.
Quand un événement Scrum semble inutile, ne commencez pas par l’annuler. Commencez par vous demander ce qu’il est censé aider l’équipe à accomplir.
Par exemple, une revue de sprint devrait aider l’équipe à obtenir des retours des parties prenantes qui influencent la suite. Si l’évaluation ne produit pas de retour utile, inspectez la conception de la réunion.
Y a-t-il les bonnes personnes ? Voient-ils le travail assez tôt pour l’influencer ? L’équipe demande-t-elle un retour ou se contente-t-elle de montrer ce qu’elle a fait ?
Tenez les événements Scrum courts. Gardez-les actifs. Gardez-les appropriés. Mais assurez-vous que chacun fasse ce pour quoi cet événement existe.
Essayez ceci.
Choisissez l’événement Scrum que votre équipe valorise le moins.
Demandez : « Qu’est-ce que cet événement devrait nous aider à accomplir ? ».
Ensuite, changez une chose lors de la prochaine occurrence de cet événement pour mieux atteindre cet objectif.
Scrum ne devrait pas ressembler à une taxe à payer par les équipes avant de pouvoir progresser. Scrum devrait les aider à progresser.
PS: Si les événements Scrum de votre équipe ressemblent plus à des réunions qu’à une aide au progrès, notre formation Working on a Scrum Team aide les équipes entières à transformer les événements Scrum en sessions de travail ciblées et productives.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Rejetez des exigences que vous ne pouvez pas défendre.
Les politiques dépassées effrayent les gens. Les pratiques établies nécessitent un exorcisme.
Les exigences actuelles sont-elles de bonnes idées qui auraient mal tournées ?
Mort lente
Des règles inutiles causent un échec silencieux. Les gens suivent des étapes qui n’ont pas d’importance. Les équipes protègent des processus qui ne servent pas.
L’énergie s’échappe, une action inutile à la fois.
Remettez en question toutes les exigences :
#1. Supposez que ces exigences sont incorrectes.
Pensez que les règles sont imparfaites. Il est facile de justifier le respect des règles. Il est courageux de supprimer des exigences supposées « essentielles ».
#2. Trouvez le « Qui ».
« C’est le système » n’est pas une réponse. Qui a imposé cela ? Si personne ne peut le défendre, remettez-le en question.
#3. Éliminez le « modèle universel ».
Les procédures génériques signalent une réflexion paresseuse. Elles échangent la précision pour la commodité. Si cela convient à tout le monde, ça ne sert probablement à personne.
#4. Ignorez les « normes industrielles ».
Maman vous a dit : « Si tes amis sautaient d’un pont, est-ce que tu le ferais ? ». L’excellence, c’est faire des choses que les autres ne font pas.
Astuce d’expert : Tuez la réflexion de l’organisation. La réponse la plus dangereuse que vous entendez est : « C’est une obligation légale » ou « La finance en a besoin. »
Simplicité
Ne soyez pas un grincheux quand vous remettez en question toutes les exigences. Éliminez la friction. Dégagez la voie pour votre équipe.
Chaque exigence inutile met à rude épreuve l’âme de votre équipe.
Avant d’optimiser, décidez si la tâche doit exister ou pas du tout.
5 questions pour remettre en question toutes les exigences.
Quel problème résout-elle ?
Que se passe-t-il si on ne fait pas ça ?
Est-ce une règle, ou c’est juste comme ça qu’on a toujours fait ?
Qui en bénéficie vraiment ?
Pouvons-nous essayer de retirer ça pendant 30 jours ?
Arrêtez de suivre les règles. Commencez à simplifier.
Quel processus pourriez-vous suggérer comme candidat à une suspension à l’essai de 30 jours ?
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Ce guide explique comment le développement interne des talents offre un retour sur investissement clairement mesurable par rapport au recrutement de ressources externes, en mettant l’accent sur l’agilité, la réduction des coûts et la résilience organisationnelle.
Quels sont les bénéfices à développer vos talents internes ?
Une organisation adaptable investit dans ses employés internes pour réduire les coûts, améliorer la productivité et assurer la rétention.
En effet, vos investissements dans votre personnel interne renforcent leur et votre capacité d’adaptation face aux disruptions. Le recrutement externe coûte très cher et le délai moyen de recrutement va de 1 à 2 mois. Alors que les coûts de formation interne sont bien moins élevés et que vos propres employés comprennent mieux votre culture et vos processus, pour une montée en compétence 3 à 4 fois plus rapide.
De plus, la mobilité interne augmente la fidélité, réduit le turnover.
Attention aux coûts et retour sur investissement de l’acquisition de nouvelles ressources externes.
L’embauche externe peut être nécessaire pour des besoins spécifiques que vous n’avez pas et ne pouvez former dans les délais impartis. Mais cela entraîne des coûts élevés et des pertes de productivité car vous devez anticiper des coûts additionnels liés à l’intégration de ces nouvelles recrues.
Quels sont les principaux bénéfices de votre meilleur management des talents ?
La réduction du turnover et la promotion interne sont des leviers clés pour optimiser les coûts.
Le développement de compétences agiles est essentiel pour la résilience organisationnelle et la capacité d’adaptation : réactivité, flexibilité interfonctionnelle et prise de décision complexe.
A retenir
L’embauche externe est coûteuse et doit être limitée aux situations de croissance rapide ou de besoin en perspectives nouvelles.
Investir dans le développement interne offre une productivité plus rapide et une meilleure fidélité pour des coûts inférieurs. L’investissement dans l’équipe existante est souvent la meilleure décision économique.
La formation aux compétences agiles est un levier stratégique pour renforcer la capacité d’adaptation et la performance globale.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’erreur la plus courante que je vois faire par équipes lors du découpage d’une histoire utilisateur est de la séparer par couches techniques.
Don’t split stories this way par Mike Cohn
L’erreur la plus courante que je vois faire par équipes lors du découpage d’une histoire utilisateur est de la séparer par couches techniques.
Ils prennent une grande histoire et la transforment en éléments tels que :
Construire l’interface utilisateur
Construire le backend
Créer les tables de la base de données
Tester la fonctionnalité
Cela peut donner l’impression que le travail à réaliser est plus petit. Mais cela aide rarement l’équipe à terminer quoi que ce soit de significatif.
Chaque élément dépend des autres. Rien ne peut être démontré comme un flux utilisateur fonctionnel. L’équipe a découpé le travail, mais la valeur reste enfermée dans l’histoire plus large.
Un meilleur découpage découpe verticalement le travail.
Cela signifie que l’équipe fait un peu de ce qui est nécessaire : interface utilisateur, backend, base de données, tests, et tout ce qui est nécessaire pour qu’un résultat plus restreint fonctionne de bout en bout.
Supposons qu’une équipe développe une fonction de recherche de maisons.
L’histoire volumineuse pourrait permettre à un acheteur potentiel de rechercher par superficie, nombre de pièces, statut, type de maison, âge et équipements.
Une mauvaise répartition serait de construire d’abord tout l’écran de recherche avec tous les critères et de le connecter plus tard.
Une meilleure répartition serait peut-être :
Recherche par superficie et nombre de pièces
Ajouter le statut immobilier et le type de bien
Ajouter l’âge de l’habitation et les équipements
La première version de cette répartition peut être simple. Elle ne supporte peut-être que quelques critères. Mais cela fonctionne pour les critères qu’elle soutient.
Cela donne à l’équipe quelque chose de fait, testable et démontrable.
C’est là le but du découpage de l’histoire : faire moins, mais faire fonctionner cette petite chose.
Dans votre prochaine conversation sur le raffinement de l’arriéré de produit, écoutez les éléments qui ressemblent à des couches techniques.
Backend pour…
UI pour…
Travail de base de données pour…
Tests pour…
Ce sont peut-être des tâches utiles plus tard. Ce ne sont généralement pas de bons découpages d’histoire.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’agilité organisationnelle est essentielle pour réussir l’intégration responsable et efficace de l’intelligence artificielle dans les entreprises.
Pourquoi l’agilité est-elle cruciale pour réussir l’intégration de l’IA ?
L’agilité organisationnelle est essentielle pour transformer l’investissement en IA en valeur durable car elle favorise la flexibilité, la collaboration et la responsabilisation de chacun.
L’IA peut avoir tendance à amplifier les problèmes si votre organisation n’est pas adaptable.
Votre réussite dépend de la capacité de vos équipes à s’adapter, apprendre et appliquer ces nouveaux outils.
L’agilité va vous permettre de tester rapidement les livrables des outils d’IA, de les ajuster et de mesurer les progrès par des résultats concrets.
Votre agilité organisationnelle crée un environnement propice à l’innovation, la résilience et la croissance durable dans notre monde aujourd’hui dominé par l’IA.
Quelles stratégies clés pour faire évoluer l’IA avec l’agilité ?
Adoptez des pratiques agiles pour favoriser la collaboration, réduisez les risques et assurez-vous d’une expérimentation responsable.
Favorisez la collaboration interfonctionnelle pour intégrer l’IA dans toute l’entreprise.
Brisez les silos entre départements comme marketing, finance, RH et opérations.
Utilisez des cycles courts pour tester et affiner les solutions IA.
Adopter une approche « test and learn » pour valider les idées, corriger le tir et focaliser vos ressources.
Faites la promotion de la transparenceet de la sécurité psychologique pour une expérimentation responsable.
La collaboration transversale est-elle un levier d’innovation ?
L’intégration de l’IA nécessite une collaboration entre différentes fonctions pour maximiser la valeur obtenue.
L’IA doit dépasser le cadre du service informatique pour devenir une réelle transformation métier.
La collaboration transverse entre analystes des données, managers de produits, marketing et conformité est essentielle.
Des pratiques opérationnelles modernes facilitent la communication et la co-création.
La collaboration assure que les solutions IA répondent aux besoins humains ainsi que stratégiques.
Réduisez les risques par des cycles courts de validation.
Les cycles courts permettent d’éviter les investissements excessifs dans des solutions non encore prouvées.
La validation par petits tests permet de définir des coûts réalistes.
La méthode « test and learn » accélère la progression et la confiance.
La répétition de ces cycles permet d’affiner et d’améliorer continuellement les solutions IA.
L’approche itérative transforme l’IA en un processus de découverte et d’adaptation.
La transparence favorise une expérimentation responsable.
Créez un environnement de sécurité psychologique pour encourager la discussion ouverte sur les biais et les erreurs.
La sécurité psychologique permet de signaler les biais et/ou les effets indésirables.
La transparence favorise la confiance et une prise de décision éthique.
Les revues régulières et les rétrospectives prônées par l’approche Agile encouragent la réflexion collective.
Une culture d’ouverture permet d’identifier et de manager les risques liés à l’IA.
Quelles sont les conditions essentielles pour le succès de l’IA ?
Dotez-vous d’un environnement basé sur la sécurité psychologique, le feedback et la collaboration, sachant que :
La préparation des données est fondamentale et nécessite des investissements en infrastructure.
Une faible qualité des données peut fortement limiter la fiabilité des apports de l’IA.
Le développement des compétences des employés doit couvrir à la fois les aspects techniques et humains, comme la capacité d’adaptation.
La constitution d’équipes transversales favorise l’alignement entre technologie et besoins humains.
Quelles approches pratiques pouvez-vous utiliser pour renforcer vos capacités organisationnelles ?
L’amélioration continue, le leadership courageux et l’apprentissage sont clés pour la maturité agile.
Commencez par une évaluation de votre préparation organisationnelle.
Investissez dans la formation ciblée et la certification pour développer ces compétences.
Favorisez une culture d’expérimentation et d’apprentissage permanent.
Assurez-vous que vos leaders incarnent l’agilité, encouragent la curiosité et garantissent la sécurité psychologique.
L’agilité peut devenir un avantage concurrentiel dans l’ère de l’IA.
Votre adaptabilité vous permet de rester compétitif, d’innover rapidement et d’apprendre de vos échecs.
Les organisations agiles évoluent plus vite et récupèrent plus rapidement.
Elles sont mieux préparées pour faire face aux changements futurs.
L’agilité devient un levier stratégique pour l’innovation et la croissance durable.
Scrum Alliance et le développement des compétences
Scrum Alliance propose des formations, microcertifications, accompagnement et ressources pour renforcer l’agilité.
Formations certifiantes en ligne ou en présentiel, adaptées à tous les métiers.
Microcertifications pour un apprentissage ciblé et immédiat.
Possibilité d’intégrer la formation ou le coaching en interne.
Adhésion à une communauté mondiale pour un développement continu.
Partenariats pour élargir l’impact de la formation agile dans l’organisation.
partagez ce billet avec vos amis, collègues et relations professionnelles
La plupart des équipes n’ont pas besoin d’un leader pour les pousser à s’engager un peu trop.
Elles le font généralement d’elles-mêmes.
Cela peut sembler surprenant. Nous pensons souvent que les développeurs logiciels sont sceptiques ou cyniques. Mais d’après mon expérience, les développeurs sont souvent très optimistes. Ils croient en l’amélioration des choses. Ils ont vu comment la technologie peut améliorer des vies et transformer les entreprises. Cet optimisme fait partie de ce qui les rend bons dans ce qu’ils font.
Demandez à une équipe de choisir ce qu’elle peut faire en un sprint, en un trimestre ou d’ici la fin de l’année, et la plupart des équipes en choisiront un peu trop. Parfois, beaucoup trop.
Cela ne veut pas dire que ses membres sont négligents. Cela signifie qu’ils sont humains.
Et c’est précisément pour cela que les leaders doivent faire preuve de prudence. Si une équipe a déjà tendance à trop s’engager par elle-même, toute pression supplémentaire venant d’en haut peut pousser cette équipe à s’engager vraiment dramatiquement.
Je l’ai appris à mes dépens au début de ma carrière. Quand j’ai été promu pour la première fois à la tête d’une équipe, je pensais que les délais seraient assez simples à tenir. Ma philosophie de management, si on peut appeler ça ainsi, était la suivante : demander des estimations aux membres de l’équipe, supposer que ces estimations sont optimistes, puis tenir les gens à leurs propres estimations optimistes.
Cela n’a pas marché.
Le problème n’était pas que mon équipe était irresponsable. Le problème, c’est que je traitais l’optimisme comme un contrat.
Les équipes sont déjà optimistes.
C’est la première chose que je veux que les leaders comprennent : l’excès d’engagement commence généralement avant même qu’un leader ne prononce une parole.
Les équipes logicielles élaborent souvent des plans raisonnables basés sur des informations incomplètes. Elles font de leur mieux. Elles regardent le travail devant elles. Elles font des suppositions sur ce qui se passera bien. Elles imaginent un parcours pour réaliser ce travail et estiment en fonction de ce parcours.
C’est normal.
Mais parce que ses membres sont optimistes, l’équipe penche souvent vers le meilleur ou le presque meilleur scénario sans s’en rendre compte. Et parce que le travail logiciel comporte de l’incertitude, même un plan sensé peut échouer.
Prenez l’exemple de devoir traverser la ville en voiture pour vous rendre à un rendez-vous. Vous considérez la distance, l’heure de la journée et la circulation habituelle. Vous en concluez que 30 minutes suffisent, et la plupart du temps vous avez raison. Mais un jour, un incident bloque les voies pendant 10 minutes, et soudain vous êtes en retard.
Votre estimation n’était pas stupide. C’était la meilleure estimation. Ça a juste échoué dans ce cas-là à cause de la malchance.
La même chose arrive aux équipes.
Parfois, une équipe planifie vraiment mal. Mais parfois, l’équipe choisissait le résultat le plus probable et se ratait tout de même parce que l’incertitude apparaissait sous une forme peu prévisible.
Les leaders doivent faire de la place à cette réalité.
Comment la pression du leadership pousse les équipes à s’engager trop.
Parce que les équipes sont déjà optimistes, cette pression du management compte plus que ce que beaucoup de leaders réalisent.
Parfois, les leaders exercent une pression intentionnelle. Ils en veulent plus, ils le veulent plus tôt, et ils le disent directement.
Mais la pression apparaît aussi de façon involontaire.
Un leader peut créer de la pression avec une question, un ton de voix, ou même un langage corporel. J’ai travaillé une fois avec une leader nommée Erin, qui était une personne vraiment positive et dynamique. En traversant le bureau, elle saluait les gens avec des questions comme :
« Vas-tu produire beaucoup de livrables aujourd’hui ? »
Elle ne voulait rien faire de mal en disant cela. En fait, sa plus grande préoccupation était la qualité. Elle voulait que l’équipe ralentisse suffisamment pour bien travailler. Mais ce que l’équipe entendait, c’était une pression quotidienne sur la productivité.
Quand je lui ai fait remarquer, elle a changé son salut pour quelque chose de volontairement ridicule :
« Resteras-tu « bug free » aujourd’hui ? »
Ce petit changement comptait. Cela montrait ce qui comptait vraiment pour elle. Et parce que c’était presque humoristique, cela a brisé l’ancien schéma.
Cet exemple reste gravé dans ma mémoire car il montre à quel point il est facile pour les leaders de communiquer une chose et d’être entendus d’une autre manière.
Même un simple « Comment ça se passe ? » peut être perçu comme une mise sous pression si les membres de l’équipe l’entendent comme « Dis-moi que tu es dans les délais. »
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Ce que la pression fait aux équipes.
La pression ne supprime pas l’incertitude. Elle change la façon dont les équipes se comportent face à l’incertitude.
Lorsque les équipes ressentent de la pression, elles ont tendance à choisir leur estimation la plus optimiste plutôt que la plus réaliste. Elles deviennent moins enclines à exposer les risques. Elles cessent de chercher trop attentivement ce qui pourrait mal tourner, en partie parce que découvrir de mauvaises nouvelles devient inconfortable.
Les risques ne disparaissent pas. Ils passent simplement sous le tapis.
C’est l’un des effets les plus dangereux de la pression. Cela ne fait pas que déformer ce que disent les équipes. Cela déforme ce qu’elles sont prêtes à considérer.
Parfois, la pression pousse aussi les équipes à allonger les heures de travail. En cas de véritable crise, travailler un peu plus cette semaine peut être acceptable. Mais ce n’est pas une stratégie à long terme pour une productivité durable. Un effort excessif prolongé entraîne de la fatigue, des erreurs et une qualité inférieure.
Et une fois que la qualité commence à décliner, les équipes aggravent souvent la situation en se pressant. Ils commencent à dire des choses comme : « On nettoiera ça plus tard » ou « On peut faire ça dans un autre sprint. »
L’urgence est acceptable. Se précipiter ne l’est pas.
J’aime la distinction souvent attribuée à John Wooden :
Soyez rapide, mais ne vous pressez pas.
C’est exactement ce que les leaders devraient attendre des équipes. Avancez avec énergie, mais pas dans la panique.
Prévisions vs. Plan vs. Engagement.
Une des raisons pour lesquelles les leaders et les équipes ont des ennuis est qu’ils utilisent les mêmes mots pour signifier des choses différentes.
Une prévision est une prédiction de l’avenir.
Un plan est ce que nous espérons faire en fonction de cette prévision.
Un engagement est ce que nous sommes convaincus de pouvoir faire, avec suffisamment de marge pour que cela soit crédible.
Ces mots ne sont pas interchangeables.
Une équipe peut estimer les éléments individuels de l’arriéré de produit et, à partir de ces estimations, élaborer un plan de sprint ou des jalons sur trois mois. Ce plan peut être réfléchi, discipliné et utile. Mais il n’est toujours pas garanti.
Un engagement, c’est différent. Un engagement nécessite une marge.
Si je pense pouvoir traverser la ville en 30 minutes, c’est un plan. Si je dois vraiment m’engager à être à l’heure, je peux partir 40 minutes plus tôt. Le temps supplémentaire n’est pas une perte de temps. C’est le prix de la certitude.
Les leaders comprennent cette idée dans d’autres domaines de l’entreprise. Une société peut prévoir en interne des bénéfices de 5$ par action. Mais lorsqu’elle communique vers l’extérieur, elle peut s’engager de manière plus prudente à 4,50$. Même entreprise, mêmes leaders, même réalité. Ils comprennent que l’engagement nécessite de la marge si les choses devaient mal tourner.
Le développement logiciel ne fait pas exception.
Donc oui, les leaders peuvent demander des engagements. Ils peuvent demander un engagement pour un sprint, une fonctionnalité ou un objectif sur plusieurs mois. Mais ils doivent reconnaître que la portée sur laquelle l’équipe va s’engager doit être plus petite que la portée planifiée, et la portée planifiée doit généralement être plus petite que la portée optimiste.
Comment l’ancrage pousse les équipes à un sur-engagement.
L’une des façons les plus courantes dont les leaders provoquent un sur-engagement est l’ancrage.
L’ancrage se produit lorsqu’un leader formule la réponse avant que l’équipe n’ait fait sa propre réflexion.
Un leader demande :
« Pouvez-vous livrer ces fonctionnalités en trois mois ? »
Ça semble assez innocent. Mais ce n’est pas neutre. L’équipe a désormais entendu à la fois la quantité de travail et le délai souhaité. Ses membres savent quelle réponse le leader espère. Ils veulent être utiles. Ils veulent plaire aux gens. Ainsi, au lieu de déterminer en toute indépendance ce qui est réaliste, ils commencent à chercher un chemin vers le oui.
Je l’ai vu très clairement il y a des années, lorsque j’étais vice-président du développement dans une société cotée. Mon patron a demandé si un certain produit pouvait être livré d’ici la fin de l’année. Nous avions besoin de revenus pour l’année en cours, et ce produit pourrait aider.
Je suis retourné avec mon équipe et j’ai élaboré le plan. Notre réponse initiale était quelque chose comme mi-février. Nous avons coupé certaines choses, révisé le plan, et réussi à obtenir un plan qui indiquait mi-décembre. Super, nous avons pensé. Nous allions répondre aux besoins business.
Ce que je n’avais pas prévu, c’est que nos clients ne nous donneraient pas de testeurs bêta disponibles en novembre et décembre. Ils étaient trop occupés. Cela a repoussé la sortie jusqu’en janvier.
Maintenant, prenez du recul et regardez ce qui s’est passé. Sur un effort de 11 mois, nous avons manqué la date cible de seulement quelques semaines. C’est en fait une assez bonne planification. Mais comme le but était de faire entrer les revenus cette année-là, le résultat a été un échec.
Et je pense que l’échec a commencé par la question.
Si mon patron m’avait demandé : « Quand est-ce qu’on peut avoir ça ? », je serais probablement revenu avec une réponse en février ou mars. Cela aurait conduit à la bonne décision business : ne pas faire le projet dans ce but de livraison avant la fin de l’année. Mais « Pouvez-vous le faire d’ici la fin de l’année ? » nous a ancrés vers une réponse souhaitée, et nous (moi) avons trouvé un moyen de presque y parvenir.
Presque ne suffisait pas.
Demandez la vérité, pas la réassurance.
Les meilleurs leaders exposent très clairement ce qu’ils demandent.
Veulent-ils une prévision ? Un plan ? Un engagement ?
Ils rendent aussi sans danger d’y répondre par la vérité.
Cette sécurité ne vient pas du fait de dire : « Donne-moi de bonnes nouvelles », elle vient du fait de poser des questions qui invitent à la réalité :
Quelles hypothèses faites-vous qui pourraient ne pas être vraies ?
Qu’est-ce qui pourrait faire dérailler ce plan ?
Quelles dépendances sont intégrées dans ce plan ?
Est-ce votre estimation optimiste, le cas le plus probable ou pessimiste ?
Que devrais-je savoir sur le cheminement de votre réflexion derrière tout ça ?
Ce sont des questions très différentes de celles qui impliquent : « S’il te plaît, rassure-moi. »
La différence compte. Une vérification saine n’est pas une formalité qui fait dire à l’équipe que tout va bien. Une vérification saine est celle qui aide l’équipe à révéler ce qui ne va pas bien.
Et lorsqu’un leader entend une mauvaise nouvelle, sa première réponse la plus importante peut simplement être : « Merci de me l’avoir dit. »
Cette phrase montre à l’équipe que la vérité est valorisée.
Vous voulez une version pratique de cela ?
Téléchargez Overcommitment Toolkit for Leaders. Ce kit comprend un bref diagnostic, un guide simple sur prévision, plan et engagement, et mes 10 meilleures questions de planification.
La planification devrait être un problème partagé.
C’est l’habitude de leadership que je souhaite le plus changer.
Trop souvent, les leaders considèrent la planification comme un problème réservé à l’équipe. Le leader demande un plan. L’équipe en fournit un. Puis le leader accepte ou dit, en quelque sorte : « Ce n’est pas suffisant. Tenez tout de même la date souhaitée. »
Ce n’est pas de la planification. C’est de la pression.
La planification doit être un dialogue.
Une équipe doit présenter son plan. Le leader doit reconnaître l’effort qui y a été investi. Et si le leader espérait mieux, la réponse devrait être quelque chose comme : « J’espérais plus, plus tôt. Que puis-je faire pour nous aider à y parvenir ? »
Cela change tout.
La conversation devient alors collaborative. Peut-être qu’une grande fonctionnalité pourrait être supprimée. Peut-être qu’un résultat de moindre priorité peut être déplacé à une version ultérieure. Peut-être que quelques semaines supplémentaires changent radicalement le risque. Peut-être qu’ajouter une personne aide. Peut-être que l’application mobile viendra plus tard.
Le fait n’est pas que chaque problème ait une réponse facile. L’essentiel est que la réponse ne devrait pas être entièrement imposée à l’équipe.
La planification est un problème partagé.
Le coût d’un sur-engagement répété.
Lorsque les équipes se sur-engagent à répétition, les premiers dégâts que les leaders remarquent sont généralement des objectifs manqués.
Le dommage le plus profond est la perte de crédibilité.
Si une équipe échoue à atteindre son objectif de sprint ou son jalon sprint après sprint, finalement plus personne ne fait confiance au plan suivant. C’est dur pour tout le monde. C’est difficile pour les leaders car ils cessent d’obtenir des informations utilisables. C’est difficile pour les équipes car même quand elles disent enfin la vérité, personne ne les croit.
Un sur-engagement répété apprend à l’organisation à ne plus croire en la réalité.
C’est pourquoi cette question est si importante. Il ne s’agit pas seulement de faire mieux tourner un sprint. Il s’agit de préserver la capacité d’une équipe et de ses leaders à avoir des conversations honnêtes et utiles sur la planification.
Que devraient plutôt demander les leaders
Si vous êtes un leader, voici le changement le plus simple que je puisse proposer.
Arrêtez de poser des questions qui révèlent la réponse que vous souhaitez.
Quand un leader demande : « Pouvez-vous faire cela en trois mois ? », l’équipe est déjà ancrée. Ses membres connaissent désormais la date que souhaite le leader, et de nombreuses équipes commenceront à chercher un moyen de faire en sorte que cette réponse soit oui.
Une meilleure question est : « Voici ce dont j’ai besoin. Quand pouvez-vous le livrer ? »
Laissez l’équipe répondre d’abord à cette question. Puis comparez leur réponse à votre timing espéré. Si la réponse est plus tardive que ce que vous souhaitez, ne transformez pas cela en pression. Transformez-le en une conversation.
Posez ensuite des questions comme :
Qu’assumez-vous qui ça se passera bien ?
Qu’est-ce qui pourrait faire dérailler cela ?
Quelles dépendances sont importantes ici ?
Est-ce une prévision, un plan ou un engagement ?
Que pouvons-nous faire ensemble pour améliorer le résultat ?
Ces questions ne réduisent pas la responsabilité. Elles l’améliorent. Elles aident les équipes à réfléchir plus clairement, à parler plus honnêtement et à planifier de manière plus crédible.
C’est ce que les leaders devraient vouloir.
Les équipes ne s’engagent pas trop parce qu’elles sont irresponsables. Elles se sur-engagent parce que l’optimisme est naturel, alors que le travail logiciel est incertain, et le comportement du leadership influence ce que les équipes se sentent en sécurité à dire.
Les meilleurs leaders ne pressent pas plus fort. Ils créent les conditions pour la vérité. Ils distinguent les prévisions des engagements. Et ils considèrent la cible ambitieuse comme un problème commun à résoudre ensemble.
C’est comme ça qu’on obtient de meilleurs plans. Et, avec le temps, de meilleurs résultats.
Vous voulez de l’aide pour mettre cela en pratique ?
Téléchargez Overcommitment Toolkit for Leaders. Cette boite à outils comprend un diagnostic rapide pour repérer les schémas de sur-engagement, un guide pour séparer les prévisions des engagements, ainsi qu’un ensemble de questions de planification que vous pouvez utiliser pour obtenir des réponses plus honnêtes de la part des équipes.
partagez ce billet avec vos amis, collègues et relations professionnelles
La majeure partie du micro-management n’est pas un problème de contrôle : c’est un échec de clarté déguisé.
Stop Telling Professionals How to Do Their Job — Commander’s Intent at Work par Stefan Wolpers
Cet article présente l’Intention du Commandant : un modèle de briefing en cinq parties qui remplace les instructions prescriptives par un objectif commun, des contraintes strictes et une marge d’adaptation.
On n’embauche pas des gens intelligents pour leur dire quoi faire.
Dans des environnements complexes, la performance dépend moins d’instructions détaillées que d’une intention claire, de contraintes strictes et d’espace d’adaptation.
Vous avez engagé des gens intelligents. Ensuite, vous leur avez écrit un scénario.
Le Sprint Backlog est rempli de tâches décomposées à l’heure près. Les critères d’acceptation ressemblent à des instructions pour assembler les meubles. Le Daily Scrum devient un rituel de reporting pour des personnes extérieures à l’équipe. L’organisation, la seule chose qui rend le travail de connaissance productif, disparaît avant même que le Sprint ne commence.
La plupart des praticiens Agile reconnaissent cela comme du micro-management. Moins comprennent pourquoi cela arrive.
Le vrai problème n’est pas le contrôle.
Le micro-management peut être un délire de pouvoir, mais la plupart du temps, c’est un échec de clarté déguisé en contrôle.
Les managers prescrivent des méthodes et des résultats parce qu’ils ne font pas confiance à ce que l’intention soit suffisamment comprise. Les gens du produit surspécifient parce qu’ils craignent que le résultat réel soit ambigu. La personne qui donne les instructions ne parvient pas à exprimer ce que signifie « bien », alors elle dicte les étapes à la place.
Cette approche n’est pas un défaut de caractère. C’est une défaillance systémique : une tentative de fabriquer la certitude en verrouillant une méthode dans des conditions où le résultat lui-même reste incertain. Dans des environnements complexes, cette approche échoue de manière prévisible. La méthode commence à se dégrader dès que les conditions changent, et dans les travaux complexes, elles restent rarement immuables.
Communiquez l’état final souhaité, ses contraintes et le but de la mission. Puis faites confiance aux personnes qui font le travail pour déterminer comment y parvenir, s’adaptant au changement des conditions.
Cette approche ne vise pas à militariser le travail. C’est plutôt l’inverse : décentralisez l’exécution parce que le centre ne dispose jamais d’assez d’informations dans des conditions complexes.
Et ce n’est pas du théâtre d’autonomisation. L’Intention du Commandant est très précise là où elle compte et relâchée là où elle doit l’être. La différence avec le micro-management n’est pas moins de leadership, mais un leadership différent : une réflexion plus intense au départ, une communication plus claire et une retenue délibérée sur la méthode.
Un briefing utile basé sur l’intention du commandant comporte 5 parties :
Résultat : À quoi ressemble « fait (done) » ?
But : Pourquoi cela est-il important maintenant ? Qu’est-ce qui est en jeu ?
Contraintes : Qu’est-ce qui est non négociable ?
Critères de réussite : Comment allons-nous mesurer ?
Déclencheurs d’escalade : Quels signaux devraient inciter à une conversation plutôt qu’à une décision unilatérale ?
Cette structure donne aux équipes suffisamment de contexte pour s’adapter intelligemment lorsque la réalité brise le plan.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Pourquoi les équipes Agiles en ont besoin.
Scrum est conçu pour cette réalité : dans un travail complexe, l’adaptation dépend du jugement local. Le Product Owner apporte une clarté sur la valeur, les résultats souhaités et les priorités. Les développeurs décident comment transformer cette intention en un incrément fonctionnel. L’équipe Scrum s’autogère dans ces limites.
Le Scrum Guide 2020 a explicitement rendu cet engagement structurel : l’objectif de Sprint (Sprint Goal) est l’engagement pour le Sprint Backlog, et il « offre de la flexibilité quant au travail exact nécessaire pour l’atteindre ». Le Sprint Goal est l’analogue le plus proche du Commander’s Intent, mais il ne fonctionne que lorsque l’équipe comprend aussi son but, les contraintes qui l’entourent et l’espace pour s’adapter.
En supprimant cette compréhension, on obtient le Scrum Theater : une équipe qui exécute les tâches, attend l’approbation et livre exactement ce qui a été spécifié, même lorsque la réalité a déjà évolué.
Chaque coach expérimenté a vu cela se produire : une partie prenante importante dicte les détails de la mise en œuvre, et l’équipe cesse de réfléchir pour se concentrer sur être payée. La partie prenante n’a pas le contexte nécessaire pour prendre de bonnes décisions. Le même schéma se répète : l’intention floue est remplacée par une méthode prescriptive.
La même erreur, un nouvel outil.
La raison pour laquelle ce principe est important au-delà de Scrum est simple : il s’applique chaque fois que l’exécution se fait plus proche de la réalité que la planification.
Considérez combien de personnes interagissent avec les agents IA : des requêtes qui ressemblent à des tickets Jira infusés de Gherkin, avec des instructions étape par étape, un format de sortie fixe et chaque paragraphe dicté à l’avance.
Comparez 2 approches :
Prescriptif : « Rédigez un article de blog de 500 mots. Utilisez trois en-têtes. Commencez par une définition de l’agilité. Incluez une liste à puces de cinq avantages. Terminez par un appel à l’action. »
Basé sur l’intention : « J’ai besoin d’un billet qui mette au défi les Scrum Masters d’arrêter de confondre la conformité aux processus avec l’agilité réelle. Le public connaît le cadre. Le ton doit être direct et inconfortable. »
Le premier prompt est plus susceptible de produire un résultat générique. Le second est plus susceptible de produire quelque chose qui vaut la peine d’être lu. Cela ne signifie pas que la structure est mauvaise. Cela signifie que sur-spécifier une méthode devient contre-productif lorsque la tâche nécessite du jugement ou une adaptation.
Le schéma est le même dans les deux cas : lorsqu’un avis est requis, la clarté de l’intention combinée à la latitude dans l’exécution l’emportent sur un script trop spécifié.
La compétence d’intention du commandant.
Si vous travaillez avec Claude, vous pouvez mettre en pratique l’Intention du Commandant dès maintenant. J’ai créé une « Commander’s Intent skill » gratuite qui s’exécute comme une couche invisible de pré-exécution sur chaque tâche que vous envoyez.
Au lieu de vous demander d’écrire des instructions détaillées, il identifie quand votre intention est floue et pose les bonnes questions avant d’exécuter, tout comme le ferait un collègue avisé. Quand votre intention est déjà claire, il s’efface et produit le résultat. Téléchargez la Commander’s Intent skill et voyez la différence entre dicter la méthode et communiquer l’intention : Téléchargez le Claude Skills Pack .
Conclusion : L’intention du commandant est le modèle opérationnel.
La prochaine fois que vous rédigez un objectif de Sprint, demandez-vous :
Transmet-il l’intention, ou est-ce qu’il dicte la méthode ?
Dans les systèmes complexes, le leader qui dicte la méthode devient le goulot d’étranglement. Le leader qui clarifie l’intention crée les conditions pour l’adaptation.
1 L’intention du commandant est enracinée dans la tradition prussienne de l’Auftragstaktik (tactiques par type de mission) : les leaders communiquent leur objectif et l’état final désiré, tandis que les leaders subordonnés conservent la liberté d’exécution en fonction des circonstances.
partagez ce billet avec vos amis, collègues et relations professionnelles
Lors de la refonte du backlog produit, j’utilise une question simple :
Savons-nous assez pour croire que cet article peut probablement être terminé en sprint ?
C’est tout.
Je ne demande pas si nous avons répondu à toutes les questions possibles.
Je ne demande pas si nous avons finalisé toutes les décisions de conception.
Je demande si nous avons assez de compréhension pour prendre un engagement responsable.
Si la réponse est oui, nous arrêtons d’affiner.
Si la réponse est non, nous identifions la plus grande inconnue et la résolvons avant d’introduire l’objet dans le sprint.
L’affinement n’est pas affaire de certitude. C’est une question de confiance.
Lorsque les équipes essaient d’éliminer toute incertitude, l’affinement devient pesant. Les réunions durent longtemps. L’énergie chute. Et ironiquement, la prévisibilité ne s’améliore pas.
Mais lorsque l’affinement se concentre sur ce seul enjeu « assez de clarté pour tenir dans un sprint », la planification du sprint devient plus facile et les engagements plus réalistes.
Il existe un type particulier d’anxiété qui hante les organisations qui développent des logiciels. Cela se manifeste par des chaînes d’approbation sans fin, des demandes pour des demandes, des commissions de revue d’architecture qui se réunissent trimestriellement, et des processus de déploiement si baroques qu’ils nécessitent leur propre équipe de documentation.
Cela vient d’un endroit raisonnable. Le logiciel est invisible jusqu’à ce qu’il tombe en panne, et quand il tombe en panne, il le fait coûteusement. Alors nous cherchons à contrôler.
Le problème, c’est que le contrôle, au-delà d’un certain point, produit le chaos qu’il est justement censé empêcher.
L’illusion de sécurité
J’ai travaillé avec une équipe qui demandait sept approbations pour déployer un seul changement en ligne. La logique était irréprochable : plus d’yeux signifiait moins d’erreurs. En pratique, cela signifiait que les déploiements étaient regroupés en livraisons massives et peu fréquentes, chacune étant une terrifiante partie de roulette russe. Quand quelque chose se cassait, personne ne savait lequel des quarante changements en était la cause.
Pendant ce temps, une équipe au bout du couloir mettait en production des dizaines de fois par jour sans aucune validation. Leur secret n’était pas l’imprudence. C’était un investissement dans les tests automatisés, les feature flags* et le retour en arrière instantané. Ils avaient remplacé la surveillance humaine par la résilience systémique.
*feature flags – Les indicateurs de fonctionnalités (également appelés commutateurs ou interrupteurs de fonctionnalités) sont des morceaux de code logique if/else utilisés pour activer ou désactiver des fonctionnalités. Ils peuvent être activés ou désactivés manuellement ou lorsque certaines conditions sont remplies.
La première équipe se sentait en sécurité. La deuxième équipe était en sécurité.
Le contrôle comme symptôme
Lorsque vous constatez un contrôle excessif dans une organisation, vous observez un symptôme plutôt qu’une solution. Creusez sous la surface et vous trouverez :
Peur du blâme. Dans les cultures où l’échec est puni, les gens construisent des forteresses bureaucratiques. Chaque approbation est une responsabilité répartie. Si quelque chose tourne mal, au moins sept personnes l’ont approuvé.
Manque de confiance. Le micro-management est un problème de confiance caché sous des processus. Si vous faites confiance à vos ingénieurs, vous leur donnez des garde-fous et de l’autonomie. Sinon, vous leur donnez des listes de contrôle et de la surveillance.
Absence de boucles de rétroaction. Les mécanismes de contrôle se multiplient lorsque les organisations ne peuvent pas savoir si leur logiciel fonctionne réellement. Si vous disposez d’une surveillance robuste, d’alertes et d’un retour en arrière rapide, vous n’avez pas besoin qu’un comité approuve un changement de couleur de bouton.
Le paradoxe du couplage serré
L’architecture logicielle reflète la psychologie organisationnelle. Les équipes orientées contrôle construisent des systèmes orientés contrôle : des monolithes où chaque changement nécessite une coordination entre des dizaines de composants, des bases de données partagées qui rendent impossible un déploiement indépendant, des flux de travail d’approbation encodés dans le logiciel lui-même.
Ces systèmes semblent gérables car tout est visible et centralisé. Mais ils sont fragiles. Un point de défaillance unique devient un point unique de paralysie. L’organisation qui voulait le contrôle finit par être contrôlée par sa propre architecture.
L’alternative n’est pas le chaos : c’est un découplage réfléchi.
De petits services indépendants. Des contrats clairs. Des équipes qui livrent sans attendre l’autorisation de six autres équipes. Cela implique de renoncer au confort de tout savoir, et d’accepter que les systèmes distribués sont intrinsèquement plus difficiles à comprendre. Mais ce découplage échange un faux contrôle contre une vraie résilience.
À quoi ressemble un contrôle sain ?
Rien de tout cela ne signifie que le contrôle est mauvais. Les systèmes incontrôlés sont terrifiants à leur manière : codage de cowboy, bases de données de production accessibles aux stagiaires, déploiements qui ont lieu quand quelqu’un en ressent l’envie.
La distinction se situe entre contrôler les personnes et contrôler les résultats.
Les organisations saines s’obsèdent sur ce dernier :
Nous contrôlons la fiabilité en investissant dans la surveillance et la réponse aux incidents, et non en exigeant des tests manuels à chaque déploiement.
Nous contrôlons la sécurité en intégrant des mesures sécurisées par défaut sur nos plateformes, et non en obligeant les développeurs à remplir des questionnaires de sécurité qu’ils ne comprennent pas.
Nous contrôlons la qualité en recrutant bien, en fournissant un contexte clair et en créant des boucles de rétroaction rapides, pas en instituant une revue de code par des personnes très éloignées du travail.
Le but est de rendre la bonne chose facile et la mauvaise difficile. C’est un problème de conception, pas de permissions.
Lâcher prise
La partie la plus difficile pour réparer une culture obsédée par le contrôle, c’est qu’il faut que les personnes en contrôle l’abandonnent. C’est vraiment difficile à demander. Le contrôle est apaisant. L’autonomie — pour les autres — est stressante.
Mais voilà le truc : vous n’avez jamais vraiment eu le contrôle de toute façon. Vous aviez une apparence de contrôle, maintenu à un coût énorme en vitesse, en moral, et en l’attrition silencieuse de vos meilleurs éléments (qui partaient vers des endroits où on leur faisait confiance). Les réunions, les signatures, les commissions de revue, c’étaient un rituel, pas une sécurité.
La vraie sécurité vient des systèmes qui supposent que la panne va survenir et qui s’en remettent en douceur. D’équipes qui expérimentent sans permission et apprennent sans être blâmées. Des architectures qui se plient au lieu de se briser.
La poigne la plus ferme ne vous protège pas. Elle fatigue juste vos mains.
Les meilleures cultures d’ingénierie partagent un trait commun : elles sont obsédées par les résultats et décontractées quant aux méthodes. Elles précisent ce qui doit être vrai — le système doit être fiable, sécurisé, maintenable — puis s’écartent. Quand on explique aux gens intelligents à quoi ressemble le succès et qu’on leur donne les outils pour y parvenir, ils le font.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
Un événement Scrum utile doit apporter de la clarté, de l’énergie, ou les deux.
DantotsuPM.com 