Pourquoi les rétrospectives échouent (et comment faire en sorte que la vôtre porte ses fruits)

Votre équipe organise une rétrospective à chaque sprint. Les participants se présentent, collent leurs post-it, approuvent d’un signe de tête deux ou trois actions à mener, puis s’en vont. Or, rien ne change quant à la manière dont le travail est réellement effectué. Si vous répétez ce schéma quarante fois par an, vous n’aurez pas ancré l’habitude de l’amélioration. Vous avez pris l’habitude de parler d’amélioration. C’est là l’échec que presque personne ne nomme : ce n’est pas un mauvais format, mais un rituel qui produit immanquablement des mots, et rien que des mots.

Les conseils habituels considèrent une rétrospective ratée comme un problème d’animation : changer de format, définir des actions plus « SMART », ajouter un exercice de brise-glace. Parfois, c’est bien là le problème. Mais ce n’est généralement pas le cas. Nous avons répertorié ailleurs les dix anti-modèles courants en matière de rétrospective, et il vaut la peine de les corriger. Ce chapitre s’attache aux deux échecs que la liste contourne poliment, car ce sont eux qui poussent les ingénieurs expérimentés à qualifier les rétrospectives de perte de temps : un problème de pouvoir et un problème de suivi. Aucun brise-glace ne permet d’y remédier. Si la facilitation est véritablement votre problème, la solution réside dans la conduite de rétrospectives efficaces, et non ici.

Le retour aux sources qui ne change rien, car l’équipe en est incapable

Voici la critique la plus profonde à l’égard des rétrospectives, et celle que notre propre article sur les anti-modèles interprète à l’envers. Lorsqu’un développeur dit « il ne se passe jamais rien », cela ne signifie généralement pas que l’équipe a oublié de rédiger des actions à mener. Cela signifie que les problèmes qui mériteraient d’être soulevés (effectifs, dépendances entre équipes, un pipeline de déploiement qui prend quarante minutes, une échéance fixée trois niveaux plus haut) sont réellement hors de la sphère d’influence de l’équipe. Comme l’a clairement exprimé un ingénieur sur Hacker News, une rétrospective peut devenir « une cérémonie sans véritable objectif, car généralement, les problèmes plus profonds soulevés par les participants ne relèvent pas du pouvoir de cette équipe ». Un autre, dans le même fil de discussion : « Cela donne à la direction une excuse pour ne pas régler les problèmes ou ne pas écouter, car la rétrospective est censée être le moyen d’exprimer ses griefs. »

C’est là que réside le piège. La rétrospective se transforme en soupape de décompression : l’équipe peut s’exprimer, précisément pour que rien ne change. Les participants se défoulent, la direction a l’impression d’avoir coché la case, et la cause profonde reste intacte. Rejeter la responsabilité sur l’animateur revient, comme l’a écrit un développeur dans un essai, « à reprocher à la boîte à suggestions que la direction ne lise pas les suggestions ». Aucune métaphore du voilier contre l’étoile de mer ne donnera à une équipe le pouvoir de résoudre un problème pour lequel elle n’a jamais reçu l’autorisation d’intervenir.

Notre ancien conseil (« cessez de vous concentrer sur ce qui ne relève pas de votre sphère d’influence ») se range discrètement du côté du système dans ce cas précis. Il incite l’équipe à passer sous silence le véritable obstacle afin de préserver une ambiance sereine dans la discussion. Adoptez plutôt une approche plus ferme. Triez chaque problème en fonction de celui qui en est réellement responsable : ce que l’équipe contrôle, ce sur quoi elle peut exercer une influence, et ce qu’elle ne peut que subir. Il s’agit de l’activité « Circles and Soup » tirée de l’ouvrage Agile Retrospectives (2e éd.) d’Esther Derby et Diana Larsen. Le but du cercle extérieur n’est pas de « les ignorer ». Il s’agit de la base d’une remontée d’information.

Tout ne dégénère pas, et tout n’est pas sans espoir. 15 % Solutions, cette technique issue des « Liberating Structures » qui consiste à identifier le plus petit changement que l’équipe peut apporter sans avoir besoin de l’autorisation de qui que ce soit, permet de maintenir l’élan au sein du « cercle d’influence » pendant que les principaux obstacles sont progressivement surmontés. Mais une rétrospective honnête refuse de prétendre que l’anneau extérieur est la faute de l’équipe.

Les commentaires qui sont conservés et utilisés à votre détriment

Voici maintenant ce dont aucun fournisseur ne parle. Si les gens restent silencieux lors des rétrospectives, c’est pour une raison bien plus concrète que la simple timidité : faire preuve d’honnêteté peut nuire à leur carrière. Cette crainte est bien réelle et transparaît dans des témoignages concrets. Un développeur a expliqué que les commentaires issus de la rétrospective refaisaient surface « lors de mon évaluation annuelle, où l’on m’a fait remarquer que je “me plaignais trop” ». Un autre, avec plus de cynisme, a déclaré : « Ils mettent toutes ces plaintes de côté pour les ressortir lors de l’examen de votre prime annuelle. »

C’est ce qu’on appelle la « banque de retours »: des commentaires sincères mis de côté pour être utilisés contre vous plus tard, et le moyen le plus rapide de tuer une rétrospective. Le Guide Scrum décrit la rétrospective de sprint comme le fait pour l’équipe Scrum de s’« inspecter elle-même ». Prenez cela au pied de la lettre : l’équipe s’inspecte elle-même. Alors pourquoi la personne qui signe votre évaluation de performance est-elle assise dans la salle à prendre des notes ? Son silence suffit. Aucune des personnes qui décident de votre promotion n’a besoin de prononcer un mot pour vous amener à modérer ce que vous auriez dit autrement. Le projet Aristote de Google a révélé que la sécurité psychologique était le principal facteur prédictif de l’efficacité d’une équipe ; la simple présence d’un responsable suffit souvent à la faire disparaître. (Nous abordons les mécanismes de ce phénomène dans le chapitre consacré à la création d’un espace psychologiquement sûr.)

Alors, identifiez cette peur et élaborez une stratégie pour la surmonter :

• Évitez que les responsables de la promotion soient présents dans la salle. Communiquez les mesures convenues à la hiérarchie, pas les places assises. Une équipe paralysée par la présence d’un responsable ne peut pas mener une rétrospective transparente, et aucune astuce d’animation ne permettra d’y remédier.
• Convenez que ce qui est dit reste entre les murs de la salle. Seules les actions que l’équipe choisit de rendre publiques sont divulguées à l’extérieur. C’est ce qui permet aux gens de s’exprimer en premier lieu.
• Faites de l’anonymat une option au cas par cas, et non un mode permanent. L’anonymat équilibre les rapports de force et permet de mettre en lumière les sujets sensibles ; utilisé comme une béquille permanente, il sape la confiance que vous essayez d’instaurer. Laissez les gens y recourir uniquement pour les sujets qui le nécessitent.
• Faites attention lorsque vous introduisez des indicateurs. Les données objectives (vélocité, durée du cycle) ont leur place dans une rétrospective, mais dès lors que la vélocité devient un objectif par rapport auquel l’équipe est évaluée, vous créez un effet de cliquet de vélocité, et les membres de l’équipe s’attachent à optimiser ce chiffre plutôt qu’à dire la vérité. C’est le mode de défaillance qui transforme la franchise en performance.

Le vide dans le suivi du mouvement, et la nouvelle approche qui permet d’y remédier

Supposons que les problèmes d’alimentation électrique et de sécurité soient résolus. Les rétrospectives échouent néanmoins face à la critique la plus récurrente de tout le débat : « Les rétrospectives permettent d’exprimer des préoccupations, mais rien ne se passe jamais vraiment à leur sujet. » Ou, pour le dire plus crûment : « Je n’ai jamais rien vu d’autre que des paroles. » Ce ton résigné (« ce point ne sera pas traité ») reflète bien ce que l’on ressent de l’intérieur lors de ces rétrospectives qui se répètent à l’infini, à la manière du film « Un jour sans fin ». Ce n’est pas le fruit de l’imagination : le chiffre que tout le monde répète, souvent cité, selon lequel seulement un tiers environ des équipes mènent systématiquement à bien les actions issues de leurs rétrospectives, s’avère en réalité exagérément pessimiste. Nous avons mesuré le nombre de points d’action issus des rétrospectives qui sont réellement menés à bien sur des centaines de milliers d’actions réelles : le taux de réalisation est plus proche de trois sur quatre, et ce sont la cadence et la prise en charge qui déterminent de quel côté de cet écart se situe une équipe. Ce que la croyance populaire a de juste, c’est la forme que prend l’échec. Une action dont personne n’assume la responsabilité, sans date butoir, au sein d’une équipe dépourvue de rythme, est celle qui finit par être inscrite sur un tableau blanc puis effacée.

Deux corrections, dont la deuxième est la plus importante.

Tout d’abord, cessez d’essayer de tout régler. Plus la liste est longue, moins chaque point qui y figure est efficace : selon nos données, les rétrospectives qui aboutissent à dix actions ou plus n’en mènent à bien qu’environ 56 %, contre environ 79 % pour celles qui n’en retiennent qu’une à trois. Limitez-vous à une amélioration à laquelle l’équipe s’engage sincèrement, intégrez-la dans le travail du prochain sprint plutôt que de la laisser sur le tableau, et commencez chaque rétrospective en faisant le point sur cette « une chose » de la dernière fois avant d’aborder quoi que ce soit de nouveau. Si elle n’a pas été réalisée, c’est là la discussion la plus utile de la réunion. La recherche d’un nouveau format est la première chose que les équipes tentent, et c’est celle qui a le moins de chances d’aider : remplacer « Fâché/Triste/Heureux » par un voilier n’est qu’une mesure cosmétique si le suivi fait défaut.

Deuxièmement, cessez de considérer la mesure à mettre en œuvre comme l’essentiel. Il s’agit là du recadrage proposé dans Agile Retrospectives, 2e édition vers lequel s’oriente l’ensemble de la discipline. Le changement essentiel proposé par Derby, Larsen et David Horowitz réside dans le fait que c’est l’apprentissage, et non l’accomplissement d’une tâche, qui constitue le critère de réussite. Remplacez l’action à mener par une expérience : une hypothèse que vous testez (« si nous travaillons en binôme sur cette story risquée, nous réduirons les retouches »), une date pour en faire le bilan, et un examen honnête de ce qui s’est réellement passé. Une rétrospective qui n’a donné lieu à aucune action à cocher mais qui a véritablement appris quelque chose à l’équipe n’est pas un échec. Ce simple changement dissipe le reproche selon lequel « rien ne change », car l’objectif cesse d’être une tâche à accomplir pour devenir un changement que vous mettez réellement en œuvre. Johanna Rothman pratiquait déjà cette substitution bien avant qu’elle ne fasse partie des principes incontournables de la rétrospective, dans Create Your Successful Agile Project : un seul point, mené sous forme d’expérience, avec le prochain bloc de travail de l’équipe conçu pour l’intégrer.

Le silence n’est pas de l’apathie : c’est un signal

Un échec plus discret : cette rétrospective où deux personnes sur huit parlent pendant cinq minutes et où le reste n’est que silence, et où tous les formats et tableaux préremplis que vous essayez ne changent rien. On pourrait facilement y voir une équipe désengagée. Ce n’est généralement pas le cas. Le silence lors d’une rétrospective est un signal, et non le problème en soi : il révèle un manque de confiance, un objectif mal défini ou un problème de leadership que les participants n’osent pas évoquer ouvertement. Le télétravail aggrave la situation : caméras éteintes, micros coupés, ambiance morose.

Ne comblez pas le silence par d’autres incitations. Changez l’ordre des intervenants. Organisez une séance de brainstorming silencieuse et individuelle avant toute discussion afin que chacun écrive avant de prendre la parole ; cela permet de protéger les personnes introverties et celles qui ne souhaitent pas être celles qui s’expriment à voix haute. Recueillez les contributions de manière asynchrone à l’avance. Permettez aux participants de contribuer en posant un post-it sans avoir à défendre leur idée devant l’assemblée. L’objectif n’est pas d’avoir une réunion animée, mais d’obtenir des données fiables, et celles-ci s’expriment souvent en toute discrétion.

Le coût des réunions est une dépense réelle, et non un prétexte

Enfin, la critique que les partisans du « ne jamais sauter la rétrospective » écartent trop hâtivement : les rétrospectives ont un coût. « C’est une réunion de plus dans mon agenda qui risque d’interrompre la concentration intense dans laquelle je me trouvais », a écrit un développeur. Et cela s’ajoute aux réunions debout, à la planification, à la revue et au raffinement. Avec des cadences courtes, le calcul devient impitoyable : les équipes travaillant par sprints d’une semaine qualifient la planification et la rétrospective hebdomadaires de « fardeau », et elles ont raison. Cinquante rétrospectives par an pour une équipe expérimentée ne constituent pas une vertu.

La solution n’est pas de faire l’impasse sur les rétrospectives, mais de les adapter à la situation. Une équipe nouvellement constituée et soumise à une forte pression a tout intérêt à organiser une rétrospective à chaque sprint. Une équipe stable qui ne cesse d’avoir les mêmes discussions superficielles vous indique que la fréquence n’est pas adaptée, et non que la réflexion est inutile. Passez à une fréquence bihebdomadaire, ou organisez des rétrospectives en fonction d’événements (après une mise en production, après une panne, après un sprint difficile) lorsqu’il y a véritablement matière à examen. La fréquence est un réglage, pas un commandement. (La même logique de surcharge s’applique à toutes les cérémonies : voir les anti-modèles de stand-up et le vide de suivi dans notre guide pratique « Agile Theatre ».)

Résolvez le problème d’énergie, préservez l’honnêteté, menez à bien une action concrète et adaptez le rythme : la rétrospective cesse alors d’être un simple exutoire. Elle devient cette heure, au cours de chaque sprint, où l’équipe modifie réellement sa façon de travailler, ce qui a toujours été l’objectif. Un outil de rétrospective en ligne apporte une aide concrète : il transpose chaque changement convenu en une action suivie, de sorte que le suivi se poursuive au-delà de la semaine suivant la réunion.

Foire aux questions

Pourquoi rien ne change-t-il jamais après nos rétrospectives ?

Généralement parce que les problèmes les plus importants ne relèvent pas de la compétence de l’équipe, et que la rétrospective ne dispose d’aucun moyen de les transmettre à qui que ce soit. Le tableau se remplit de problèmes que l’équipe ne peut pas résoudre seule (effectifs, dépendances, pipeline de déploiement défaillant), et tout le monde repart après avoir simplement décrit la situation au lieu de la faire évoluer. La solution consiste à trier chaque point en fonction de la personne qui en est réellement responsable, à ne retenir qu’une seule amélioration contrôlée par l’équipe sur laquelle travailler, et à remonter les points hors du champ d’action en les identifiant nommément, en précisant le responsable et une date, au lieu de les laisser discrètement de côté.

Que faites-vous lorsque le véritable problème échappe au contrôle de l’équipe ?

Vous remontez le problème, de manière officielle. Classez les problèmes en trois catégories : ce que l’équipe contrôle, ce sur quoi elle peut exercer une influence et ce qu’elle ne peut que subir (l’activité « Circles and Soup » tirée de Agile Retrospectives). Le conseil classique consiste à ignorer le cercle extérieur et à rester dans votre cercle d’influence. C’est ainsi qu’une rétrospective se transforme en spectacle. Au lieu de cela, transformez les éléments du cercle extérieur en une demande visible (un « Retrospective Radiator ») qui identifie l’obstacle, l’impact et la personne qui doit agir, puis présentez-la aux personnes en mesure de faire avancer les choses. Une rétrospective qui ne fait remonter que les problèmes que l’équipe est déjà en mesure de résoudre est confortable, mais malhonnête.

Peut-on se permettre d’être honnête dans une rétrospective ?

À condition que l’honnêteté n’ait pas de conséquence sur la carrière. Les développeurs signalent régulièrement que les retours d’expérience issus des séances rétrospectives refont surface lors d’un entretien d’évaluation, comme preuve qu’ils « se plaignent trop ». Si la personne chargée de valider les promotions est présente dans la salle, ou si ce qui est dit est conservé pour plus tard, les participants se taisent et affirment que tout va bien. Protégez délibérément la franchise. Écartez de la séance les responsables hiérarchiques chargés des promotions, convenez que ce qui est discuté reste dans la salle et que seules les actions convenues en sortent, et proposez l’anonymat au cas par cas pour chaque idée plutôt que selon un mode « tout ou rien ».

Les rétrospectives sont-elles une perte de temps ?

C’est le cas lorsque le seul critère de réussite est une tâche menée à bien, car la plupart des sprints ne vous offrent pas de situation bien ficelée. Recadrez l’objectif. Une rétrospective est réussie lorsque l’équipe tire un enseignement qu’elle mettra en pratique lors du prochain sprint, même en l’absence d’une tâche à cocher, et lorsqu’elle mène une seule expérience sincère plutôt que dix tâches abandonnées. Les rétrospectives accomplissent également un travail plus discret (mettre en lumière les tensions dès le début, maintenir la cohésion de l’équipe) qui n’apparaît jamais sous la forme d’une tâche à accomplir, mais qui est bien réel. Considérées comme un rituel d’apprentissage plutôt que comme une usine à tâches, elles trouvent ainsi toute leur place.