Téléchargez le modèle de rétrospective
Imprimez-le pour l'afficher au mur ou modifiez-le dans l'outil que vous utilisez déjà. Gratuit, sans e-mail ni inscription. Les fichiers sont en anglais.
Une rétrospective agile est une réunion courte et régulière où l'équipe revient sur une période de travail, le plus souvent un sprint, et se met d'accord sur ce qu'elle va changer dans sa façon de travailler. La réunion de planification porte sur ce que l'équipe va construire ; la rétrospective, sur la manière dont elle construit. Le résultat n'est pas une liste de reproches, mais un ou deux changements concrets que l'équipe testera avant la prochaine rétrospective.
Les rétrospectives viennent directement du Manifeste agile de 2001, dont le dernier principe demande aux équipes de réfléchir à intervalles réguliers aux moyens de devenir plus efficaces, puis d'ajuster leur comportement en conséquence. En Scrum, la Rétrospective de Sprint est l'événement qui clôt chaque sprint.
Ce guide présente les cinq étapes d'une bonne rétrospective, compare les formats les plus courants et déroule un exemple concret : une équipe qui passe de ses post-it à un seul changement validé, avec un responsable.
En bref
Une rétrospective a rempli son rôle quand l'équipe repart avec un changement précis, un responsable et un moyen de vérifier si cela a marché. Tout le reste de la réunion sert à trouver ce changement.
La Prime Directive
La plupart des rétrospectives commencent par rappeler la Prime Directive de la rétrospective, formulée par Norm Kerth dans Project Retrospectives (2001). En résumé : quoi que nous découvrions, nous partons du principe que chacun a fait de son mieux, compte tenu de ce qu'il savait, de ses compétences, des ressources disponibles et de la situation du moment.
Il ne s'agit pas d'une formule de politesse. Une équipe qui s'attend à être blâmée donne des retours prudents et génériques, et cache la vraie cause. C'est en écartant toute recherche de coupable que l'on permet à quelqu'un de dire à voix haute « Je ne savais pas que la spécification avait changé », et c'est généralement à ce moment-là que la partie utile de la réunion commence.
Les cinq étapes d'une rétrospective
Dans leur livre Agile Retrospectives, Esther Derby et Diana Larsen décrivent cinq étapes que suivent presque toutes les bonnes rétrospectives, quel que soit le format :
| Étape | Objectif | Durée type dans une rétro de 45 minutes |
|---|---|---|
| 1. Planter le décor | Rappeler l'objectif et la Prime Directive ; faire parler tout le monde dès le début | 5 minutes |
| 2. Collecter les données | Rassembler ce qui s'est passé : faits, événements et ressentis | 10 minutes |
| 3. Générer des idées | Regrouper les données, choisir le thème principal et en trouver la cause profonde | 15 minutes |
| 4. Décider quoi faire | Choisir un ou deux changements, chacun avec un responsable | 10 minutes |
| 5. Clôturer | Confirmer les engagements et faire le point sur la réunion | 5 minutes |
L'étape que les équipes sautent le plus souvent est la troisième. Passer directement de « voici nos post-it » à « voici nos actions » produit des actions qui traitent les symptômes.
Les formats de rétrospective les plus courants
Le format, c'est l'ensemble des questions posées à l'étape 2. Varier les formats évite qu'une rétrospective régulière tourne à la routine.
| Format | Questions | Idéal pour |
|---|---|---|
| Start, Stop, Continue | Que devrions-nous commencer, arrêter et continuer à faire ? | Nouvelles équipes ; rétros rapides |
| Starfish | Continuer, faire plus, faire moins, arrêter, commencer | Les équipes qui veulent plus de nuances que « bien » et « pas bien » |
| Mad, Sad, Glad | Qu'est-ce qui vous a agacé, déçu ou réjoui ? | Les sprints éprouvants sur le plan émotionnel |
| 4L | Liked, Learned, Lacked, Longed for (aimé, appris, manqué, souhaité) | La fin d'un projet ou d'un trimestre |
| Voilier (Sailboat) | Le vent (ce qui a aidé), les ancres (ce qui nous a freinés), les rochers (les risques à venir) | Les équipes qui abordent une période risquée |
| Frise chronologique | Placer les événements clés du sprint, puis marquer les hauts et les bas | Les bilans après un incident ou une mise en production |
Le Starfish (étoile de mer), généralement attribué à Patrick Kua, est le format de notre modèle de rétrospective gratuit. Ses cinq catégories laissent de la place à « ça marche, mais on en fait trop », une nuance qu'un simple découpage bien/pas bien fait disparaître.
Un exemple concret de rétrospective
Voici une rétrospective de 45 minutes pour une équipe produit fictive de sept personnes. Leur sprint de deux semaines s'est terminé avec la livraison d'une fonctionnalité d'export client trois jours en retard.
Étape 1 : planter le décor (5 minutes)
Le facilitateur rappelle la Prime Directive et annonce l'objectif : « Nous avons livré l'export avec trois jours de retard. Cherchons pourquoi et mettons-nous d'accord sur un changement pour le prochain sprint. » Chacun résume le sprint en un mot. Deux personnes disent « précipité ».
Étape 2 : collecter les données (10 minutes)
L'équipe dresse rapidement la chronologie du sprint, puis chacun écrit ses notes Starfish en silence pendant cinq minutes, pour que la voix la plus forte n'impose pas l'ordre du jour.
| Continuer | Faire plus | Faire moins | Arrêter | Commencer |
|---|---|---|---|---|
| Des daily stand-ups de moins de 15 minutes | Du pair programming sur les stories délicates | Des revues de design improvisées dans le chat | Changer les critères d'acceptation en plein sprint | Montrer les maquettes au client avant le sprint |
| Écrire les tests avant de merger | Des démos au client | Des réunions de suivi qui pourraient tenir en un message | Démarrer des stories sans maquette finale |
Étape 3 : générer des idées (15 minutes)
L'équipe regroupe les notes et vote. Le groupe le plus important, de loin, concerne des exigences qui ont changé après le début du sprint. L'équipe lui applique la méthode des 5 pourquoi :
- Pourquoi l'export a-t-il été livré en retard ? Les tests ont montré qu'il ne correspondait pas à ce qu'attendait le client.
- Pourquoi ? Les critères d'acceptation ont changé le sixième jour du sprint.
- Pourquoi ? La responsable des opérations du client a vu la maquette pour la première fois le cinquième jour.
- Pourquoi ? Les maquettes sont revues en interne, mais pas montrées au client avant qu'une story entre dans le sprint.
- Pourquoi ? Personne n'est responsable de la validation client. L'équipe produit pensait que les account managers s'en chargeaient, et les account managers pensaient que c'était l'équipe produit.
La cause profonde n'est pas « la communication ». C'est une étape du processus qui n'a pas de responsable.
Étape 4 : décider quoi faire (10 minutes)
Quelqu'un propose de « mieux communiquer avec le client ». Le facilitateur objecte : c'est un souhait, pas un changement. L'équipe s'accorde plutôt sur une expérimentation :
- Changement : pendant les deux prochains sprints, toute story qui modifie ce que voit le client doit avoir une maquette validée par le client avant d'entrer dans le sprint.
- Responsable : la product manager.
- Comment nous le saurons : compter les stories dont les critères d'acceptation changent après le début du sprint. Au dernier sprint, il y en a eu trois.
Les autres notes vont sur une liste à revoir plus tard. L'équipe s'engage sur un changement, pas sur sept.
Étape 5 : clôturer (5 minutes)
Le facilitateur relit l'expérimentation et le nom du responsable, et chacun note la rétrospective de un à cinq. La prochaine rétrospective commencera par vérifier ce compteur.
Pourquoi une rétrospective échoue
- Aucune action, ou trop d'actions. Une liste de dix améliorations n'appartient à personne. Choisissez-en une ou deux.
- Des actions qui sont des vœux pieux. « Mieux communiquer » ne peut pas se faire lundi matin. « Le client valide les maquettes avant le sprint », si.
- Ne jamais vérifier l'action précédente. Si la rétrospective suivante ne commence pas par faire le point sur le dernier changement, l'équipe apprend que les engagements sont facultatifs.
- La recherche de coupables. Dès qu'une personne est pointée du doigt, tous les autres commencent à filtrer ce qu'ils disent.
- Toujours le même format. Variez les questions pour que l'équipe ne donne pas les mêmes réponses en pilote automatique.
Supprimer purement et simplement les rétrospectives a aussi un coût, que nous détaillons dans le coût de la dette de processus.
Rétrospective, revue de sprint ou post-mortem ?
On confond souvent ces trois réunions, parce qu'elles regardent toutes en arrière :
- Revue de sprint : l'équipe montre aux parties prenantes ce qu'elle a construit et recueille leurs retours sur le produit.
- Rétrospective : l'équipe examine comment elle a travaillé et fait évoluer son processus. Les parties prenantes ne sont généralement pas présentes.
- Post-mortem : une analyse ponctuelle d'un incident ou d'un échec précis. Elle reprend souvent les mêmes étapes, avec une chronologie au centre.
Modèle de rétrospective gratuit
Le modèle de rétrospective gratuit est disponible en PDF, en document Word, en classeur Excel et en présentation PowerPoint. Il reprend le format Starfish, avec des questions pour chacune des cinq catégories et un tableau de suivi des actions, avec responsables et échéances.
Pour aller plus loin sur les rétrospectives
- Comment animer une rétrospective de projet : la posture du facilitateur et comment gérer une salle tendue.
- Comment animer une rétrospective de sprint dans Microsoft Teams : un déroulé de 45 minutes à distance.
- Le coût de la dette de processus : pourquoi sauter les rétrospectives ralentit les équipes.
Questions fréquentes
À quelle fréquence une équipe doit-elle faire une rétrospective ?
À la fin de chaque sprint, ou toutes les deux à quatre semaines pour les équipes qui ne travaillent pas en sprints. Il est aussi courant d'en organiser une après une mise en production importante ou un incident.
Combien de temps doit durer une rétrospective ?
Environ 45 minutes pour un sprint de deux semaines. Le Guide Scrum limite la Rétrospective de Sprint à trois heures pour un sprint d'un mois et précise qu'elle est généralement plus courte pour des sprints plus courts.
Qui doit participer à une rétrospective ?
Les personnes qui ont fait le travail : l'équipe de réalisation, y compris le Product Owner et le Scrum Master en Scrum. Les managers et les parties prenantes restent généralement à l'écart, pour que chacun puisse parler librement.
Qui doit animer une rétrospective ?
Souvent le Scrum Master ou un membre de l'équipe, à tour de rôle. Faire tourner l'animation aide, et pour une rétrospective tendue, un facilitateur extérieur peut garder la salle concentrée sur le processus plutôt que sur les personnes.
Que produit une rétrospective ?
Un ou deux changements de processus précis, chacun avec un responsable et un moyen de vérifier, à la rétrospective suivante, s'il a fonctionné.
Envie de passer à la pratique ? Lancez-vous avec votre équipe grâce au modèle de rétrospective gratuit.
