Le pouvoir : quand l'autorité s'empare de la cérémonie
Le deuxième mode d'échec du théâtre agile : les distorsions d'autorité qui sapent l'honnêteté. L'effet de cliquet de la vélocité, le « blanchiment » des estimations et la « mise en réserve » des retours d'expérience sont les trois façons dont un déséquilibre des pouvoirs retourne une cérémonie contre l'équipe.
Toute cérémonie agile repose sur 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 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 « cliquet de vélocité» que ce préjudice se produit. La vélocité est censée être un outil d’auto-calibrage propre à chaque équipe : la moyenne mobile 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 de réunion pour devenir un objectif de productivité, elle se transforme en mécanisme de « cliquet » : le chiffre du dernier sprint devient le seuil minimal 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.
Le fondement le plus solide sur lequel s’appuyer pour maintenir la « velocity » dans son cadre est le DORA. Une décennie de recherche sur les facteurs prédictifs de la performance en matière de livraison de logiciels a abouti à l’identification de quatre indicateurs clés (fréquence de déploiement, délai d’exécution, taux d’échec des modifications et temps de restauration) ; la « velocity » n’en fait pas partie. 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 consacré à la vélocité explique comment rester honnête, tandis que la section sur 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 moins 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 résulte ; 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 prévu, 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 devient 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 questions : « Ê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 convertissant directement les points en une date.
La solution canonique 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és ; un engagement est une décision prise par l’équipe concernant ce qu’elle est sûre 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 consacré aux story points par rapport aux heures explique 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 grave, car elle transforme une cérémonie qui semble pourtant inoffensive en un véritable handicap. Le « feedback banking » consiste à accumuler des commentaires rétrospectifs sincères 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. L’entretien rétrospectif est présenté comme un espace sûr où l’on peut s’exprimer en toute franchise. Le « feedback banking » vous fait découvrir que cette franchise a une date d’échéance.
Ces anecdotes sont concrètes et font mal. Un ingénieur a décrit la manière dont ses commentaires négatifs refaisaient surface lors de son évaluation annuelle comme la preuve qu’il « se plaint trop ». Un autre a expliqué 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 intitulé « Pourquoi les rétrospectives échouent » explique comment concevoir la séance de manière à ce que l’honnêteté ne se fasse plus au détriment de la 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 — qui a consisté à étudier 180 équipes pendant deux ans —, 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 mode 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 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 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 manager d’absorber la pression, vos cérémonies ne sont pas sûres. Vous disposez d’une cérémonie 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 d’échec et le « pouvoir » en tant que réalité 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 la mise en œuvre : le quatrième mode, celui où la mise en réserve des retours d’expérience 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. Elle ne fait pas partie des indicateurs de livraison de DORA, et les points ne sont de toute façon 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 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 dates butoirs ?
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 obliger l’équipe à s’y tenir, 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 Standup ?
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 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 du suivi : 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.
- La vélocité : à quoi elle sert et comment la calculer : utilisez cette valeur pour établir des prévisions, jamais pour attribuer une note.
- Points de scénario contre heures : pourquoi cette conversion favorise le « blanchiment » des estimations.
- Planification du sprint (la réunion) : lors de laquelle 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épende pas des personnes présentes dans la pièce.
- Glossaire du théâtre agile : « estimate laundering », « feedback banking » et « velocity ratchet » : définitions.