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. Mais rien ne change quant à la manière dont le travail est réellement effectué. Répétez cela quarante fois par an et vous n’aurez pas instauré une habitude d’amélioration — vous aurez instauré une 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 infructueuse 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 brise-glace ne permet d’y remédier.

Le retour au passé 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 », 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 — les effectifs, les 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 l’exutoire où l’on peut 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, les responsables ont 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 son essai, à « blâmer la boîte à suggestions parce que la direction ne lit 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’agir.

Notre ancien conseil — « cessez de vous concentrer sur ce qui ne relève pas de votre sphère d’influence » — va discrètement dans le sens du système en l’occurrence. Il incite l’équipe à passer sous silence le véritable obstacle afin de préserver une ambiance de travail sereine. 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 d’Esther Derby et Diana Larsen Agile Retrospectives (2e éd.) — et l’objectif 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 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 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, sur un ton 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 le « feedback banking » — des commentaires sincères mis de côté pour être utilisés contre vous plus tard — et c’est le moyen le plus rapide de tuer une rétrospective de sprint. Le Guide Scrum décrit la rétrospective de sprint comme le moment où l’équipe Scrum s’auto-évalue. Prenez cela au pied de la lettre : l’équipe s’auto-évalue. Alors pourquoi la personne qui signe votre évaluation de performance est-elle assise dans la salle à prendre des notes ? Son silence suffit — personne parmi ceux qui contrôlent votre promotion n’a besoin de dire un mot pour vous inciter à 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 actions convenues à la hiérarchie, et non les postes occupés. 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 réé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 contributions qui en ont besoin.
• 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 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 — et le recadrage 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 toujours 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 vu autre chose que des paroles. » Ce ton résigné — « ce point sensible ne sera pas traité » —, c’est 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 : selon un chiffre souvent cité par la Scrum Alliance, seul un tiers environ des équipes mène systématiquement à bien les actions issues de leurs rétrospectives. Les autres sont notées sur un tableau blanc, puis effacées. La rumeur exagère toutefois quelque peu la gravité de la situation : nous avons mesuré le nombre de mesures issues des rétrospectives effectivement mises en œuvre sur des centaines de milliers d’actions réelles, et le taux de réalisation est plus proche de trois sur quatre, la cadence et l’appropriation des mesures déterminant de quel côté de l’écart se situe une équipe.

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

Tout d’abord, cessez d’essayer de tout régler. Une rétrospective qui génère dix actions à mener n’en mène aucune à bien. Limitez-vous à une seule amélioration à laquelle l’équipe s’engage sincèrement, et commencez chaque rétrospective par faire le point sur cette action de la fois précédente avant d’en définir une nouvelle. Si elle n’a pas été menée à bien, c’est là la discussion la plus utile de la réunion. Adopter un nouveau format est la première chose que les équipes tentent 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 — et c’est là le changement de perspective proposé par Agile Retrospectives, 2e édition vers lequel s’oriente l’ensemble de la discipline — cessez de considérer les mesures à mettre en œuvre comme l’objectif principal. 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 la « mesure à mettre en œuvre » 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 tâche à accomplir pour devenir un changement que vous mettez réellement en œuvre.

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

Un échec plus discret : cette rétrospective où deux personnes sur huit prennent la parole 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. 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, pas 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 à prendre la parole. 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 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 émergent 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 — venant s’ajouter aux réunions debout, à la planification, à la revue et au raffinement. Avec des cadences serrées, le calcul devient impitoyable : les équipes travaillant par 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 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 la même conversation superficielle 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é, allez jusqu’au bout d’une chose concrète et adaptez le rythme : la rétrospective cessera alors d’être un simple exutoire. Elle deviendra ce sprint, au cours duquel l’équipe modifie réellement sa façon de travailler — ce qui a toujours été le but recherché.

Foire aux questions

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

En général, 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 chacun repart après avoir simplement décrit la situation plutôt que de l’avoir modifié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 indiquant clairement le nom du responsable et une date, plutôt que de les laisser de côté sans rien dire.

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 (les « cercles » et l’activité « Soup » tirés 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’entretiens 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 séance 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 résultat tout fait. 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 — faire émerger les tensions à un stade précoce et 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.