Événements clés

Que s'est-il passé, et à peu près quand ? Un événement par idée.

Début février : lancement du projet. On avait un objectif clair mais aucune définition de « terminé » partagée.
Semaine 3 - Sarah nous a rejoints depuis l'équipe plateforme et a repris le travail sur l'API.
Mi-avril : le client a demandé que le module de reporting passe dans la phase un.
Moments forts

Quand l'équipe était-elle au meilleur de sa forme, et pourquoi ?

Vers la semaine 8, quand la première démo a été bien accueillie par le client. J'ai enfin eu l'impression qu'on savait ce qu'on construisait.
Le hackathon de deux jours en avril. Tout le monde dans la même pièce, aucune réunion, et on a réglé le problème de la recherche.
Franchement, la meilleure période pour moi, c'était juillet, une fois le périmètre figé et qu'on a pu enfin avancer.
Moments difficiles

Quand l'équipe a-t-elle eu du mal, et pourquoi ?

Mi-avril, quand le module de reporting a été avancé. On venait de planifier les six semaines suivantes et tout est parti à la poubelle.
La migration ratée de mai. Trois soirées tardives et beaucoup de reproches échangés sur le canal.
Juin était morne. Sans designer, on devinait l'interface et on refaisait le travail.
Leçons pour la prochaine fois

Que referions-nous ou changerions-nous sur le prochain projet ?

Refaire un hackathon en présentiel au moins une fois par projet. C'est ce qui a débloqué la recherche.
Convenir avec le client, dès le lancement, d'un processus de changement de périmètre : qui valide et comment on replanifie.
Faire une répétition complète de toute migration de données dans un environnement proche de la production avant la semaine de mise en production.

Qu'est-ce qu'une rétrospective timeline ?

Une rétrospective timeline amène l'équipe à reconstituer l'histoire d'un travail de longue haleine, comme un projet, un trimestre ou une année, en plaçant dans l'ordre les événements qui l'ont marqué. L'activité vient de la communauté des rétrospectives agiles. Esther Derby et Diana Larsen la présentent comme un exercice de collecte de données dans leur livre Agile Retrospectives: Making Good Teams Great, et elle s'inspire des travaux antérieurs de Norm Kerth sur les rétrospectives de projet. Chacun ajoute les événements dont il se souvient, leur attribue une date approximative et indique ce qu'il a ressenti sur le moment. Le plus utile, c'est la courbe d'humeur. En plaçant les hauts et les bas de l'équipe à côté des événements qui les ont provoqués, on voit comment l'énergie a monté et baissé au fil du projet : le lancement qui a galvanisé tout le monde, la réorganisation qui a plombé le moral pendant un mois, le changement de périmètre tardif que personne n'avait vu venir. Des tendances apparaissent, qu'on ne verrait pas en regardant sprint par sprint, et les personnes arrivées en cours de route découvrent les parties de l'histoire qu'elles ont manquées. Dans TeamRetro, le modèle de rétrospective timeline comporte quatre thèmes : événements clés, moments forts, moments difficiles et leçons pour la prochaine fois. Les participants réfléchissent d'abord individuellement, puis l'équipe regroupe les idées liées, vote sur ce qui compte le plus et termine en convenant d'actions avec des responsables nommés. Ce format a besoin de suffisamment d'historique pour fonctionner, réservez-le donc à la fin d'un projet, d'un trimestre ou d'une année. Pour un sprint de deux semaines, il n'en vaut pas la peine et un format plus simple vous sera plus utile.

Format de rétrospective timeline

Événements clés

Que s'est-il passé, et à peu près quand ? Un événement par idée.

Les événements clés sont les faits de l'histoire : mises en production, décisions, arrivées ou départs, incidents, échéances et changements de cap. Demandez à chacun d'ajouter un seul événement par idée et de commencer par une date ou une semaine approximative (« Mi-mars », « Semaine 6 ») pour que l'équipe puisse les remettre dans l'ordre. Quelques jours avant la séance, envoyez un message invitant chacun à parcourir son agenda, les notes de version, les tickets et l'historique des discussions. La mémoire s'efface vite et, sans cette préparation, les dernières semaines prennent le pas sur les premières. Si les premiers mois paraissent peu fournis au moment où les idées sont révélées, signalez-le et laissez quelques minutes aux participants pour combler le vide.

Moments forts

Quand l'équipe était-elle au meilleur de sa forme, et pourquoi ?

Les moments forts sont ceux où l'énergie, la confiance ou le moral étaient au plus haut. Demandez à chacun de rattacher chaque moment à une date ou à un événement clé et de décrire ce qu'il a ressenti, au-delà de ce qui s'est passé. « Livrer la bêta a été un énorme soulagement après des semaines de doute » en dit plus que « Bêta livrée ». Cherchez ce que les moments forts ont en commun, par exemple des objectifs clairs, une bonne collaboration ou des progrès visibles, car ce sont ces conditions qu'il vaut la peine de recréer sur le prochain projet.

Moments difficiles

Quand l'équipe a-t-elle eu du mal, et pourquoi ?

Les moments difficiles sont ceux où l'énergie a chuté : frustration, stress, confusion ou épuisement. Demandez aux participants de les dater et de dire ce qu'ils ont ressenti, et rappelez au groupe que l'objectif est de comprendre ce qui s'est passé, pas de désigner des coupables. Certaines personnes ont du mal à évoquer des moments difficiles devant un manager : le brainstorming anonyme de TeamRetro est alors précieux. Pendant la discussion, vérifiez si les creux coïncident avec certains événements. Des creux répétés autour des changements de périmètre ou des passations signalent généralement un problème de processus qui mérite une action.

Leçons pour la prochaine fois

Que referions-nous ou changerions-nous sur le prochain projet ?

C'est avec les leçons que la timeline se transforme en décisions. Demandez aux participants d'examiner ensemble les moments forts et les moments difficiles, puis de proposer ce qu'il faut continuer et ce qu'il faut changer sur le prochain projet. Poussez-les vers des propositions précises : « Convenir d'un processus de changement avec le client dès le lancement » est actionnable, « Mieux communiquer » ne l'est pas. Une fois les idées regroupées et votées, transformez les deux ou trois premières en actions dans TeamRetro, chacune avec un responsable nommé et une échéance, pour que les leçons se retrouvent dans le prochain travail.

Dans quels cas recourir à cette étude rétrospective ?

  • À la fin d'un projet ou d'une version majeure, quand l'équipe veut revenir sur l'ensemble du travail avant de passer à autre chose.
  • Pour les bilans trimestriels ou annuels, quand il y a assez d'événements et assez de hauts et de bas pour dessiner une courbe d'humeur claire.
  • Quand des personnes sont arrivées ou parties en cours de route et que l'équipe a besoin d'une vision partagée de ce qui s'est passé et pourquoi.
  • Après une période de travail longue ou difficile, pour comprendre ce qui a épuisé l'énergie de l'équipe et ce qui l'a relancée.
  • Avant de lancer un projet similaire, pour recueillir des leçons sur lesquelles la nouvelle équipe pourra agir. Ce format n'en vaut pas la peine pour un sprint de deux semaines.

Exemples de questions pour brise-glace

  • Si ce projet était un film, quel serait son titre ?
  • Quel petit moment de ce projet vous a fait rire ?

Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →

Idées et conseils pour votre réunion de rétrospective

  • Quelques jours avant la séance, envoyez un message demandant à chacun de revoir son agenda, les notes de version, les tickets et l'historique des discussions. Sans cela, le biais de récence l'emporte et les dernières semaines dominent la timeline.
  • Demandez à chacun de commencer chaque idée par une date ou une semaine approximative. Les idées datées sont bien plus faciles à ordonner et à regrouper, et elles rendent visibles les hauts et les bas de l'humeur de l'équipe.
  • Encouragez les participants à dire ce qu'ils ont ressenti face à chaque événement, et pas seulement ce qui s'est passé. C'est la dimension émotionnelle qui distingue une timeline d'un rapport d'avancement de projet.
  • Utilisez le brainstorming anonyme pour que chacun puisse évoquer honnêtement les moments difficiles, surtout en présence de managers ou de parties prenantes. Centrez la discussion sur les événements et les conditions, pas sur les personnes.
  • Prévoyez plus de temps que pour une rétro de sprint classique. Un long projet a beaucoup d'historique : comptez 60–90 minutes et limitez le temps de chaque thème pour que les leçons ne soient pas expédiées à la fin.
  • Terminez par un petit nombre d'actions, chacune avec un responsable nommé et une échéance. Passez-les en revue au début du projet suivant pour que les leçons soient bien appliquées.

Foire aux questions

Qu'est-ce qu'une rétrospective timeline ?
Une rétrospective timeline est un format dans lequel l'équipe place dans l'ordre les événements clés d'un projet, d'un trimestre ou d'une année, puis ajoute les moments forts et les moments difficiles vécus en chemin. Comparer les événements à l'humeur de l'équipe montre ce qui a aidé et ce qui a nui, et la séance se termine par des actions convenues ensemble.
Combien de temps dure une rétrospective timeline ?
La plupart des rétrospectives timeline durent 60–90 minutes, selon la taille de l'équipe et la durée de la période examinée. Un bilan annuel avec une grande équipe peut demander près de deux heures.
Puis-je utiliser une rétrospective timeline pour un sprint ?
Pour un sprint de deux semaines, elle n'en vaut pas la peine. Il y a trop peu d'événements à placer et trop peu de variations d'humeur : un format plus simple comme Start, Stop, Continue vous apportera davantage en moins de temps.
Quelle différence entre une rétrospective timeline et un post-mortem ?
Une timeline couvre tout l'arc d'un projet, le bon comme le mauvais, et s'intéresse au ressenti de l'équipe au fil des événements. Un post-mortem analyse ce qui a mal tourné, généralement après un incident ou un échec, pour en trouver les causes profondes.
Comment éviter que les participants ne se souviennent que des dernières semaines ?
Demandez aux participants de revoir leur agenda, les notes de version, les tickets et l'historique des discussions avant la séance. Pendant le brainstorming, signalez les périodes peu fournies de la timeline et laissez quelques minutes pour ajouter des événements correspondants.
Pourquoi faut-il dater les idées ?
Les dates permettent à l'équipe de remettre les événements dans l'ordre et d'aligner les moments forts et difficiles sur ce qui se passait à ce moment-là. C'est grâce à cet alignement qu'on repère des tendances, comme une baisse du moral après chaque changement de périmètre.
Êtes-vous prêt à mener cette rétrospective ?Essayez ce concert rétrospectif