Rétrospectives
qui changent quelque chose.

La rétrospective est le seul rituel agile dont le produit est un changement de comportement. C'est aussi celui qu'on sacrifie en premier quand le sprint dérape — ce qui est exactement le moment où on en aurait le plus besoin.

Définition

Une rétrospective est une réunion de fin de cycle où l'équipe examine sa propre façon de travailler — pas le produit — et choisit des ajustements concrets pour le cycle suivant. En Scrum, elle clôt chaque sprint.

Distinction utile : la revue de sprint parle du produit avec les parties prenantes ; la rétrospective parle du processus, entre les gens qui font le travail. Les confondre vide la seconde de son intérêt, parce que personne ne dira devant un client ce qui n'a pas marché.

La structure en cinq temps

La trame classique, issue de Agile Retrospectives de Derby et Larsen, tient en cinq étapes :

1. Ouvrir. Faire parler tout le monde une première fois, même brièvement. Quelqu'un qui n'a pas ouvert la bouche dans les cinq premières minutes a de bonnes chances de rester silencieux jusqu'au bout.
2. Rassembler les faits. Ce qui s'est passé, sans interprétation : incidents, retards, réussites, chiffres.
3. Générer des idées. Pourquoi c'est arrivé, et qu'est-ce qu'on pourrait faire autrement.
4. Décider quoi faire. Une ou deux actions, pas dix.
5. Clore. Récapituler les décisions et à qui elles appartiennent.

Cinq formats qui fonctionnent

Start / Stop / Continue

Trois colonnes : ce qu'on commence, ce qu'on arrête, ce qu'on garde. Simple, rapide, efficace pour une équipe qui débute. Son défaut : il pousse aux symptômes plutôt qu'aux causes.

Mad / Sad / Glad

Trois colonnes émotionnelles. Utile quand la tension est palpable et que personne n'ose la nommer. Le format donne la permission de parler de ce qui irrite.

Les 5 pourquoi

On prend un seul problème et on demande « pourquoi » cinq fois de suite. Le build est lent → pourquoi ? → les tests tournent en série → pourquoi ? → personne n'a le temps de paralléliser → pourquoi ? → le travail d'outillage n'entre jamais dans le sprint. La vraie cause est presque toujours à deux ou trois niveaux sous le symptôme.

Le voilier

Un dessin : le vent qui pousse, l'ancre qui retient, les rochers devant, l'île à atteindre. Le support visuel débloque les équipes qui tournent en rond sur les mêmes trois plaintes.

La ligne du temps

On reconstruit le sprint jour par jour, puis chacun place ses hauts et ses bas. Excellent après un incident ou une livraison difficile : les gens se souviennent de choses différentes, et l'écart est instructif.

Changez de format toutes les trois ou quatre rétrospectives. Le même canevas trop longtemps produit les mêmes réponses.

Pourquoi la plupart des rétrospectives ne changent rien

Quatre causes, par ordre de fréquence :

• Trop d'actions. Une équipe qui sort avec huit engagements n'en tiendra aucun. Une seule action réellement terminée bat huit intentions.
• Aucun propriétaire, aucune échéance. « Il faudrait améliorer les tests » n'est pas une action. « Marie ajoute les tests d'intégration sur le module de paiement, d'ici la fin du prochain sprint » en est une.
• Les actions ne sont pas dans le backlog. Si l'amélioration ne prend pas de capacité dans le sprint, elle sera écrasée par la première urgence. Le travail d'amélioration doit être visible et budgété comme le reste.
• Pas de sécurité psychologique. Si dire « j'ai bloqué trois jours et je ne l'ai dit à personne » a un coût, personne ne le dira. Vous récolterez des rétrospectives polies et inutiles. C'est le facteur numéro un, et le plus difficile à corriger.

Test simple : commencez la rétrospective en vérifiant les actions de la précédente. Si vous n'osez pas le faire parce que rien n'a été fait, vous connaissez déjà le diagnostic.

La règle de base

La directive première de Norm Kerth se lit ainsi : quoi qu'on découvre, chacun a fait de son mieux compte tenu de ce qu'il savait, de ses compétences, des ressources disponibles et de la situation.

Ce n'est pas de la gentillesse décorative. C'est ce qui fait la différence entre une analyse de cause et une recherche de coupable — et une équipe qui cherche un coupable arrête immédiatement de rapporter les problèmes.

Et si l'équipe est distribuée ?

Les rétrospectives à distance échouent surtout par manque de temps de réflexion silencieuse. En présentiel, on écrit sur des papiers autocollants en parallèle ; en visioconférence, une seule personne parle à la fois et les premières idées ancrent tout le reste. Réservez trois à cinq minutes d'écriture silencieuse dans un tableau partagé avant toute discussion. Ça change tout.

Questions fréquentes

À quoi sert une rétrospective agile ?

À examiner la façon de travailler de l'équipe — pas le produit — et à décider d'un ou deux ajustements concrets pour le cycle suivant. C'est le mécanisme d'amélioration continue intégré au cadre agile.

Combien de temps doit durer une rétrospective ?

Environ quarante-cinq minutes pour un sprint d'une semaine, une heure et demie pour un sprint de deux semaines. La règle usuelle est de compter environ quarante-cinq minutes par semaine de sprint.

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

La revue de sprint présente le produit aux parties prenantes et récolte leur retour. La rétrospective porte sur le processus de l'équipe et se tient entre les personnes qui font le travail.

Combien d'actions faut-il sortir d'une rétrospective ?

Une ou deux, avec un responsable nommé et une échéance, inscrites dans le backlog du sprint suivant. Une équipe qui repart avec huit engagements n'en tiendra aucun.

À lire ensuite

• Scrum : rôles, événements et artefacts
• Agile : c'est quoi, vraiment ?
• Dette technique : la mesurer et la rembourser
• Story points et vélocité

Parlons de votre projet

Nos ingénieurs déployés s'assoient dans vos rituels et transfèrent les compétences pendant qu'ils livrent. Parlez-nous de votre équipe.