Rétrospective

La rétrospective (ou « rétro ») est la réunion qui clôt chaque sprint. L’équipe s’y retrouve pour examiner non pas le produit livré, mais sa façon de travailler : ce qui a bien fonctionné, ce qui a coincé, et ce qu’elle change dès le sprint suivant. Pour un sprint de deux semaines, elle dure en général une heure à une heure et demie.

Dans Scrum, c’est le dernier des quatre événements du sprint, après le sprint planning, les daily meetings et la revue de sprint. C’est aussi le plus souvent sacrifié quand le calendrier se tend, alors que c’est le seul dont l’objet est l’équipe elle-même. Bien menée, la rétrospective est le mécanisme par lequel une équipe progresse d’un sprint à l’autre. Mal menée, ou purement cosmétique, elle devient une heure perdue toutes les deux semaines.

À quoi sert une rétrospective

L’idée de fond est l’amélioration par petits pas. Une équipe qui enchaîne une douzaine de sprints par semestre et corrige un irritant à chaque rétrospective a changé une douzaine de choses en six mois : une relecture de code simplifiée, une règle sur les interruptions, un environnement de test fiable. Aucun ajustement n’est spectaculaire, mais leur accumulation l’est. C’est la logique du kaizen japonais appliquée à la méthode agile.

La rétrospective est aussi le seul moment formel où chacun peut dire ce qu’il a vécu pendant le sprint, satisfactions et frustrations comprises. La parole d’un développeur junior y compte autant que celle du Product Owner. C’est cette égalité qui fait remonter les vrais problèmes : des user stories trop floues, des priorités qui changent en cours de sprint, une dette technique qui ralentit tout le monde sans que personne ne l’ait chiffrée. Sur ce dernier point, les phrases entendues en rétro sont souvent le premier signal d’alerte, bien avant les indicateurs techniques.

Enfin, les améliorations décidées en rétrospective viennent de l’équipe, pas de la direction. Une règle que l’équipe s’est donnée elle-même est appliquée. La même règle imposée d’en haut est subie, puis contournée.

Comment se déroule une rétrospective de sprint

Le déroulement de référence, décrit par Esther Derby et Diana Larsen dans Agile Retrospectives (2006), comporte cinq étapes : ouvrir la séance, collecter les faits, chercher à les comprendre, décider des actions, clore. La plupart des équipes le condensent en trois questions.

Qu’est-ce qui a bien fonctionné ? Les pratiques à conserver : une relecture de code fluide, une bonne communication avec le client, un déploiement sans accroc. Commencer par là donne le ton et ancre la discussion dans le concret.

Qu’est-ce qui a posé problème ? Sans chercher de coupable : des spécifications floues, des interruptions trop fréquentes, des tests insuffisants, des réunions qui n’avancent pas. On parle de processus et de systèmes, pas d’individus.

Que change-t-on au prochain sprint ? Pour chaque problème retenu, une action concrète, avec un responsable et une échéance. C’est l’étape qui compte. Sans elle, la rétrospective est une conversation agréable et rien de plus. Le Guide Scrum recommande d’ailleurs d’ajouter les améliorations les plus importantes au backlog du sprint suivant, au même titre qu’une fonctionnalité.

Les formats alternatifs

Après vingt rétrospectives sur le même modèle, la routine s’installe et les remarques se répètent. Varier le format relance la réflexion :

• Le bateau à voile : le vent représente ce qui pousse l’équipe, les ancres ce qui la freine, les récifs les risques à venir.
• L’étoile de mer : cinq catégories (continuer, commencer, arrêter, faire plus, faire moins) pour affiner le tri.
• Mad / Sad / Glad : chacun classe ses observations selon ce qui l’a agacé, déçu ou satisfait, ce qui met le ressenti au centre.
• Le radar d’équipe : chaque membre note plusieurs dimensions (communication, qualité, collaboration) de 1 à 5, et les écarts de notation lancent la discussion.

Le format importe moins que la qualité de la discussion et la pertinence des actions qui en sortent.

Les règles d’une rétrospective qui produit des résultats

Un facilitateur, pas un chef

La rétrospective est animée par le Scrum Master ou par un membre de l’équipe, à tour de rôle. Jamais par le manager, ni par le Product Owner seul. Le facilitateur distribue la parole, tient le temps et ramène la discussion vers des solutions quand elle glisse vers les reproches.

La directive première

Norm Kerth, qui a formalisé les rétrospectives de projet en 2001, a posé le postulat que la plupart des équipes agiles ont repris : « Quoi que nous découvrions, nous sommes convaincus que chacun a fait de son mieux avec ce qu’il savait, ses compétences et les moyens dont il disposait. » Lue au début de la séance, cette phrase n’est pas une formule de politesse. Elle crée la confiance sans laquelle les vrais problèmes restent tus.

Un temps fixe et respecté

La durée est annoncée au départ et tenue. Si la séance déborde à chaque fois, le problème n’est pas le format : ce sont des sujets de fond qui méritent leur propre réunion. On les note, on les traite à part.

Deux ou trois actions, pas dix

Une liste de dix actions est une liste que personne ne suivra. Deux ou trois actions effectivement réalisées valent mieux que dix intentions. Chaque action a un responsable et une échéance, et la rétrospective suivante commence par vérifier ce qui a été fait. C’est ce contrôle qui distingue une rétrospective utile d’un exercice de style.

Les erreurs qui vident la rétrospective de son sens

La plus destructrice est la séance de reproches. « Le sprint a dérapé à cause de tel développeur » tue la sécurité psychologique, et au sprint suivant plus personne ne parle. La formulation utile est : « Notre relecture de code n’a pas détecté ce type de bug. Comment l’améliorer ? »

Vient ensuite la rétrospective sans suite. Quand les mêmes problèmes remontent trois ou quatre séances d’affilée sans être traités, l’équipe se désengage : « À quoi bon, rien ne change. » Un sujet qui revient pour la troisième fois dépasse en général l’équipe (budget, dépendance externe, décision d’organisation) et doit être remonté plutôt que remis sur un post-it.

Troisième erreur : laisser une personne dominer. Quand le fondateur ou le Product Owner monopolise la parole, les développeurs se taisent, et leurs observations sont souvent les plus précieuses. Le facilitateur doit rééquilibrer activement.

Dernière erreur, très répandue : annuler la rétro quand le sprint s’est « bien passé ». Les sprints calmes sont justement ceux où l’on peut prendre du recul et repérer des améliorations que la gestion de crise masque.

La rétrospective hors de Scrum

Le principe dépasse le cadre Scrum. En Kanban, il n’y a pas de sprint, donc pas de fin de sprint : l’équipe se réunit à cadence fixe, toutes les deux semaines ou tous les mois, pour examiner ses métriques de flux (temps de cycle, débit, blocages) et améliorer son processus. Au niveau de l’entreprise, la revue trimestrielle des OKR joue le même rôle : comprendre les écarts entre objectifs et résultats, puis décider ce qu’on change au trimestre suivant.

Le post-mortem, organisé après un incident ou à la fin d’un projet, est un cousin de la rétrospective : même règle (chercher les causes, pas les coupables), mais appliquée à un événement précis plutôt qu’à une période de travail.

Rétrospective à distance et en asynchrone

En télétravail, un tableau collaboratif (Miro, FigJam ou un outil dédié) remplace les post-it. Chacun écrit en même temps, ce qui évite que les premiers à parler orientent les autres, et une phase d’écriture anonyme suivie d’un vote aide à faire remonter les sujets sensibles.

Pour les équipes réparties sur plusieurs fuseaux horaires, un format hybride fonctionne bien : collecte asynchrone pendant la semaine dans un canal dédié, puis trente minutes en visioconférence pour prioriser et décider.

FAQ rétrospective

Quelle différence entre la revue de sprint et la rétrospective ?

La revue de sprint porte sur le produit : l’équipe montre ce qu’elle a livré aux parties prenantes et recueille leurs retours. La rétrospective porte sur l’équipe et sa façon de travailler, et se tient entre membres de l’équipe juste après. Les deux sont souvent confondues, et c’est en général la seconde qui disparaît au profit de la démo.

Qui participe à la rétrospective ? Le fondateur doit-il y être ?

Toute l’équipe Scrum : développeurs, designers, Scrum Master et Product Owner. Pas de parties prenantes extérieures ni de hiérarchie, sinon la parole se ferme. Un fondateur qui tient le rôle de Product Owner participe pleinement, avec les mêmes règles que les autres, et en acceptant que certaines actions le concernent directement (des priorités qui changent trop souvent, par exemple).

Combien de temps dure une rétrospective ?

Une heure à une heure et demie pour un sprint de deux semaines, trois heures au maximum pour un sprint d’un mois selon le Guide Scrum. En dessous de quarante-cinq minutes, l’équipe n’a pas le temps de dépasser les constats de surface.

Comment Polara Studio anime les rétrospectives

Chez Polara Studio, chaque sprint de deux semaines se termine par une rétrospective, y compris quand le calendrier est serré. Nous la considérons comme l’investissement le plus rentable du sprint : une heure qui rend les dix jours suivants plus efficaces.

Nos clients y participent, en général dans le rôle de Product Owner. Nous suivons quelques règles simples : commencer par vérifier les actions du sprint précédent, varier les formats pour éviter la routine, limiter les décisions à deux ou trois, et nommer un responsable pour chacune.

Un constat récurrent : les premières rétrospectives d’un projet sont les plus denses, parce que des problèmes accumulés depuis des mois remontent d’un coup. Au fil des sprints, les discussions portent sur des réglages plus fins, signe que les gros irritants ont été traités. C’est précisément à ce moment que l’on est tenté d’arrêter, et c’est là qu’il faut continuer.