Actions de rétrospective : pourquoi elles ne sont jamais faites

Fin de rétro. L’équipe a bien discuté, une liste d’actions a été notée, tout le monde repart satisfait. Deux semaines plus tard, à la rétro suivante, quelqu’un demande ce que sont devenues ces actions. Silence. Personne ne sait vraiment, et les mêmes sujets réapparaissent sur les cartes.

C’est le défaut le plus répandu des rétrospectives, et le plus coûteux : une rétro dont les actions ne sont pas faites n’est qu’une discussion, et l’équipe finit par le comprendre. Les causes sont presque toujours les mêmes, et presque toutes se corrigent pendant la séance.

Les six raisons pour lesquelles elles ne sont pas faites

1. Il y en a trop

Huit actions pour un sprint de deux semaines, en plus du travail prévu, c’est une liste de vœux. Personne ne choisit explicitement de les abandonner : elles passent simplement après tout le reste.

2. Elles sont trop vagues

« Mieux communiquer », « Faire plus attention aux tests », « Améliorer les specs ». Ce sont des intentions, pas des actions : on ne peut ni les commencer ni dire quand elles sont terminées.

3. Elles appartiennent à « l’équipe »

Une action confiée à tout le monde n’est confiée à personne. Chacun suppose qu’un autre s’en occupe.

4. Elles n’ont pas d’échéance

Sans date, une action n’est jamais en retard, donc jamais urgente. Elle glisse d’un sprint à l’autre jusqu’à être oubliée.

5. Elles disparaissent entre deux rétros

Notées dans un compte rendu que personne ne rouvre, ou sur un tableau archivé à la fin de la séance, les actions sortent du champ de vision de l’équipe au moment précis où elles devraient y entrer.

6. Elles ne dépendent pas de l’équipe

« Avoir plus de temps », « Que le métier priorise mieux » : une action que l’équipe ne peut pas réaliser elle-même est vouée à rester ouverte. La version actionnable est presque toujours une démarche : aller voir quelqu’un, proposer quelque chose, mesurer un problème pour l’objectiver.

Écrire une action qui aboutit

Une bonne action de rétro tient en une phrase et répond à trois questions : quoi (un geste concret, dont on saura dire qu’il est fait), qui (une personne, pas un groupe) et quand (une date, idéalement avant la prochaine rétro). Quelques exemples de réécriture :

Et une limite : une à trois actions par rétro, pas plus. Si l’équipe en identifie davantage, elle choisit. C’est précisément le rôle du vote : ne discuter, et donc n’agir, que sur ce qui compte le plus.

Les garder sous les yeux

Une action bien écrite peut encore être oubliée si elle est rangée au mauvais endroit. Trois habitudes changent tout :

• Les poser pendant la séance, pas après. Le responsable et la date se décident tant que tout le monde est là. Une action « à attribuer plus tard » ne le sera pas.
• Les rendre visibles entre deux rétros. Dans le backlog du sprint, sur le tableau de l’équipe, ou dans l’outil de rétro lui-même : un endroit que l’équipe consulte déjà, pas un document qu’il faut aller chercher.
• Ouvrir la rétro suivante par leur état. Quelques minutes en début de séance : fait, pas fait, abandonné (et pourquoi). C’est ce qui donne à l’équipe la preuve que la rétro change quelque chose.

Actions et décisions, ce n’est pas la même chose

Toutes les conclusions d’une rétro ne sont pas des tâches. « On ne déploie plus le vendredi après-midi » n’a ni responsable ni échéance : c’est une décision, une règle que l’équipe se donne. La noter comme une action, c’est la voir « faite » et oubliée. Tenez deux listes : les actions, qui se ferment, et les décisions, qui restent valables jusqu’à ce que l’équipe les revoie.

Dans SquadRetro

Dans SquadRetro, chaque action sort de la séance avec un responsable et une échéance, posés pendant la rétro. Actions et décisions se consultent et se pointent à n’importe quelle phase, sans quitter la séance, et toutes celles de la squad sont rassemblées sur sa page, séance après séance. Pour le reste du déroulé, lisez le guide pour animer une rétrospective agile .