Pourquoi les rétrospectives échouent (et comment faire en sorte que la vôtre soit efficace)

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 instauré d’habitude d’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 qui échoue 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’attaque aux deux échecs que cette 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 exercice brise-glace ne permet d’y remédier. Si l’animation est véritablement votre problème, la solution réside dans la mise en place de rétrospectives efficaces, et non ici.

Le retour au passé qui ne change rien, car l’équipe en est incapable

Voici la critique la plus pertinente à 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 », il ne veut généralement pas dire que l’équipe a oublié de rédiger des actions à mener. Il veut dire 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 hiérarchiques 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 l’exutoire des griefs. »

C’est là que réside le piège. La rétrospective se transforme en soupape de pression : l’équipe peut s’exprimer, précisément pour que rien ne change. Les participants se défoulent, la direction estime que la case est cochée, et la cause profonde reste intacte. Rejeter la responsabilité sur l’animateur revient, comme l’a écrit un développeur dans un essai, à « blâmer la boîte à suggestions parce que la direction ne lit pas les suggestions ». Aucune métaphore du type « le 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’agir.

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. Classez chaque problème en fonction de la personne 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 d’un élément alimentant une remontée hiérarchique.

Tout ne dégénère pas, et tout n’est pas sans espoir. Les « 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 sur l’anneau d’influence pendant que les obstacles majeurs se résolvents progressivement. Mais une rétrospective honnête refuse de prétendre que l’anneau extérieur relève de la responsabilité 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 discrets 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, plus cynique, 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 « mise en réserve des retours » : des commentaires sincères qui sont accumulés pour être ensuite utilisés contre vous, et le moyen le plus rapide de tuer une rétrospective de sprint. Le Guide Scrum décrit la rétrospective de sprint comme l’équipe Scrum qui s’inspecte elle-même. Prenez cela au pied de la lettre : l’équipe qui 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 concevez une solution pour y remédier :

• Évitez que les responsables de la promotion soient présents dans la salle. Partagez les actions convenues avec la hiérarchie, et non les sièges. 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 diffusé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 ce 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. » Le ton résigné de cette remarque (« 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, comme dans le 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 mesures issues des rétrospectives réellement mises en œuvre parmi des centaines de milliers d’actions concrètes : 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 bien cerné, c’est la nature de 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 se terminent avec 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. Adopter un nouveau format est la première chose que les équipes essaient de faire, et c’est celle qui a le moins de chances d’aider : remplacer « Mad/Sad/Glad » par un voilier n’est qu’une mesure cosmétique si le suivi fait défaut.

Deuxièmement, cessez de considérer la tâche à réaliser comme l’objectif principal. Il s’agit là du changement de perspective proposé dans la 2e édition de Agile Retrospectives, vers lequel s’oriente l’ensemble de la discipline. Le changement fondamental proposé par Derby, Larsen et David Horowitz réside dans le fait que c’est l’apprentissage, et non l’achèvement d’une tâche, qui constitue le critère de réussite. Remplacez la « tâche à réaliser » 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 la plainte selon laquelle « rien ne change », car l’objectif cesse d’être une corvée à 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 pratiques établies 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 organisé de manière à l’intégrer.

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

Un échec plus discret : cette réunion rétrospective où deux personnes sur huit prennent la parole pendant cinq minutes et où le reste n’est qu’un silence pesant, et où tous les formats et tableaux préremplis que vous essayez ne changent rien. Il est facile d’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 travail à distance aggrave la situation : caméras éteintes, micros coupés, ambiance morose.

Ne comblez pas le silence par d’autres incitations à intervenir. Changez l’ordre des intervenants. Organisez une séance de réflexion silencieuse et individuelle avant toute discussion afin que chacun écrive avant de s’exprimer, ce qui permet de protéger les introvertis et ceux qui ne souhaitent pas être les premiers à s’exprimer à voix haute. Recueillez les contributions de manière asynchrone à l’avance. Permettez aux participants d’apposer un post-it sans avoir à le défendre devant l’assemblée. L’objectif n’est pas d’avoir une réunion animée, mais d’obtenir des données sincères, 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 » balayent trop vite : 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 standups, à la planification, aux revues et aux itérations de raffinement. À un rythme soutenu, le calcul devient impitoyable : les équipes travaillant selon des sprints d’une semaine décrivent la planification et la rétrospective hebdomadaires comme « un fardeau », et elles ont raison. Cinquante rétrospectives par an au sein d’une équipe expérimentée ne constituent pas une vertu. La même plainte transparaît à l’échelle de l’organisation dans les études sur la charge de réunions, où la part des réunions que les personnes déclarent avoir pu éviter est mesurée plutôt qu’estimée.

La solution n’est pas de sauter 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 : consultez les anti-modèles des Standups et l’absence de suivi dans notre guide pratique « Agile Theatre ».)

Résolvez le problème d’alimentation, préservez l’honnêteté, menez à bien une action concrète et adaptez le rythme : la rétrospective cessera alors d’être une simple soupape de décompression. Elle deviendra 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 ?

En général, c’est 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 plutôt que de l’avoir changée. 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 selon ce que l’équipe contrôle, ce sur quoi elle peut exercer une influence et ce qu’elle ne peut que subir (l’activité « Cercles et Soupe » 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 franc dans une rétrospective ?

À condition que l’honnêteté n’ait pas de conséquences sur la carrière. Les développeurs signalent régulièrement que les retours d’expérience formulés lors de réunions rétrospectives refont surface lors d’un entretien d’évaluation, comme preuve qu’ils « se plaignent trop ». Si la personne chargée d’approuver 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 réunion les responsables hiérarchiques chargés des promotions, convenez que ce qui y est discuté reste entre les murs de la salle et que seules les mesures convenues en sortent, et proposez l’anonymat au cas par cas pour chaque idée plutôt que selon un principe « 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.