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 filmée, une séance de planification peut être surchargée, et l’équipe ressentira tout de même 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 se déroule, les gens s’expriment franchement, des post-it sont rédigés, tout le monde acquiesce. Puis le sprint se termine et rien n’a changé. 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 tient plutôt au fait que celles-ci ont bien été rédigées, ajoutées au backlog, puis sont restées là indéfiniment tandis que la rétrospective suivante en générait trois de plus. « J’ai répété les mêmes points de rétrospective de sprint après sprint sans qu’ils ne soient jamais traités », confie un participant résigné. « Cette note autocollante ne sera pas prise en compte. 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, tandis que 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 anecdotes avec précaution : nos propres données internes sur le pourcentage de points d’action issus des rétrospectives qui sont effectivement menés à bien indiquent un taux de réalisation plus proche de trois sur quatre, et montrent que ce sont la prise en charge et la régularité, et non l’effort, qui déterminent cet écart.

La solution qui fonctionne vraiment ne consiste pas à multiplier les actions, mais à les réduire. 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. Ce conseil n’est pas nouveau : Johanna Rothman recommande, dans Create Your Successful Agile Project, de ne retenir qu’un seul point, considéré comme une expérience et intégré au prochain bloc de travail de l’équipe. Si vous définissez trop de points d’action, la moitié ne sera pas réalisée, et cette moitié non réalisée apprendra à l’équipe que rien de tout cela n’a d’importance. Une seule tâche, attribuée à un responsable et assortie d’une date de révision, 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 cette boucle 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 n’abandonne complètement.

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 : 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 espace 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 : « reprocher à l’animation d’être à l’origine d’un problème, c’est comme reprocher à la boîte à suggestions que la direction ne lise 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 questions profondes soulevées par les participants ne relèvent pas du pouvoir de contrôle de cette équipe ». Pire encore : « cela 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 éléments 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 votre 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é cette correction, et c’est l’édition actuelle qui l’a intégrée. La deuxième édition de Agile Rétrospectives (2024), à laquelle David Horowitz s’est associé à Esther Derby et 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 l’ouvrage de référence s’adapte en conséquence. 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, en distinguant 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 ».
• 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 de l’extérieur, sur un tableau que la direction peut consulter, et suivez leur évolution 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 les citant nommément.

C’est la ligne de conduite stricte que mettent en évidence les recherches, et elle est étayée par la doctrine : procéder à un tri 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 suit cette approche fait preuve d’honnêteté quant au pouvoir. Une rétrospective qui ne le fait pas 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 boucle la boucle sur l’ensemble du mode de fonctionnement. La deuxième édition modifie également le critère de réussite lui-même, en le faisant passer des actions à mettre en œuvre à l’apprentissage. Sa position (et c’est un soulagement de l’entendre émaner de la référence en la matière) est qu’une rétrospective sans action à mettre en œuvre n’est pas un échec si l’équipe a appris quelque chose. L’unité de changement devient une expérience : une hypothèse que vous testez 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 pure défoulement. Comme l’a formulé l’un des participants, une rétrospective peut être « 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 pas régler les problèmes. Elle pèse sur les personnes qui doivent absorber ces plaintes. La solution n’est pas d’interdire les sentiments ; elle consiste à 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 moment où la frustration ne fait que circuler.

C’est ainsi que l’on sort du vide et que l’on s’affranchit du guide. Réalisez une boucle suffisamment courte pour la boucler, effectuez un triage suffisamment honnête pour signaler ce que l’équipe ne peut pas résoudre, et mesurez l’apprentissage plutôt que de compter les actions, car une franchise qui ne change rien finit par ne plus être de la franchise. Les quatre modes (Performance, Puissance, Surcharge et le Vide) reviennent, en fin de compte, à poser la même question de quatre façons différentes : cette cérémonie remplit-elle sa fonction, ou se contente-t-elle de la mettre en scène ?

Foire aux questions

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

Déterminez pourquoi elles reviennent, car deux défaillances différentes peuvent sembler identiques vues de l’intérieur. Si l’action a été répertoriée mais n’a jamais été prise en charge, elle reste en suspens dans le backlog tandis que la rétrospective suivante en ajoute trois autres. Limitez-vous à une seule tâche attribuée, assortie d’une date de révision, et commencez la rétrospective suivante par son examen. 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 mise en scène. 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 indiquant 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 de 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 nécessite-t-elle une mesure à mettre en œuvre ?

Non, et insister sur ce point 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 feront vous sentir coupable.

Lectures complémentaires

• Le pouvoir : quand l’autorité s’empare de 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’honnêteté au sein 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 de défaillance identifiés.