Nul : lorsque la cérémonie ne change rien

Le mode de défaillance le plus grave n’est pas une cérémonie mal organisée. C’est une cérémonie bien organisée qui ne change rien.

Une réunion « stand-up » peut être enregistrée, une session de planification peut être surchargée, et l’équipe continuera malgré tout à ressentir des frictions et une certaine résistance. Le manque de suivi est d’autant plus grave qu’il donne l’impression que tout va bien. La rétrospective a lieu, les participants sont francs, des post-it sont rédigés, tout le monde acquiesce… puis le sprint commence et rien ne change. Répétez cela plusieurs fois et vous n’obtiendrez pas de colère ; vous obtiendrez quelque chose de plus discret et de plus corrosif. Comme l’a formulé un ingénieur sur Hacker News : « Les rétrospectives permettent d’exprimer des préoccupations, mais d’après mon expérience, rien ne se passe jamais vraiment à leur sujet. » Un autre, plus direct encore : « Je n’ai jamais rien vu se produire d’autre que des paroles. » C’est la plainte la plus fréquemment formulée à propos des rétrospectives, où que ce soit, et ce n’est pas celle que les conseils de notre secteur pensent qu’elle est.

Des mots, et rien que des mots

On part généralement du principe que les équipes « oublient de consigner les actions à mener » ; la solution habituelle consiste donc à mieux les formuler : les rendre « SMART », désigner un responsable, les ajouter au tableau. Mais cela passe à côté du véritable problème. Le problème réside rarement dans l’absence de mesures à mettre en œuvre ; il réside plutôt dans le fait que la mesure a bien été rédigée, ajoutée au backlog, puis est restée là indéfiniment tandis que la rétrospective suivante en générait trois autres. « J’ai répété les mêmes points de rétrospective de sprint après sprint sans qu’ils ne soient traités », confie quelqu’un d’un ton résigné. « Ce post-it ne sera pas traité. C’est un peu triste. » D’après une enquête souvent citée, seul environ un tiers des équipes mène systématiquement à bien ses actions issues de la rétrospective — et les deux tiers restants apprennent, sprint après sprint, que cette cérémonie ne produit que des mots, et rien d’autre. Il convient toutefois de prendre ces idées reçues avec précaution : nos propres données internes sur le pourcentage de points d’action issus des rétrospectives qui sont réellement menés à bien indiquent un taux de réalisation plus proche de trois sur quatre — et montrent que ce sont l’appropriation et la cadence, et non l’effort, qui déterminent cet écart.

La solution qui fonctionne vraiment ne réside pas dans davantage d’actions, mais dans moins d’actions. Limitez-vous à une seule. Une seule amélioration à laquelle l’équipe s’engage sincèrement, examinée en tout début de la prochaine rétrospective avant toute autre chose, vaut mieux qu’une liste de dix points qui finissent tous par tomber dans l’oubli. Si vous définissez trop de points d’action, la moitié ne sera pas réalisée — et cette moitié qui ne l’est pas enseigne à l’équipe que rien de tout cela n’a d’importance. Un seul point, attribué à un responsable et assorti d’une date de bilan, boucle la boucle qu’une longue liste laisse ouverte. Le chapitre Pourquoi les rétrospectives échouent de notre guide sur les rétrospectives explique comment boucler ce cycle au cours de la cérémonie, et la rétrospective « à cocher » décrite dans le chapitre Performance illustre le vide qui se crée avant que l’équipe ne baisse complètement les bras.

La soupape de pression

Mais il existe une version plus profonde de ce vide, et c’est celle que les conseils prodigués par notre secteur interprètent à l’envers. Parfois, les actions ne se concrétisent pas parce que l’équipe n’aurait de toute façon jamais été capable de les mener à bien — car les véritables problèmes dépassent réellement les compétences de l’équipe. Le budget, les effectifs, les dépendances entre équipes, une décision d’architecture prise deux échelons plus haut, une échéance fixée par le service commercial. L’équipe peut les énumérer à l’infini. Elle ne peut en résoudre aucun. La rétrospective devient alors une soupape de décompression : un lieu où l’on peut se défouler afin que la direction ait le sentiment que l’équipe a été entendue, sans qu’il y ait de mécanisme permettant de changer la situation qui fait l’objet de ces doléances.

C’est un développeur, dans un article publié sur dev.to, qui en donne l’expression la plus percutante, et cela mérite d’être cité dans son intégralité : « La rétrospective est devenue une soupape de pression. Une apparence de voix sans substance de pouvoir. » Ce même essai met le doigt sur un point qui devrait mettre tout coach mal à l’aise : « Blâmer l’animation, c’est comme blâmer la boîte à suggestions parce que la direction ne lit pas les suggestions. » Vous ne pouvez pas résoudre un problème de pouvoir par la seule facilitation. Et sur Hacker News, c’est dit sans détour : une rétrospective est « 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 contrôle de cette équipe » — et pire encore, « elle donne à la direction une excuse pour ne pas régler les problèmes ».

C’est là que la plupart des conseils prodigués par les prestataires causent un réel préjudice. La liste standard des anti-modèles recommande aux équipes de « rester dans leur cercle d’influence » — c’est-à-dire de cesser de soulever des points qu’elles ne peuvent pas changer. Présenté comme un problème de discipline propre à l’équipe, ce conseil est tout à fait erroné. Il incite l’équipe à occulter le véritable obstacle et à ne se concentrer que sur les détails mineurs, sans risque et maîtrisables par l’équipe, ce qui est précisément ce qui transforme une rétrospective en une mise en scène confortable. Rester dans son cercle d’influence est un mauvais conseil lorsque l’élément le plus important présent dans la salle se trouve en dehors de celui-ci.

Exprimez-vous vers l’extérieur, ne refoulez pas vos émotions vers l’intérieur

La bonne nouvelle, c’est que le texte de référence a déjà apporté la correction — et c’est l’édition actuelle qui l’a fait. La deuxième édition de Agile Retrospectives (2024), à laquelle David Horowitz s’est joint aux côtés d’Esther Derby et de Diana Larsen, a ajouté un chapitre entier consacré aux problèmes échappant au contrôle de l’équipe — la situation était devenue suffisamment critique pour que la référence s’y adapte. Trois de ses outils constituent l’antidote à cette soupape de pression :

• Cercles et « soupe » — classez chaque problème en fonction de la personne qui en est responsable : ce que l’équipe contrôle, ce sur quoi elle peut exercer une influence, et ce qui se trouve dans la « soupe », c’est-à-dire ce à quoi elle ne peut que réagir. Il s’agit d’un triage par responsabilité, qui remplace le principe « restez dans votre cercle » par « acheminez chaque problème vers la personne qui peut réellement y remédier ».
• Les solutions à 15 % — face à des problèmes complexes et insolubles, identifiez la partie sur laquelle l’équipe peut se lancer dès maintenant, sans avoir besoin de l’autorisation de qui que ce soit. Pas la solution dans son intégralité, mais les 15 % qui sont à votre portée. Mieux vaut créer une dynamique sur une partie du problème que de rester paralysé face à l’ensemble.
• Radiateurs rétrospectifs — rendez les problèmes escaladés visibles à l’extérieur, sur un tableau que la direction peut consulter, avec un suivi dans le temps. Un « radiateur » est l’opposé d’une « soupape » : une soupape libère la pression et la masque ; un radiateur met en évidence le problème non résolu jusqu’à ce qu’une personne ayant le pouvoir de le résoudre s’en charge. Signalez les problèmes « rouges » en citant nommément les personnes concernées.

C’est la ligne dure que mettent en évidence les recherches, et elle est étayée par les principes fondamentaux : trier en fonction de la responsabilité, signaler les points critiques en précisant le nom et la date, diffuser l’information plutôt que de la laisser s’évacuer. Une rétrospective qui applique ces principes fait preuve d’honnêteté quant au pouvoir. Une rétrospective qui les ignore n’est qu’une soupape de pression animée par un facilitateur.

Ce qui compte, c’est l’apprentissage, pas la liste des tâches à accomplir

Ce dernier recadrage vient boucler la boucle de l’ensemble du mode. La deuxième édition modifie également le critère de réussite lui-même — passant des actions concrètes à l’apprentissage. La position adoptée par la deuxième édition — et c’est un soulagement de l’entendre de la part des références en la matière — est qu’une rétrospective sans action à mener n’est pas un échec si l’équipe en a tiré des enseignements. L’unité de changement devient une expérience — une hypothèse que l’on teste avec une date de révision — plutôt qu’une tâche qui reste en suspens dans le backlog. « Nous pensons que le travail en binôme lors du déploiement réduira notre taux de retour en arrière ; nous allons l’essayer pendant deux sprints et faire le point » : voilà une expérience. « Améliorer les déploiements » est un post-it qui finit par être oublié.

Cela met également en lumière un coût qui ne figure jamais sur les listes d’anti-modèles : le fardeau émotionnel lié à une séance de pur défoulement. Comme l’a fait remarquer un participant, une rétrospective peut consister en « plus d’une heure passée assis là, à écouter principalement les autres se plaindre de tout et n’importe quoi, ce qui me déprime ». Une rétrospective qui se limite à un défoulement ne permet pas seulement de ne rien régler, elle pèse également sur les personnes qui doivent absorber ces plaintes. La solution n’est pas d’interdire les sentiments, mais de leur offrir une issue : transformer les points « rouges » en expériences prises en charge, datées et diffusées, et cette heure cesse alors d’être un lieu où la frustration ne fait que circuler.

C’est ainsi que l’on sort du vide et que l’on s’affranchit du guide. Il faut que la boucle soit suffisamment courte pour se refermer, que le triage soit suffisamment honnête pour signaler ce que l’équipe ne peut pas résoudre, et qu’on mesure l’apprentissage plutôt que de compter les actions — car une franchise qui ne change rien finit par cesser d’être de la franchise. Les quatre modes — Performance, Pouvoir, Surcharge et le Vide — sont, en fin de compte, la même question posée de quatre façons différentes : cette cérémonie remplit-elle sa fonction, ou se contente-t-elle de la mettre en œuvre ?

Foire aux questions

Que faites-vous lorsque les mêmes problèmes reviennent à chaque rétrospective ?

Déterminez pourquoi elles se reproduisent, car deux défaillances différentes peuvent sembler identiques vues de l’intérieur. Si l’action a été rédigée mais n’a jamais été attribuée à quelqu’un, elle reste en suspens dans le backlog tandis que la prochaine rétrospective en ajoute trois autres — limitez-vous à un seul élément attribué avec une date de révision, et commencez la prochaine rétrospective en le vérifiant. Si le problème revient sans cesse parce qu’il échappe véritablement au contrôle de l’équipe, le réinscrire ne servira à rien : triez-le en fonction de la personne qui en est responsable et remontez-le à la hiérarchie en précisant le nom et la date, au lieu de vous défouler à nouveau.

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

Ne poussez pas l’équipe à soulever des problèmes mineurs : c’est ainsi qu’une rétrospective se transforme en spectacle. Triez chaque problème en fonction de la personne qui en est réellement responsable, puis remontez les problèmes « rouges » à la hiérarchie en y joignant un nom et une date, et affichez-les sur un tableau de rétrospective afin qu’ils ne puissent pas être discrètement laissés de côté. Rester dans votre cercle d’influence est un mauvais conseil lorsque cela revient à occulter le véritable obstacle.

Comment faire en sorte que les actions à mener lors d’une rétrospective soient réellement menées à bien ?

Limitez-vous à une seule. Une seule amélioration à laquelle l’équipe s’engage sincèrement, examinée en tout premier lieu lors de la prochaine rétrospective avant toute autre chose, vaut mieux qu’une liste de dix points qui finissent tous par tomber dans l’oubli. Désignez-en un responsable et fixez une date de suivi, puis considérez-la comme une expérience reposant sur une hypothèse plutôt que comme une corvée sur une liste.

Une rétrospective doit-elle comporter une mesure à mettre en œuvre ?

Non — et insister sur le contraire fait partie du problème. La deuxième édition de Agile Retrospectives redéfinit le critère de réussite en mettant l’accent sur l’apprentissage, et non sur les actions à mener : une rétrospective au cours de laquelle l’équipe a véritablement compris quelque chose de nouveau n’est pas un échec simplement parce qu’elle n’a pas donné lieu à une liste de tâches. Menez des expériences dont vous pouvez tirer des enseignements, et non des tâches qui vous donneront mauvaise conscience.

Lectures complémentaires

• Le pouvoir : quand l’autorité prend le pas sur la cérémonie — pourquoi les problèmes qui mériteraient d’être soulevés dépassent si souvent les compétences de l’équipe.
• Spectacle : la cérémonie que vous organisez pour le public — le côté rétro « pour la forme », avant que l’équipe n’y renonce.
• Comment créer un espace de sécurité psychologique — une franchise qui trouve sa place.
• La « Prime Directive » rétrospective — la règle qui garantit l’intégrité de la salle.
• La rétrospective de sprint (la cérémonie) — la place qu’occupe la rétrospective dans le cycle, et la boucle qu’elle est censée boucler.
• Glossaire de l’agile Theatre — définition des quatre modes d’échec identifiés.