Catégorie : agile

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

La géographie de l’état d’esprit collectif.

Le par mopertodans agile, experience sharing, pointeurs utilesLaisser un commentaire

L’état d’esprit collectif, c’est l’eau que le poisson ne remarque pas mais sans laquelle il ne peut vivre.

The Geography of the Collective Mindset par Bob Marshall

https://flowchainsensei.wordpress.com/2026/07/01/the-geography-of-the-collective-mindset/

Nous parlons beaucoup ici de la mentalité collective : l’ensemble d’hypothèses (partagé, en grande partie de manière tacite) qu’une organisation a sur la manière dont le travail devrait fonctionner.

C’est l’eau que le poisson ne remarque pas. Et l’une des vérités les plus inconfortables à propos de cette eau est qu’une grande partie de sa chimie est versée bien avant que quiconque ne rejoigne l’organisation. Elle arrive avec les gens. Elle arrive sous forme de culture nationale, et la culture nationale a une géographie.

Geert Hofstede a passé des décennies à en dessiner la carte. Travaillant à l’origine avec des données d’enquête auprès d’employés d’IBM dans environ soixante-dix pays, il a proposé que les cultures nationales diffèrent selon quelques dimensions mesurables – des coordonnées, si l’on veut, selon lesquelles la culture d’un pays peut être située à peu près.

La carte est rudimentaire, l’enquête a ses critiques (nous en reparlerons plus bas), et pourtant elle reste l’un des graphiques les plus utiles que nous ayons pour remarquer pourquoi une pratique qui fonctionne parfaitement dans une partie du monde se bloque dans une autre.

Je souhaite parcourir quatre régions de cette carte – la Chine, l’Europe continentale, la Scandinavie et les États-Unis – et me demander ce que le terrain de chacune implique pour l’état d’esprit collectif sur le lieu de travail. Pas pour écraser qui que ce soit par des stéréotypes, mais pour retracer le mensonge du pays qui passe si souvent inaperçu.

Lecture des coordonnées

Hofstede nous donne six axes.

Les quatre qui comptent le plus pour nos besoins ici :

  1. Distance de pouvoir – à quel point une culture accepte facilement que le pouvoir soit réparti de manière inégale. Une grande distance de pouvoir signifie que la hiérarchie semble naturelle et que le boss est le boss. Une faible distance de pouvoir signifie que le boss doit se justifier comme tout le monde.
  2. Individualisme versus collectivisme – que l’identité soit construite autour du « je » ou du « nous ». Dans les cultures individualistes, vous êtes responsable de vous-même ; dans les collectivistes, vous appartenez à un groupe qui veille sur vous, et auquel vous devez loyauté.
  3. Évitement de l’incertitude – à quel point une culture est à l’aise avec l’ambiguïté et l’inconnu. L’évitement élevé exige des règles, de la structure et des réponses claires. L’évitement faible hausse les épaules face au désordre et improvise.
  4. Masculinité contre féminité – les labels les moins réussis de Hofstede, mais l’idée sous-jacente est solide : qu’une culture valorise la compétition, la réussite et l’affirmation, ou la coopération, le soin et la qualité de vie.

(Il y en a deux autres, Orientation à long terme et Indulgence, que je vais légèrement aborder.)

Maintenant, les quatre régions.

La Chine : la vision à long terme, défendue collectivement.

La Chine est très présente sur la distance de pouvoir et profondément enfoncée en territoire collectiviste. En termes de travail, cela produit un état d’esprit où la hiérarchie n’est pas un problème à aplanir mais une structure à respecter. L’attente fonctionne dans les deux sens : les subordonnés s’inclinent, mais ceux au-dessus ont une véritable obligation envers ceux d’en dessous. La loyauté envers le groupe – l’équipe, l’entreprise, la famille sur laquelle l’entreprise est implicitement inspirée – prime sur l’affirmation de la préférence individuelle.

Ce qui frappe, c’est la combinaison avec une orientation à long terme extraordinairement élevée, parmi les plus élevées jamais enregistrées à Hofstede. L’état d’esprit collectif ici est patient. Il tolère le sacrifice présent pour une position future, valorise la persévérance et considère les relations (guanxi) comme des actifs durables plutôt que comme des échanges transactionnels. L’évitement de l’incertitude, fait intéressant, est assez bas – il y a un confort pragmatique avec l’ambiguïté, une volonté de laisser les choses vaguement définies et de s’adapter.

Pour quiconque porte les pratiques occidentales dans ce paysage, la friction se manifeste généralement autour de la responsabilité individuelle et des contestations ouvertes. Une rétrospective qui invite les gens à critiquer publiquement les décisions prises au-dessus d’eux demande au groupe de violer quelque chose de profond. Le flux vient du travail avec la hiérarchie et le visage du groupe, pas contre eux.

Europe continentale : l’ordre, et l’inconfort de ne pas savoir

L’« Europe » est, bien sûr, une fiction – un continent, pas un pays, et l’une des parties les plus variées de toute la carte. L’Europe latine n’est pas l’Europe germanique, qui n’est pas l’Europe de l’Est. Mais si l’on met la Scandinavie de côté (on y reviendra) et que l’on observe le vaste centre continental – Allemagne, France, Italie, Espagne et leurs voisins – un élément commun du terrain apparaît.

C’est un évitement élevé de l’incertitude. C’est peut-être le trait européen le plus constant, et cela façonne l’état d’esprit collectif du milieu de travail plus que ce que les gens réalisent. Cela se manifeste par une préférence pour la structure, l’expertise, des spécifications claires, des qualifications et un processus bien défini. Les plans comptent. Les rôles comptent. La parole de l’expert a du poids précisément parce que l’expertise réduit l’incertitude (prétendument). Là où une startup américaine pourrait joyeusement shipper et voir, une culture d’ingénierie allemande veut d ‘abord savoir.

La distance de pouvoir varie dans la région – modeste en Allemagne, nettement plus élevée en France avec sa tradition d’élite accréditée et de décision centralisée. L’individualisme est généralement élevé, bien que plus communautaire en Méditerranée et dans le Sud.

L’état d’esprit collectif ici perçoit souvent, aux yeux des étrangers, comme bureaucratique. Mais ce n’est pas le bon cadre. Ce qui ressemble à de la bureaucratie est souvent une tentative culturellement enracinée de rendre le monde prévisible et d’honorer la compétence. La dysfonction ne vient pas du désir d’ordre, mais du fait que l’ordre se calcifie en rituel bien après avoir cessé de servir quiconque – ce qui est, bien sûr, un danger pour toute organisation, n’importe où sur la carte.

Scandinavie : le « nous » discrètement radical

La Scandinavie mérite un traitement séparé car, sur un certain axe, elle est vraiment exceptionnelle. La Suède, la Norvège et le Danemark obtiennent de loin les scores les plus bas au monde sur l’échelle de masculinité de Hofstede. La Suède se situe presque tout en bas. C’est un ensemble de cultures qui, par mesure, privilégient la coopération plutôt que la concurrence, l’attention aux autres sur la conquête, et la qualité de vie plutôt que l’accumulation du statut.

Ajoutez à cela une faible distance de pouvoir – celle du Danemark est parmi les plus basses – et vous obtenez un état d’esprit collectif au travail, presque conçu sur mesure pour ce type de travail auto-organisé, distribué et à haute confiance que nous défendons si souvent et que nous atteignons si rarement. L’autorité est douce. Le consensus est la norme, parfois à l’excès. Le concept nordique de lagom (grossièrement, « juste la bonne quantité », pas trop) et la Loi de Jante sur l’inconfort envers quiconque se place au-dessus du groupe expriment tous deux le même instinct : le « nous » est réel, et l’individu qui attire trop la lumière est doucement corrigé.

Pour ceux d’entre nous qui s’intéressent au flux et à des façons plus saines de travailler ensemble, cette partie de la carte est en quelque sorte une expérience naturelle. Une grande partie de ce qui se lit comme une innovation managériale éclairée ailleurs est, ici, simplement la façon dont les choses ont longtemps été faites. La prudence est évidente : ce qui pousse dans ce sol ne se transplante pas automatiquement. La recherche de consensus qui est libératrice à Copenhague peut ressembler à une paralysie dans des cultures qui attendent de quelqu’un qu’il décide.

Les États-Unis : le culte de l’individu

Les États-Unis occupent la limite sur l’axe de l’individualisme – le score le plus élevé jamais enregistré par Hofstede, la culture la plus individualiste sur Terre selon ses données. Cette seule coordonnée explique beaucoup de choses sur la mentalité au travail américain. Le soi-même est l’unité de sens. La réussite personnelle, la responsabilité individuelle, la mobilité individuelle, le héros individuel – ce ne sont pas des modes dans le management, ce sont les fondations du terrain. (Et toxique pour la pensée systémique).

Ajoutez à cela une orientation assez masculine (la compétition, la victoire et la réussite sont bonnes et méritent d’être célébrées ouvertement) et une orientation à court terme (résultats maintenant, ce trimestre, ce sprint), et vous obtenez un état d’esprit collectif qui paradoxalement n’est pas du tout collectif. Les organisations américaines sont souvent des coalitions d’individus intéressés, dynamisés par l’ambition, fluides dans leurs loyautés et prompts à agir. La distance de puissance est faible, donc le fondateur déjeune avec le stagiaire et les titres comptent moins que les résultats.

Les forces sont réelles : dynamisme, courage entrepreneurial, volonté d’échouer et de réessayer, et une franchise rafraîchissante. L’ombre est tout aussi réelle. Une culture aussi individualiste lutte avec le véritable collectif. Le « travail d’équipe » est célébré bruyamment précisément parce qu’il va à contre-courant du pays. Le « nous » doit être construit de manière délibérée, avec effort – et tend à disparaître dès que les incitations individuelles se tournent ailleurs.

Notre partenaire Lefebvre Dalloz Compétences propose des formations pour mieux manager et piloter tous les changements.

La carte n’est pas le territoire.

Voici ce à quoi je reviens sans cesse. La culture nationale décrit le terrain, mais elle ne fixe pas l’itinéraire. Une organisation a sa propre mentalité collective – son propre méméplex*– et cette mentalité peut, et fait souvent, diverger fortement du paysage environnant. Il existe des entreprises profondément hiérarchiques au Danemark égalitaire et des entreprises véritablement communautaires dans l’Amérique individualiste. Les coordonnées nationales indiquent la position du terrain et la direction que tend le vent, pas l’endroit où un navire particulier va réellement naviguer.

* Un méméplexe (ou memeplex en anglais) est un groupe de mèmes culturels reliés entre eux qui se renforcent mutuellement pour se propager plus efficacement dans les esprits, à la manière d’un complexe de gènes en biologie.

Ce que fait la carte de Hofstede, c’est

nous mettre en garde contre une préconception particulière : l’hypothèse qu’un mode de travail qui s’enchaîne parfaitement dans une région possède une certaine validité universelle.

C’est rarement le cas. Les pratiques agiles et lean que tant d’organisations importent aujourd’hui en grande partie ont été forgées dans des sols culturels spécifiques – le collectivisme japonais et l’orientation à long terme vers le lean, un individualisme anglo-américain pour une grande partie de l’agilité. Sortez-les de cette terre et vous ne transplantez pas une pratique ; Vous transplantez un ensemble d’hypothèses culturelles que le nouvel hôte pourrait discrètement rejeter.

Si vous essayez de changer un état d’esprit collectif – et je dirais que c’est le seul type de changement organisationnel qui compte finalement – il est utile de savoir quelles hypothèses présentes dans la salle sont organisationnelles et changeantes, et lesquelles sont culturelles et bien plus profondément enracinées dans le sol. Vous pouvez renégocier les premières sur quelques mois de dialogue patient. Les secondes peuvent sembler bien plus insolubles.

Une mise en garde nécessaire concernant le cartographe.

Il serait malhonnête de s’en tenir là. La carte de Hofstede a suscité de sérieuses critiques, et ces critiques méritent d’être prises en compte. L’enquête originale provenait d’une seule entreprise, il y a des décennies, et le monde a changé.

Les nations ne sont pas culturellement homogènes – traitant la « Chine » ou « l’Europe » comme des papiers uniques sur une énorme variation interne, comme une moyenne nationale unique cache montagnes et vallées. Et la fausse erreur écologique se cache tout au long : les coordonnées d’un pays ne vous disent presque rien de fiable sur l’individu assis en face de vous à la table, qui peut être totalement atypique par rapport à ses compatriotes. La critique bien connue de Brendan McSweeney va encore plus loin, s’interrogeant sur la possibilité de traiter sensément les cultures nationales comme des causes de comportements.

Alors lisez et prenez ces indications comme de simples indications. Elles sont une carte, pas le territoire. Utilisées comme un moyen de remarquer – de faire émerger des suppositions que vous n’auriez autrement pas examinées, de poser de meilleures questions sur pourquoi une pratique ne fonctionne pas – elles méritent leur place. Utilisées pour prédire ou encadrer la personne devant vous, elles vous induiront en erreur et, pire encore, l’insulteront.

L’état d’esprit collectif est une chose toujours vivante. La géographie le façonne. Mais ce n’est pas une prison, et les organisations les plus intéressantes sont précisément celles qui ont discrètement redessiné leurs propres frontières.

Pour aller plus loin

Hofstede, G. (1980). Culture’s consequences: International differences in work-related values. Sage.

Hofstede, G. (2011). Dimensionalizing cultures: The Hofstede model in context. Online Readings in Psychology and Culture, 2(1).

Hofstede, G., Hofstede, G. J., & Minkov, M. (2010). Cultures et organisations : Logiciels de l’esprit : coopération interculturelle et son importance pour la survie (3e éd.). McGraw-Hill.

McSweeney, B. (2002). Hofstede’s model of national cultural differences and their consequences: A triumph of faith – a failure of analysis. Human Relations, 55(1), 89–118.

Hofstede, G. (s.d.). Country comparison bar charts [Data visualisation tool]. Retrieved 25 June 2026, depuis

Nous devons devenir meilleurs pour mettre en place le « changement ». par Lenka Pincot

Le par mopertodans agile, experience sharing, leadershipLaisser un commentaire

We need to get better at « changing ».

La préparation au changement et à la transformation ne se produit pas par hasard. Les agilistes et managers de projet ont un rôle important pour aider à le construire.

Lors de la conférence PMI Agile 2026, nous avons exploré quatre tensions issues des dernières recherches du Project Management Institute sur ce qui ralentit l’exécution des stratégies des organisations.

1. La stratégie est claire au sommet, mais l’intention se perd en descendant.

💡 Pourquoi : Au fur et à mesure que l’information se propage à travers les couches, les équipes reçoivent des instructions sans suffisamment de contexte. Alors que 82 % des leaders et des employés estiment que l’alignement stratégique est en place, seuls 23 % peuvent le rejouer.

💠 Que faire : Continuez à relier les projets et produits à leur but, aux résultats et aux compromis. Laissez à vos équipes suffisamment de temps pour assimiler les directives, demandez des précisions, et rappelez-leur sans cesse le contexte général tout au long du cycle de vie.

2. Les organisations veulent la rapidité, mais les décisions restent centralisées.

💡 Pourquoi : Les équipes sont censées avancer rapidement sans avoir l’autorité d’agir. Déléguer la prise de décision là où le travail se déroule est le troisième facteur le plus influent pour l’agilité des entreprises, mais les PDG admettent aussi que c’est très difficile à atteindre.

💠 Que faire : Trop de contrôle crée du retard et trop de liberté sans garde-corps engendre le chaos. La réponse pratique n’est pas une autonomie illimitée ; C’est une autorité claire avec des garde-fous clairs. Les professionnels doivent continuellement accroître leur sens des affaires pour communiquer où des décisions doivent être prises et pour présenter les problèmes et obstacles dans le langage exécutif, en articulant les compromis et en étant transparents sur les conséquences.

3. Les équipes travaillent dans des structures conçues pour la stabilité, pas pour l’adaptabilité.

💡Pourquoi : les silos, les approbations et les processus fixes ralentissent l’adaptation. Seulement environ la moitié des PDG s’accordent à dire que leurs modèles de gouvernance sont prêts pour l’agilité des entreprises, seuls 41 % des cadres déclarant que leurs modèles d’exploitation soutiennent la réallocation rapide du capital et des talents.

💠 Que faire : Exposer la friction récurrente comme un problème système, pas seulement comme un problème de livraison. Nous traitons souvent la livraison lente comme un problème de processus, mais le vrai problème est souvent le modèle opérationnel. Le travail avance à la vitesse de la dépendance la plus lente.

4. Les leaders veulent de la transparence, mais les gens peuvent ne pas se sentir en sécurité pour s’exprimer.

💡 Pourquoi : Selon Gallup, seuls 27 % des employés estiment que leur opinion compte au travail. Faire ressortir les risques et désaccords peut être vu comme une résistance, ce qui repousse encore davantage le dialogue.

💠 Que faire : Normaliser les défis constructifs, mettre les problèmes en lumière dès le début et inviter différentes voix. Si les gens ne se sentent pas en sécurité pour faire remonter des risques, remettre en question les hypothèses ou dire « ça ne fonctionne pas », l’organisation perd les signaux nécessaires pour s’adapter. La sécurité psychologique n’est pas un sujet culturel léger ; C’est une exigence opérationnelle pour la rapidité, l’apprentissage et la gestion des risques.

Quelle est votre façon de combler ces écarts ?

PMI is a registered mark of Project Management Institute, Inc.

« Scrum a besoin du soutien des leaders » par Mike Cohn

Le par mopertodans agile, leadershipLaisser un commentaire

Les leaders doivent créer un environnement où les bons comportements soient possibles pour que Scrum et les approches Agile réussissent.

Scrum needs leadership support by Mike Cohn, Mountain Goat Software

L’une des plus grandes erreurs des leaders est de traiter Scrum ou agile comme quelque chose d’isolé par rapport aux équipes.

  • Les équipes seront agiles.
  • Les équipes vont adopter Scrum.
  • Les équipes tiendront les réunions.
  • Les équipes deviendront plus rapides.

Mais l’organisation environnante reste largement inchangée.

Ce n’est pas durable.

Scrum demande aux équipes de se concentrer, de collaborer, d’inspecter, d’adapter et de livrer des incréments de travail précieux.

Pour que cela se produise, les leaders doivent créer un environnement où ces comportements sont possibles.

  • Cela signifie souvent éliminer les silos et former des équipes interfonctionnelles.
  • Cela signifie donner un défi aux équipes puis s’écarter suffisamment pour qu’elles puissent le résoudre.
  • Cela signifie résister à la tentation de remettre en question les décisions de l’équipe.
  • Cela signifie permettre aux équipes de dire la vérité sur des délais trop optimistes, des encadrements irréalistes et des risques qu’elles voient dans le travail.

Une équipe ne peut pas donner le meilleur d’elle-même tout en étant poussée à s’engager dans des choses qu’elle ne juge pas réalisables.

Une équipe ne peut pas s’automanager si chaque décision significative est prise ailleurs.

Une équipe ne peut pas livrer des résultats prévisibles si les dirigeants la redirigent constamment et agissent ensuite surpris lorsque le plan initial n’est pas réalisé.

Un bon soutien du leadership signifie façonner l’environnement pour que les équipes puissent réussir.

Lorsqu’une échéance ou un champ d’action souhaité n’est pas réalisable, les dirigeants et les équipes doivent considérer cela comme un problème commun à résoudre.

Peut-être que la portée peut être réduite. Peut-être que plus de temps serait nécessaire. Peut-être qu’une autre approche est possible. Peut-être qu’une autre initiative devrait être retardée. Peut-être que l’organisation doit accepter plus de risques.

La première étape est de dire la vérité.

Scrum fonctionne mieux dans les organisations où la vérité est bienvenue.

Essayez ceci : la prochaine fois qu’une équipe dit qu’une date limite ou un champ d’action n’est pas faisable, ne demandez pas : « Comment pouvez-vous encore y arriver ? », demandez :

Que faudrait-il changer pour que cela devienne réalisable ?

Cette question transforme la conversation de la pression en résolution de problèmes.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Beaucoup de problèmes avec Scrum sont en réalité des problèmes de focalisation. par Mike Cohn

Le par mopertodans agileLaisser un commentaire

Les organisations essaient de faire trop de choses à la fois.

Many Scrum problems are really focus problems.

Les organisations essaient de faire trop de choses à la fois. Elles ont trop d’initiatives, trop de demandes urgentes, trop de parties prenantes, trop de priorités, et trop peu de volonté de dire « pas maintenant ».

Scrum rend cela visible.

Un sprint crée un horizon de planification court pour décider de ce que l’équipe pourra accomplir ensuite. Un objectif de sprint identifie un résultat suffisamment important pour que l’équipe puisse s’organiser autour de celui-ci. Un arriéré de produit rend visible ce qui est plus important que d’autres items.

Ce sont des conversations inconfortables dans une organisation qui veut tout en même temps.

Ainsi, la difficulté est souvent reportée sur les équipes et les propriétaires de produit (product owners)

Les product owners sont invités à satisfaire trop de parties prenantes. Les équipes sont invitées à engager plus de travail qu’elles ne peuvent en finir. Les dirigeants demandent de la prévisibilité tandis que les priorités continuent d’évoluer. Tout le monde veut les bénéfices de la concentration sans faire les compromis que la concentration exige.

Ça ne marche pas.

Un product owner peut aider en apportant un focus à l’équipe. Cela signifie dire ce qui doit être fait et, tout aussi important, ce qui ne doit pas être fait maintenant.

Mais les product owners ont besoin de soutien.

Un product owner entouré de parties prenantes qui estiment que chaque demande est urgente aura du mal à créer un focus, à moins que les leaders n’aident à établir l’attente que tout ne peut pas être prioritaire.

C’est une des raisons pour lesquelles Scrum peut être frustrant.

L’équipe est invitée à s’engager sur un objectif de sprint, mais l’organisation continue de se comporter comme si tout était urgent. L’équipe est invitée à être prévisible, mais les priorités changent sans cesse. Le product owner est censé prendre de bonnes décisions prioritaires, mais chaque partie prenante souhaite une réponse différente.

Scrum met en lumière la nécessité d’une priorisation difficile.

Cette exposition est utile. Cela donne à l’organisation la possibilité de prendre de meilleures décisions.

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

Essayez ceci : Avant le prochain sprint, demandez aux parties prenantes et aux leaders de compléter cette phrase :

Pour que cette équipe réussisse au prochain sprint, nous choisissons de ne pas encore travailler sur ____.

Si personne ne peut combler le vide, l’équipe n’a probablement pas suffisamment de focus. Le sprint comporte une liste de demandes concurrentes.

« Scrum devrait être utile » Mike Cohn

Le par mopertodans agileLaisser un commentaire

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.

  1. Choisissez l’événement Scrum que votre équipe valorise le moins.
  2. Demandez : « Qu’est-ce que cet événement devrait nous aider à accomplir ? ».
  3. 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.

 

Remettez en question toutes les exigences.

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

« Les Simplificateurs sont des accélérateurs. » Jon McNeill

Challenge All Requirements par Dan Rockwell

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.

  1. Quel problème résout-elle ?
  2. Que se passe-t-il si on ne fait pas ça ?
  3. Est-ce une règle, ou c’est juste comme ça qu’on a toujours fait ?
  4. Qui en bénéficie vraiment ?
  5. 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.

Cet article est basé sur «The Algorithm: The Hypergrowth Formula that Transformed Tesla, Lululemon, General Motors and SpaceX », par Jon McNeill, ancien président de Tesla.

« BUILD VS. BUY » GUIDE – Libérez le retour sur investissement du développement de vos ressources internes

Le par mopertodans agile, formations et certificationsLaisser un commentaire

Unlock the ROI of internal development by ScrumAlliance®

https://resources.scrumalliance.org/guides-and-playbooks/build-vs-buy

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.

Ne découpez pas les histoires de cette façon.

Le par mopertodans agileLaisser un commentaire

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.

Scaling AI with Agility: Your Foundation for Success par ScrumAlliance®

Le par mopertodans agileLaisser un commentaire

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 transparence et 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.

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

Le par mopertodans agile, best practices, leadershipLaisser un commentaire

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

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

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

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

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

Cela transparaît aussi dans leurs estimations.

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

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

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

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

Cela n’a pas marché.

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

Les équipes sont déjà optimistes.

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

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

C’est normal.

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

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

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

La même chose arrive aux équipes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ce que la pression fait aux équipes.

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

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

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

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

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

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

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

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

Soyez rapide, mais ne vous pressez pas.

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

Prévisions vs. Plan vs. Engagement.

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

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

Ces mots ne sont pas interchangeables.

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

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

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

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

Le développement logiciel ne fait pas exception.

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

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

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

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

Un leader demande :

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

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

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

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

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

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

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

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

Presque ne suffisait pas.

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

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

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

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

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

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

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

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

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

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

Vous voulez une version pratique de cela ?

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

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

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

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

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

La planification doit être un dialogue.

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

Cela change tout.

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

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

La planification est un problème partagé.

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

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

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

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

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

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

Que devraient plutôt demander les leaders

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

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

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

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

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

Posez ensuite des questions comme :

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

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

C’est ce que les leaders devraient vouloir.

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

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

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

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

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

Le par mopertodans agile, leadershipLaisser un commentaire

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

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

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

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

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

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

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

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

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

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

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

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

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

Que signifie l’intention du commandant ?

L’intention du commandant est simple en concept :

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

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

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

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

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

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

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

Pourquoi les équipes Agiles en ont besoin.

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

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

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

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

La même erreur, un nouvel outil.

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

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

Comparez 2 approches :

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

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

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

La compétence d’intention du commandant.

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

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

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

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

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

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

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

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

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

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

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

C’est tout.

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

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

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

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

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

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

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

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

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

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

Le par mopertodans agile, leadershipLaisser un commentaire

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

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

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

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

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

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

L’illusion de sécurité

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

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

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

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

Le contrôle comme symptôme

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

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

Le paradoxe du couplage serré

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

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

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

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

À quoi ressemble un contrôle sain ?

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

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

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

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

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

Lâcher prise

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

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

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

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

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

Téléchargez le rapport AI4Agile Practitioners 2026

Le par mopertodans agileLaisser un commentaire

83 % des praticiens Agile utilisent l’IA, mais la plupart y consacrent au plus 10 % de temps car ils ne savent pas où elle se situe. Stefan Wolpers

Le rapport AI4Agile Practitioners 2026 inclut des analyses détaillées des réponses par rôle, taille d’organisation et niveau d’agilité. Vous y découvrirez une analyse qualitative complète des défis, préoccupations, réussites et priorités.

Cette enquête auprès de 289 praticiens Agile identifie les véritables obstacles à l’adoption et montre où l’Intelligence Artificielle crée une valeur sur laquelle vous pouvez agir.

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

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

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

Le par mopertodans agileLaisser un commentaire

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

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

How to Provide a Release Plan Without Losing Agility by Mike Cohn

Une feuille de route est un plan, pas une promesse.

Je m’apprête à partir pour un road trip entre l’Idaho et le Colorado : un trajet de 16 heures.

Je sais où je vais, et mon itinéraire général, mais je ne connais pas chaque virage que je vais prendre — et ça me va.

C’est ainsi que les équipes agiles devraient traiter les plans de livraison et les feuilles de route.

Mon itinéraire est un plan, pas une promesse. Il n’est pas gravé dans le marbre. Les virages que j’ai pris et mon temps estimé pouvaient varier en fonction des travaux sur les routes, des embouteillages, d’une opportunité de détour excitant, ou même une crevaison. Plus je dois parcourir de la distance, plus je devrais m’attendre à être ces incertitudes.

Les plans agiles sont identiques. Nous ne pouvons pas prédire chaque éventualité, mais nous pouvons fournir une prévision. Nous pouvons donner une idée générale de la direction que nous envisageons, une plage prévue de moments où nous atteindrons probablement des étapes clés, ainsi que notre niveau de confiance dans le plan.

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

Pourquoi les parties prenantes poussent pour avoir des garanties.

La plupart des équipes agiles savent qu’il y a trop d’incertitude pour tout garantir. En même temps, elles pensent qu’une garantie est la seule chose que les parties prenantes accepteront.

Voici ce que les équipes agiles pourraient manquer : les parties prenantes ont leurs propres plans à établir. Et elles sont tout aussi inquiètes que les équipes Agiles de devoir rendre des comptes sur leurs prévisions.

Les parties prenantes ont besoin de dates de livraison et de jalons justes (notez que je n’ai pas dit précis). Elles recherchent la prévisibilité.

Parfois, on a l’impression qu’elles demandent une garantie. Mais en vérité, la seule façon de leur donner une certitude absolue est de :

  • Charger nos estimations (comme dire à quelqu’un que mes 16 heures de route en prendront 24 heures, juste au cas où), ou
  • Refuser de vous adapter lorsque les conditions changent.

Aucun n’est bon ni pour le produit ni pour l’équipe.

Le chemin vers l’alignement commence par l’empathie.

Alors, que pouvez-vous faire lorsqu’une partie prenante semble vouloir une garantie plutôt qu’une prévision ? Essayez ceci : parlez aux parties prenantes en termes qu’elles comprennent. Voici une technique que j’ai trouvée utile :

Comparez leurs demandes à celles de prévisions similaires dans leur propre domaine.

Par exemple :

  • Demandez à un commercial quel serait son niveau de confort s’il devait garantir précisément combien il vendra — et avec quels clients il conclura — pour chacun des six prochains mois, ou durant la première année de sortie d’un produit.
  • Demandez à un responsable marketing quelles seraient ses préoccupations si on lui demandait de s’engager sur des résultats de campagne précis avec des délais précis.

Ne soyez pas dans la confrontation. L’objectif n’est pas de les piéger, c’est de montrer que l’incertitude existe partout, et que l’agilité est une force, pas une faiblesse.

Donnez aux parties prenantes ce dont elles ont besoin pour réussir.

Ensuite, partagez mon analogie de road trip avec vos parties prenantes. Dites-leur que vous ne pouvez pas leur donner de garantie, mais que vous pouvez présenter une feuille de route pour les 3 à 6 mois. La feuille de route montrera l’objectif de l’équipe, le niveau de progrès que vous pensez pouvoir faire à quel moment (exprimé en fourchette), ainsi que la confiance de votre équipe dans le plan.

Rappelez aux parties prenantes que, comme les itinéraires suggérés lors d’un long trajet, les feuilles de route agiles offrent de la visibilité, alignent les attentes et aident les gens à planifier — sans prétendre que chaque virage est connu à l’avance.

Libérer votre équipe d’attentes irréalistes peut accélérer leur transition de bon à excellent niveau.

P.S. Si votre équipe a du mal à concilier agilité avec attentes des parties prenantes, amenez Mountain Goat dans votre organisation pour un atelier de planification de sortie. Nous aidons les équipes à construire des feuilles de route flexibles et à haute confiance — sans trop s’engager. Vous avez besoin d’aide pour communiquer vos projets ? Essayez notre outil de visualisation de plans, gratuit pour tous les membres de MGS Essentials.   

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

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

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

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

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

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

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

Téléchargez ce manifeste gratuitement

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

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

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

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

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

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

Les 9 principes

Comportement de leadership

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

Conception organisationnelle

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

Exécution

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

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

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

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

 

Le modèle opérationnel du produit agile

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

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

The Agile Product Operating Model

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

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

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

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

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

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

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

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

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

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

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

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

Pas de management de projet zombie par Alan Zucker

Le par mopertodans agileLaisser un commentaire

Les managers de projet zombies se contentent de faire semblant.

No Zombie Project Management par Alan Zucker

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

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

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

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

#1 – Trouvez les zombies

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

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

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

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

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

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

#2 – Tuez les zombies

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

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

#3 – Engagez le cerveau pensant

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

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

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

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

#4 – Établissez l’approche

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

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

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

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

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

#5 – Managez le projet

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

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

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

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

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

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

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

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

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

Le par mopertodans agile, experience sharing, leadershipLaisser un commentaire

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

Bridging Clinical Workflows and Agile Delivery

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

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

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

La transformation, ce sont les personnes avant la technologie.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Manager la résistance avec empathie.

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

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

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

La technologie doit respecter les soins.

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

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

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

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

À propos de l’auteur

Sohail Bashir Chughtai

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

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

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

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