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 entre en jeu 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 sûre 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. Il a été très clair : « Je pense que comparer les équipes sur la base de la qualité de leurs estimations ou de 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 préjudice se produit. La vélocité est censée être un outil d’auto-calibrage propre à chaque équipe : il s’agit de la moyenne glissante des points achevés, utilisée pour estimer le temps nécessaire à la réalisation du backlog. Dès qu’elle sort du cadre de la salle de réunion pour devenir un objectif de productivité, elle se transforme en « cliquet » : le chiffre du dernier sprint devient le seuil minimal de ce sprint, et la seule direction dans laquelle il est autorisé à évoluer est vers le haut. 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 entendre 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 « velocity » 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 (fréquence de déploiement, délai d’exécution, taux d’échec des modifications et temps de restauration) ; la vélocité n’en fait délibérément pas partie, car les points de story 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 trouve en amont de ce chiffre. La réponse honnête est : « Que cherchez-vous réellement à mesurer ? » Notre chapitre « Vélocité » explique comment rester honnête à ce sujet, et « Vélocité et planification 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 moins d’informations possible) 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 date butoir en ressort ; et lorsque cette date butoir n’est pas respectée, c’est la faute du développeur qui a « manqué 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 prévu, c’est vous qui en portez la responsabilité. Les estimations sont rejetées (« cela ne peut pas être juste, refaites-le ») jusqu’à ce que l’équipe donne le chiffre qui permettra de respecter la date butoir, après quoi 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 la question « ê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 d’histoire ont été en partie conçus comme une protection contre cette pression précisément, et le « blanchiment » des estimations est la pression qui vient à bout de cette protection 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 mode 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 si sûre en un véritable handicap. Le « feedback banking » consiste à accumuler des commentaires rétrospectifs sincères pour les 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 » au poste. La rétrospective est présentée comme un espace sûr où l’on peut s’exprimer en toute franchise. Le « feedback banking » est la prise de conscience 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 formulés lors d’une rétrospective refaisaient surface lors de son évaluation annuelle, ce qui était interprété comme une preuve qu’il « se plaignait trop ». Un autre a décrit le mécanisme sans détours : 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 volonté. 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 pèse plus sur votre carrière.

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 — une étude menée pendant deux ans auprès de 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 « mis de côté » 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 présent dans la salle prend-il des notes ?

Ne comptez pas sur un héros

Il existe un risque de défaillance au cœur même de cette solution. Ces distorsions sont généralement contenues parce qu’un responsable (un chef d’équipe, un chef de projet ayant du cran) protège personnellement l’équipe : il refuse de transmettre les données de vélocité à ses supérieurs, présente les estimations 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, vos cérémonies ne sont pas sûres. Vous disposez d’une cérémonie temporairement bienveillante, et le théâtre reprend le jour où cette personne s’en va.

C’est là toute la différence entre le « pouvoir » en tant que mode d’échec 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 êtes alors confronté au vide de suivi : le quatrième mode, celui où l’accumulation des retours d’information cause ses 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 à l’é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’un entretien d’évaluation ?

Cela arrive, et cette crainte est tout à fait justifiée. 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 d’être de l’anonymat, de l’exclusion des responsables et de la « règle de Las Vegas ». 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 délais prévisionnels ne deviennent des délais fermes ?

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 exiger de l’équipe qu’elle s’y tienne, 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 à nuire à la franchise. La personne chargée de valider les promotions est, par défaut, une présence qui a un effet dissuasif. Transmettez les actions à mener vers le haut de la hiérarchie, et non pas les places assises.

Lectures complémentaires

• Le vide de la suite logique: là où se rencontrent les réactions refoulées et l’impuissance.
• La représentation : la cérémonie que vous mettez en scène pour le public : le théâtre que le pouvoir rend coercitif.
• Vitesse : à quoi cela sert-il et comment la calculer : utilisez cette valeur à des fins de prévision, jamais pour noter.
• Points de scénario vs heures: pourquoi cette conversion favorise le « blanchiment » des estimations.
• Planification du sprint (la cérémonie) : une estimation doit 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 des estimations », « mise en réserve des retours d’expérience » et « effet de cliquet de la vélocité ».