Articles

Comment Obtenir des Éléments d'Action Exploitables de tes Rétrospectives

Équipe agile rassemblée autour d'un tableau blanc lors d'une rétrospective, écrivant des éléments d'action clairs avec les noms des propriétaires et les délais sur des cartes Ton équipe organise des rétrospectives. Vous identifiez les problèmes. Vous écrivez les éléments d'action sur des post-its ou les tapez dans un document partagé. Et puis rien ne se passe. À mi-sprint, personne ne se souvient de ce qui a été décidé. Lors de la rétrospective suivante, les mêmes problèmes réapparaissent. C'est le mode de défaillance le plus courant dans les équipes agiles, et il n'a rien à voir avec le format de rétrospective que tu choisis. Le problème est ce qui se passe après la fin de la discussion. Les équipes qui organisent des rétrospectives efficaces échouent toujours dans le suivi lorsque leurs éléments d'action sont vagues, non assignés et non suivis. Une enquête de la Scrum Alliance en 2023 a révélé que seulement 35% des équipes complètent systématiquement les éléments d'action de leurs rétrospectives. Les 65% restants génèrent des idées sur lesquelles ils n'agissent jamais, ce qui est pire que de ne pas avoir la conversation du tout. Cela enseigne à l'équipe que les rétrospectives ne mènent pas à des changements.

Le cimetière des éléments d'action

Avant de corriger le problème, il est utile de comprendre pourquoi les éléments d'action des rétrospectives meurent. Il y a quatre modèles constants.

Pas de propriétaire

"Nous devrions améliorer nos revues de code" apparaît sur le tableau. Tout le monde hocha la tête. Personne n'est responsable de sa réalisation. Sans un nom assigné, un élément d'action est un souhait, pas un engagement.

Trop vague

"Communiquer mieux" n'est pas quelque chose que quelqu'un peut concrétiser. Qu'est-ce que mieux signifie? Communiquer sur quoi? Avec qui? Les éléments d'action vagues ne peuvent pas être lancés car personne ne sait à quoi ressemble la première étape.

Trop ambitieux

"Réécrire le pipeline de déploiement" est un projet, pas un élément d'action. Lorsque la portée est trop grande pour un seul sprint, l'équipe ne commence jamais ou l'abandonne à mi-chemin parce que d'autres travaux prennent la priorité.

Pas de suivi

Même les éléments d'action bien rédigés disparaissent quand il n'y a pas de système pour les suivre. Ils vivent dans les notes de réunion que personne n'ouvre, ou sur un tableau blanc qui est effacé. Sans visibilité, il n'y a pas de responsabilité.

Ce qui rend un élément d'action exploitable

La différence entre un élément d'action qui se réalise et celui qui ne se réalise pas se résume généralement à quatre propriétés. Si tu as utilisé le cadre d'objectifs SMART pour la fixation d'objectifs, les mêmes principes s'appliquent ici, adaptés à du travail de la taille d'un sprint. Voici un test simple: si un nouveau membre de l'équipe lisait l'élément d'action sans contexte, saurait-il exactement quoi faire, qui le fait, et quand cela doit être terminé? Si non, il faut être plus net.

Avant et après: vague vs. exploitable

L'écart entre un élément d'action inutile et un élément utile n'est généralement que quelques mots supplémentaires. Voici des exemples réels.

Élément d'action vague	Version exploitable
Améliorer les revues de code	Ajouter une liste de contrôle de 5 éléments au modèle de PR d'ici mercredi, assigné à Sarah
Mieux communiquer sur les blocages	Publier les blocages dans le canal #dev-blockers de Slack dans l'heure suivant leur occurrence, à partir de ce sprint, assigné à toute l'équipe
Corriger les tests instables	Identifier et corriger les 3 tests les plus instables dans CI d'ici la fin du sprint, assigné à James
Mieux planifier	Examiner les 5 premiers éléments du backlog avec le propriétaire du produit avant la planification du sprint mardi, assigné à Maria
Réduire les réunions	Annuler la synchronisation du mercredi et la remplacer par une mise à jour asynchrone dans Slack pendant 2 sprints comme expérience, assigné à Alex

Comparaison côte à côte montrant des post-its vagues avec des points d'interrogation à gauche et des éléments d'action propres et organisés avec des coches, des noms de propriétaires et des dates à droite Remarque le modèle. Chaque version exploitable répond à trois questions: qui fera quoi quand. Ce seul modèle transforme la plupart des sorties de rétrospectives.

Techniques pour générer de meilleurs éléments d'action

Arriver à des éléments d'action spécifiques, assignés et délimités dans le temps ne se fait pas par hasard. Ces techniques en font une partie naturelle du flux de rétrospective.

Utilise le modèle "qui fera quoi quand"

Après que l'équipe discute d'un problème et se mette d'accord sur une direction, ne rédige pas encore l'élément d'action. À la place, pose trois questions à haute voix:

1. Qui en sera le propriétaire?
2. Quoi spécifiquement vont-ils faire?
3. Quand cela sera-t-il terminé?

Rédige l'élément d'action seulement après que les trois aient été répondus. Cela prend 30 secondes par élément et élimine la plupart des engagements vagues. De nombreux modèles de rétrospective incluent maintenant des sections dédiées pour capturer ces trois éléments, ce qui garde le format cohérent.

Vote sur les éléments d'action, pas seulement les problèmes

La plupart des équipes utilisent le vote par points pour prioriser les problèmes. Mais identifier le plus gros problème ne garantit pas une bonne solution. À la place, génère deux ou trois éléments d'action candidats pour chaque problème principal, puis vote sur quel élément d'action l'équipe souhaite s'engager. Cela déplace l'énergie de "qu'est-ce qui ne va pas" à "que allons-nous faire à ce sujet", qui est le vrai lieu de valeur d'une rétrospective.

Limite à 1-3 éléments d'action par rétrospective

C'est contre-intuitif, mais moins d'éléments d'action signifie que plus en sont terminés. Quand une équipe quitte une rétrospective avec sept éléments d'action, la charge cognitive est trop élevée et aucun d'eux n'obtient d'attention. Quand il y en a deux, l'équipe peut réellement se concentrer. La cadence de tes rétrospectives compte aussi ici. Les équipes qui organisent des rétrospectives chaque sprint ont plus de chances d'itérer, donc chaque rétrospective individuelle peut se permettre de se concentrer sur moins d'éléments.

Suivre l'avancement

Rédiger de bons éléments d'action est la moitié du problème. L'autre moitié consiste à s'assurer qu'ils ne disparaissent pas entre les rétrospectives.

Examine d'abord les éléments du dernier sprint

Commence chaque rétrospective en examinant les éléments d'action du sprint précédent. Pour chacun, demande: a-t-il été réalisé? Si oui, a-t-il aidé? Si non, pourquoi pas? Cela crée une boucle de rétroaction. L'équipe voit si ses actions ont conduit à l'amélioration, ce qui motive un meilleur suivi la prochaine fois. Cela expose aussi les obstacles systémiques. Si le même élément d'action s'étend sur trois sprints d'affilée, l'équipe doit soit le décomposer en étapes plus petites, soit admettre que ce n'est pas une véritable priorité. Équipe examinant une liste de contrôle des éléments d'action terminés et en cours sur un tableau numérique, avec des coches vertes et des indicateurs de progression

Rendre les éléments d'action visibles pendant le sprint

Les éléments d'action doivent vivre là où l'équipe travaille déjà. Ajoute-les au tableau du sprint. Ajoute-les en tant que tickets. Mets-les dans un message Slack épinglé. Le mécanisme importe moins que la visibilité. Si l'équipe doit chercher ses éléments d'action, elle ne le fera pas. Certaines équipes ajoutent les éléments d'action des rétrospectives directement à leur backlog de planification du sprint, les traitant comme des éléments de travail de première classe. C'est efficace car cela oblige l'équipe à comptabiliser le travail d'amélioration dans sa capacité, au lieu d'espérer qu'il se produise en plus du travail de livraison régulier.

Intègre les éléments d'action dans ta Définition de Fini

Quand un élément d'action de rétrospective crée une nouvelle norme d'équipe, comme "tous les PR ont besoin d'au moins deux examinateurs", ajoute-le à ta liste de contrôle de définition de fini. Cela transforme une amélioration unique en un changement de processus permanent. L'élément d'action est terminé quand la DoD est mise à jour et que l'équipe commence à la suivre.

Quand les éléments d'action continuent d'échouer

Si l'équipe échoue systématiquement à terminer les éléments d'action malgré leur bonne rédaction et suivi, la cause première est généralement l'une de trois choses. L'équipe est surchargée. Il n'y a pas de capacité pour le travail d'amélioration car chaque sprint est chargé à la limite. La solution: réserve explicitement 10-15% de la capacité du sprint pour les éléments d'action des rétrospectives et la dette technique. Fais-en une politique, pas un espoir. Les éléments d'action ne sont pas assez importants. S'ils continuent à être déprioritisés, peut-être qu'ils n'auraient pas dû être des éléments d'action en premier lieu. La rétrospective a exposé une légère gêne, pas un vrai problème. Une meilleure identification des problèmes mène à des éléments d'action que les gens se soucient vraiment de réaliser. Personne ne ressent la propriété. Cela pointe souvent vers un problème plus profond de sécurité psychologique. Si les gens ne se sentent pas autorisés à changer le processus, ils ne se battront pas pour leurs éléments d'action quand des priorités concurrentes émergent. Le travail du facilitateur est d'assurer que les éléments d'action ont un soutien authentique, pas seulement un accord courtois.

Mener une rétrospective conçue pour les éléments d'action

Voici un format léger qui produit naturellement des sorties exploitables. Il fonctionne avec n'importe quel modèle de rétrospective comme dernière étape. Le tout s'inscrit dans un laps de temps de 60 minutes, et l'équipe sort avec des engagements concrets, assignés et suivis au lieu d'une liste de bonnes intentions.

Pour commencer

Si tes rétrospectives ont produit des éléments d'action qui ne vont nulle part, ne révolutionne pas tout le processus à la fois. Commence par un changement: à la fin de ta prochaine rétrospective, prends l'élément d'action principal et fais-le passer par le filtre qui/quoi/quand. Assigne un nom. Fixe une date. Ajoute-le au tableau du sprint. Puis ouvre la rétrospective suivante en demandant si elle a été réalisée. Cette unique boucle, rédige-la clairement, suis-la, examine-la, est la base. Une fois que l'équipe voit que les décisions de rétrospective mènent réellement à des changements, la qualité des conversations dans la rétrospective elle-même s'améliorera. Les gens soulèvent de meilleurs problèmes quand ils croient que quelque chose se produira en conséquence. Tes rétrospectives ne sont que aussi précieuses que les changements qu'elles produisent. Rends ces changements spécifiques, assignés et visibles, et la rétrospective devient la réunion la plus productive du calendrier.