La Rétrospective de sprint : apprendre réellement

Presque toutes les équipes font une rétrospective de sprint. Beaucoup en font une et ne voient aucune différence après. La réunion se passe, on liste des problèmes qu'on connaît déjà, on dit "on va améliorer ça", et deux sprints plus tard c'est exactement pareil.

Le problème n'est pas que la rétro soit une mauvaise idée. C'est que beaucoup en font une cérémonie creuse au lieu d'un vrai moment d'apprentissage.

Pourquoi une rétrospective ?

Le contexte : un sprint se termine. L'équipe a livré quelque chose, ou pas. Elle a rencontré des problèmes, ou peut-être pas. Le réflexe normal est de dire "bon, sprint suivant, même chose" et de continuer. C'est le cycle.

La rétrospective dit : attendez. Prenons 60 à 90 minutes pour demander "comment on a vraiment travaillé ensemble cette semaine ?" et "qu'est-ce qu'on pourrait changer pour que ce soit meilleur la prochaine fois ?"

Ça paraît évident, mais c'est un acte intentionnel. Sans la rétro, on continue en mode automatique et on reproduit les mêmes patterns. Avec la rétro bien faite, on crée une boucle d'apprentissage. Sprint après sprint, l'équipe s'améliore.

Le format qui fonctionne

Une bonne rétro tourne autour de trois questions simples.

Qu'est-ce qui a bien fonctionné ? Pas juste pour se féliciter, mais vraiment : qu'est-ce qu'on a fait différemment et qui a eu un effet positif ? Si on n'identifie pas ce qui marche, on ne peut pas le garder ou le reproduire.

Qu'est-ce qui a posé problème ? Ici, on ne cherche pas des coupables. On cherche les obstacles : peut-être qu'on s'attend tous entre nous chaque jour et qu'on perd deux heures, peut-être qu'on ne comprend pas vraiment ce qu'on doit construire jusqu'à jeudi, peut-être qu'une intégration est tellement lente qu'on en vient à éviter de pusher le code.

Qu'est-ce qu'on décide de changer ? C'est la partie cruciale. L'équipe doit choisir une ou deux améliorations à tester dès le prochain sprint. Pas dix améliorations, pas une liste de souhaits. Une ou deux choses concrètes qu'on peut vraiment essayer.

Le Scrum Master facilite. Il s'assure que tout le monde parle, que ça ne part pas en débat sans fin, que les décisions se prennent.

La tension : bienveillance vs transformation réelle

Il y a une tension inhérente dans les rétros bien faites.

D'un côté, il faut que l'espace soit bienveillant. Si les gens ont peur de dire la vérité (parce que le manager est assis à côté, ou parce qu'ils ont peur de vexer quelqu'un), la rétro devient du théâtre. On dit ce qui plaît, on se rencontre, on part.

De l'autre côté, une rétro bienveillante mais qui ne produit rien n'a aucune valeur. Si on se plaît entre nous mais qu'on ne change rien, on reste bloqués dans les mêmes patterns. L'équipe finit frustrée parce qu'elle parle de ses problèmes sans jamais les résoudre.

Les meilleures rétros que j'ai vues tenaient cet équilibre : on peut parler franchement (parce que tout le monde sait que l'intention est de s'améliorer, pas de blâmer), mais on exige aussi de se transformer. Les deux sprints suivants, on regarde si ce qu'on a décidé a changé quelque chose. Si non, on comprend pourquoi et on ajuste.

Les pièges à éviter

Ne pas terminer par des décisions. Si la rétro ne produit pas des actions concrètes qu'on teste au prochain sprint, c'est juste du défoulement. Les gens sortent satisfaits d'avoir parlé, mais rien ne change.

Comparer la rétro à une réunion de bilan. Une réunion de bilan, c'est "qu'est-ce qu'on a livré ?" Une rétro, c'est "comment on a travaillé ensemble pour livrer ça". Deux questions très différentes.

Laisser le même problème revenir chaque sprint. Si on dit chaque rétro "on ne comprend pas les requirements assez tôt" et qu'on ne change rien pour que le Product Owner affine les stories plus tôt, c'est un signal que la rétro n'est pas prise au sérieux.

Faire participer trop de monde. La rétro, c'est pour l'équipe qui vit au quotidien. Si le VP du produit vient s'asseoir, les gens parlent différemment. Ça peut être utile parfois (pour montrer qu'on écoute), mais ce n'est pas le moment principal.

Ce qu'il faut retenir

Une rétrospective efficace est une boucle d'apprentissage. L'équipe réfléchit ensemble, identifie ce qui peut changer, teste une amélioration, et la semaine suivante elle regarde si ça a eu un effet.

Avec le temps, ça crée une équipe qui s'améliore d'elle-même. Elle ne blâme pas le système (ou elle le fait moins) parce qu'elle sait qu'elle peut agir. Elle ne reste pas bloquée parce qu'elle apprend vite de ses essais.

Pour les équipes qui cherchent à structurer leur rétro, des outils comme Retro Tool ou les templates Miro offrent des formats alternatifs pour varier et relancer l'engagement si la rétro devient routinière.