Pourquoi vos rétrospectives agiles ne changent jamais rien

Une équipe qui identifie les mêmes trois problèmes à chaque rétrospective, sprint après sprint, sans qu'aucun ne se résolve, n'a pas un problème d'assiduité au rituel. Elle a un problème de suivi.

Le symptôme classique

La rétrospective se déroule normalement : les participants s'expriment, des post-its s'accumulent, des points sont notés. Puis le sprint suivant commence, et personne ne revient sur ce qui avait été décidé. Trois sprints plus tard, les mêmes problèmes reviennent, presque mot pour mot.

Pourquoi ça se produit

Les actions décidées ne sont pas de vraies actions

"Améliorer la communication avec l'équipe design" n'est pas une action, c'est une intention. Une action réelle a un propriétaire nommé, un délai, et un critère de vérification : qui fait quoi, avant quand, et comment on saura que c'est fait.

Personne ne relit les actions de la rétrospective précédente

La rétrospective démarre presque toujours par un tour de table ouvert plutôt que par une relecture des engagements pris la fois précédente. Sans ce rappel, les mêmes sujets ressurgissent parce que personne ne se souvient qu'ils avaient déjà été traités, ou que la décision prise n'a jamais été appliquée.

Le format devient prévisible et personne n'ose plus être honnête

Un même format répété sprint après sprint, sans variation, finit par produire des réponses de convenance. Les participants savent ce qu'ils sont censés dire, et le disent, sans que ça reflète nécessairement ce qui bloque réellement.

Ce qui rend une rétrospective réellement utile

Ouvrir chaque rétrospective par la relecture des actions décidées la fois précédente, avec un statut explicite pour chacune : faite, en cours, abandonnée et pourquoi. Ne jamais sortir de la rétrospective avec plus de deux ou trois actions engagées, avec un propriétaire et une date, plutôt qu'une longue liste de bonnes intentions que personne ne suivra. Varier le format de temps en temps (rétrospective thématique, focus sur un seul sujet plutôt que balayage général) pour éviter l'effet de routine qui tue l'honnêteté des échanges.

Ce que je vérifie quand j'anime ou j'audite ce rituel

Le test le plus simple : demander à l'équipe de citer la dernière action décidée en rétrospective, et son statut actuel. Si personne ne s'en souvient précisément, le rituel produit de la discussion sans produire de changement, ce qui revient à en faire un théâtre plutôt qu'un outil d'amélioration continue, la même dynamique que celle que j'ai décrite pour les comités de pilotage qui ne servent à rien.

C'est ce type de diagnostic de rituel que j'intègre dans mon activité de Delivery Manager : un rituel agile n'a de valeur que si ses décisions survivent au-delà de la réunion elle-même. Sur la priorisation des actions qui en ressortent, ma matrice RICE reste l'outil que j'utilise pour arbitrer entre plusieurs pistes d'amélioration identifiées.