Le pouvoir : quand l'autorité s'empare de la cérémonie

Toute cérémonie agile repose sur le principe de l’égalité des chances. Le pouvoir intervient lorsqu’il n’y en a pas.

Le « Planning Poker » ne permet de contourner l’effet d’ancrage que si personne autour de la table ne peut passer outre les cartes. Une rétrospective n’est fiable que si l’honnêteté n’entraîne aucun coût. La vélocité n’est qu’une prévision si personne au-dessus de l’équipe ne l’évalue. Supprimez ces hypothèses — ajoutez un responsable qui valide les promotions, un indicateur qui remonte la hiérarchie, une estimation qui se transforme en promesse — et la cérémonie ne se contente pas d’être inefficace. Elle se retourne contre vous. Elle commence à jouer contre les personnes pour lesquelles elle a été conçue. Ce chapitre identifie les trois mécanismes les plus marquants par lesquels cela se produit, car les nommer est la première étape pour les rejeter.

Le cliquet de vitesse

Commençons par l’argument le plus percutant de tous : la personne qui a inventé les « story points » s’en est désolidarisée. « J’aime dire que j’ai peut-être inventé les story points, et si c’est le cas, je m’en excuse aujourd’hui », a écrit Ron Jeffries en 2019 — et plus précisément : « Je pense que comparer les équipes sur la qualité de leurs estimations ou leur vélocité est néfaste. » Lorsque l’inventeur d’une unité vous dit que celle-ci est utilisée pour nuire aux équipes, la charge de la preuve incombe alors à quiconque continue de s’en servir comme indicateur de performance.

C’est par le biais du mécanisme de crantage de la vélocité que ce problème se manifeste. La vélocité est censée être un outil d’auto-calibrage propre à chaque équipe — la moyenne glissante des points validés, utilisée pour estimer le temps nécessaire à l’exécution du backlog. Dès qu’elle sort du cadre de la salle pour devenir un objectif de productivité, elle se transforme en « cliquet » : le chiffre du dernier sprint devient le seuil minimum de ce sprint, et la seule direction autorisée est la hausse. Les équipes ne sont pas stupides ; elles réagissent donc de la seule manière que cette incitation leur permet : elles gonflent les chiffres. Une story qui valait 3 le trimestre dernier vaut 5 ce trimestre, le chiffre grimpe, et rien n’est livré plus rapidement. Même Mike Cohn, la référence en matière de points, reconnaît ce mécanisme : le moindre indice laissant penser que les vélocités seront comparées entraîne une inflation progressive et constante des points.

La référence la plus solide permettant de maintenir la « vélocité » dans son cadre est DORA. Une décennie de recherche sur les facteurs permettant de prédire les performances de livraison logicielle a abouti à l’identification de quatre indicateurs — la fréquence de déploiement, le délai de mise en production, le taux d’échec des modifications et le temps de restauration — et la vélocité n’en fait délibérément pas partie, car les points d’histoire ne sont pas comparables d’une équipe à l’autre et mesurent l’effort fourni, et non la valeur livrée. La règle est donc simple et défendable : utilisez la vélocité pour établir des prévisions, mais ne l’utilisez jamais pour évaluer les performances. Si une personne extérieure à l’équipe vous demande « votre vélocité est-elle bonne ? », la solution se situe en amont de ce chiffre — la réponse honnête est « qu’essayez-vous réellement de mesurer ? » Notre chapitre sur la vélocité explique comment rester honnête à ce sujet, et la planification de la vélocité et de la capacité montre comment l’utiliser pour la seule chose à laquelle elle sert.

Blanchiment de devis

La deuxième distorsion est plus subtile, car elle prend l’apparence d’une responsabilisation. Le blanchiment d’estimation consiste à transformer discrètement une estimation — une supposition, formulée avec le minimum d’informations dont vous disposerez jamais — en un engagement, puis à obliger l’équipe à s’y tenir comme si elle avait signé un contrat. Cette estimation est présentée lors de la réunion de planification ; une échéance en ressort ; et lorsque celle-ci n’est pas respectée, c’est la faute du développeur qui « n’a pas respecté son estimation ».

Les professionnels décrivent l’ensemble du cycle de « blanchiment » sans qu’on ait besoin de leur demander : les estimations se transforment comme par magie en engagements, et si vous n’atteignez pas le chiffre fixé, c’est vous qui en portez la responsabilité. Les estimations sont rejetées — « ça ne peut pas être juste, refaites-le » — jusqu’à ce que l’équipe donne le chiffre qui permettra de respecter la date butoir, moment à partir duquel la planification n’est plus qu’une mascarade dont la réponse est prédéterminée. Il existe même une asymétrie révélatrice dans le langage : dites « cela prendra dix jours » et un responsable vous pressera de répondre « êtes-vous sûr que cela ne peut pas être neuf ? » ; dites « cela représente dix points » et, pour des raisons que personne ne peut vraiment justifier, ce même réflexe ne se déclenche pas. Les points de story ont été en partie conçus comme une armure contre cette pression précise — et le « blanchiment » des estimations est la pression qui vient à bout de cette armure en reconvertissant directement les points en une date.

La recommandation de référence est celle de Mike Cohn, et elle est antérieure à notre néologisme : distinguer l’estimation de l’engagement. Une estimation est une distribution de probabilité ; un engagement est une décision prise par l’équipe concernant ce qu’elle est certaine de pouvoir livrer. Distinguez-les clairement, à voix haute. Prévoyez une fourchette et précisez les hypothèses qui la sous-tendent. Et méfiez-vous du cas de cumul : lorsque la portée, le délai et le coût sont tous fixés d’avance et que le travail est simplement réparti en sprints de deux semaines, vous n’avez pas affaire à une méthode agile avec des estimations, mais à une méthode en cascade déguisée. Dave West, de Forrester, a baptisé ce phénomène « water-scrum-fall », et le « blanchiment d’estimations » en est le cœur battant. Notre chapitre « story points vs heures » explique en détail pourquoi cette conversion est un facteur d’échec, et non une solution.

Gestion des retours d’expérience

La troisième distorsion est la plus sombre, car elle transforme une cérémonie qui semble pourtant sûre en un véritable handicap. Le « feedback banking » consiste à accumuler des retours rétrospectifs honnêtes pour les réutiliser discrètement contre vous plus tard — lors d’une évaluation de performance, d’un ajustement de prime ou d’une conversation informelle sur votre « adéquation » avec l’entreprise. La rétrospective est présentée comme un espace sûr où l’on peut s’exprimer en toute franchise. Le « feedback banking » révèle que la franchise a une date d’échéance.

Ces anecdotes sont concrètes et font mal. Un ingénieur a expliqué que les commentaires négatifs refaisaient surface lors de son évaluation annuelle, comme pour prouver qu’il « se plaignait trop ». Un autre a décrit clairement le mécanisme : la direction met toutes les plaintes de côté pour les ressortir lors de l’examen annuel de votre prime. Cet effet dissuasif ne nécessite même pas de mauvaise intention : la personne chargée d’approuver les promotions n’a pas besoin de prononcer un seul mot dans la salle. Sa simple présence suffit à rendre vagues les commentaires sincères et à faire comprendre à tout le monde que la meilleure stratégie consiste à feindre la satisfaction. Notre chapitre « Pourquoi les rétrospectives échouent » traite de la conception de la séance afin que l’honnêteté ne se solde plus par un coût professionnel.

C’est là que la littérature sur la sécurité cesse de se contenter de vagues généralités. Les travaux d’Amy Edmondson sur la sécurité psychologique, ainsi que le Projet Aristote de Google — deux années d’étude portant sur 180 équipes — ont révélé que la sécurité psychologique était le plus important des cinq facteurs identifiés, celui sur lequel reposent les quatre autres. Une équipe qui a compris que ses retours d’expérience sont archivés ne bénéficie, par définition, d’aucune sécurité psychologique, et la rétrospective qui prétend le contraire n’est qu’une mise en scène comportant un risque juridique. Le Guide Scrum présente la rétrospective comme un moment où l’équipe s’auto-évalue — alors pourquoi le responsable est-il présent dans la salle pour prendre des notes ?

Ne comptez pas sur un héros

Il existe un risque de défaillance inhérent à cette solution. Ces distorsions sont généralement contenues parce qu’un responsable — un chef de projet, un chef d’équipe doté d’une forte personnalité — protège personnellement l’équipe : il refuse de transmettre les données de vélocité à ses supérieurs, recadre les estimations en les présentant comme des prévisions et veille à ce que le contenu de la rétrospective reste confiné à la salle de réunion. Cela fonctionne, mais uniquement tant que cette personne reste en poste. Un bouclier n’est pas un système. Si l’honnêteté de vos cérémonies repose sur la volonté d’un seul responsable d’absorber la pression, vous n’avez pas de cérémonies sûres — vous en avez une temporairement bienveillante, et le cirque reprend le jour où cette personne s’en va.

C’est là toute la différence entre le « pouvoir » en tant que mode de défaillance et le « pouvoir » en tant qu’élément immuable. Le chapitre consacré à la sécurité psychologique traite de la manière d’instaurer une franchise qui ne dépende pas des personnes présentes dans la pièce, tandis que la Directive Première aborde la norme qui permet de la pérenniser. Lorsque la cérémonie ritualisée ne produit finalement plus que des apparences soignées, vous vous retrouvez face au vide de suivi — le quatrième mode, celui où la mise en réserve des retours d’expérience cause les dégâts les plus insidieux.

Foire aux questions

Comment puis-je empêcher la direction d’utiliser la vélocité contre mon équipe ?

Gardez ce chiffre pour vous. La vélocité est un indicateur utilisé pour les prévisions, et non un indicateur de performance — l’étude DORA l’exclut délibérément, car les scores ne sont pas comparables d’une équipe à l’autre. Si un responsable extérieur à votre équipe vous demande si votre vélocité est bonne, la réponse honnête consiste à lui poser une question en retour : qu’essayez-vous réellement de mesurer ? Rendez compte des résultats et des livraisons, et non du total des points.

Les commentaires rétrospectifs peuvent-ils être utilisés à mon encontre lors d’une évaluation de performance ?

Cela arrive, et cette crainte est légitime : les participants rapportent que des commentaires sincères formulés lors d’une rétrospective refont surface des mois plus tard sous la forme d’une remarque selon laquelle ils se plaignent trop. C’est ce qu’on appelle la « mise en réserve des retours d’expérience », et c’est la raison pour laquelle l’anonymat, l’exclusion des responsables et la « règle de Las Vegas » existent. Une rétrospective où la franchise représente un risque pour la carrière n’est pas psychologiquement sûre, et aucune technique d’animation ne peut y remédier. Modifiez la dynamique de pouvoir, pas la formulation.

Comment éviter que les estimations ne deviennent des échéances ?

Faites la distinction entre l’estimation et l’engagement, à voix haute et de manière délibérée. Une estimation est une probabilité ; un engagement est une promesse ; confondre les deux, puis tenir l’équipe responsable de ce qu’elle n’a pas promis, voilà ce qui brise la confiance. Prévoyez une fourchette, précisez les hypothèses, et ne laissez jamais une supposition formulée lors d’une réunion de planification être reprise comme une date à laquelle l’équipe s’est engagée.

Mon responsable doit-il assister à la rétrospective ou animer la réunion debout ?

En général, non. Le Guide Scrum définit la rétrospective comme un moment où l’équipe s’auto-évalue, et la réunion quotidienne comme un moment de coordination entre les développeurs eux-mêmes. La simple présence d’une figure d’autorité dans la salle suffit à entraver la franchise — la personne chargée d’approuver les promotions est, par défaut, une source d’intimidation. Transmettez les actions à mener à vos supérieurs, mais ne leur cédez pas votre place.

Lectures complémentaires

• Le vide de la suite des événements — là où se rejoignent les réactions accumulées et l’impuissance.
• Spectacle : la cérémonie que vous mettez en scène pour le public — ce théâtre que le pouvoir rend coercitif.
• La vélocité : à quoi sert-elle et comment la calculer — utilisez cette valeur à des fins de prévision, jamais pour attribuer une note.
• Points de scénario vs heures — pourquoi cette conversion favorise le « blanchiment » des estimations.
• Planification du sprint (la cérémonie) — où l’estimation est censée rester une prévision dont l’équipe est responsable, et non un engagement.
• Comment créer un espace de sécurité psychologique — une franchise qui ne dépend pas des personnes présentes dans la pièce.
• Glossaire du théâtre agile — Définitions des termes « blanchiment d’estimations », « mise en réserve des retours d’expérience » et « effet de cliquet de la vélocité ».