La rétrospective qui a enfin tenu : le redressement d'une équipe
La rétrospective de sprint est le seul événement de Scrum dont le but entier est de rendre l'équipe meilleure. Le Guide Scrum est sans détour : l'équipe examine comment s'est déroulé le dernier sprint et détermine les améliorations à mettre en œuvre lors du suivant. Pourtant, bien des équipes en font une série de remerciements suivie d'une liste bien rangée que personne ne rouvre jamais. Voici l'histoire anonymisée d'une équipe de livraison hybride, en pleine reprise au début de 2021 entre télétravail et perturbations d'approvisionnement persistantes, dont les rétrospectives ont enfin commencé à changer quelque chose.
Ce qui n'allait pas
L'équipe — appelons-la l'escouade du Port — tenait une rétrospective à chaque sprint, à l'heure, pendant une heure complète. Les gens étaient présents, surtout caméra allumée, et disaient des choses raisonnables. Le Scrum Master regroupait les notes en trois colonnes : ce qui a bien fonctionné, ce qui n'a pas fonctionné, les idées. Le tableau se remplissait. Et rien ne bougeait. La même plainte sur des environnements de test instables est revenue dans quatre rétrospectives consécutives. Personne ne s'en chargeait, personne ne réglait le problème, et au bout d'un moment l'équipe a cessé de le soulever, parce que le soulever était devenu un rituel sans conséquence.
Le vrai problème n'était pas le format. C'est que la rétrospective produisait de la parole, pas des engagements. Les améliorations restaient des observations en suspens, pas du travail que quelqu'un avait accepté de faire.
Les trois changements qui ont compté
Une amélioration, dans le backlog. Au lieu d'une liste de souhaits, l'équipe sortait de chaque rétrospective avec exactement une amélioration qu'elle comptait vraiment réaliser au prochain sprint — et elle l'ajoutait au backlog de sprint comme un véritable élément avec un responsable. Le Guide Scrum le permet explicitement : l'amélioration la plus marquante est traitée dès que possible. La placer dans le backlog la faisait concurrencer la capacité comme tout autre travail, au lieu d'être un conseil gratuit.
Commencer par les données, pas par les ressentis. Avant les opinions, le Scrum Master consacrait cinq minutes aux faits du sprint : combien d'éléments reportés, où le temps de cycle a grimpé, quel environnement a échoué et quand. Ancrer la discussion dans des preuves l'empêchait de dériver vers la théorie favorite du plus bruyant et faisait ressortir le problème d'environnement de test comme un coût mesurable et récurrent, plutôt qu'une vague rouspétance.
Vérifier d'abord la dernière fois. Chaque rétrospective s'ouvrait désormais par la revue de l'unique amélioration du sprint précédent. L'avons-nous faite? A-t-elle aidé? Cette seule habitude a créé de la responsabilité. Une amélioration qui réapparaît sans cesse sans être traitée n'est plus facile à ignorer quand la première chose qu'on fait est de la lire à voix haute.
Pour une équipe répartie, la mécanique comptait aussi. Elle utilisait un tableau en ligne partagé pour que les membres à distance et au bureau aient une voix égale, accordait à chacun quelques minutes de silence pour écrire avant de parler, et faisait tourner l'animation afin que ce ne soit pas toujours la même personne aux commandes. Rien d'exotique. C'est juste la différence entre une réunion qui mime l'amélioration et une qui la produit.
Ce qui a changé trois mois plus tard
L'environnement de test instable a été réglé — parce qu'il est enfin devenu un élément du backlog, avec un responsable et un sprint pour vivre. Plus important encore, l'équipe a compris qu'une rétrospective n'est ni une séance de défoulement ni un rapport d'avancement. C'est un petit acte délibéré pour changer sa façon de travailler, une amélioration à la fois, avec la discipline de vérifier si elle a vraiment porté. Visez un vrai changement par sprint que vous menez jusqu'au bout, et vous devancerez toute équipe qui en poursuit dix qui s'évaporent.
Repartez avec une amélioration, pas dix.
Faites-en un élément du backlog avec un responsable, pas une note autocollante.
Ouvrez la rétrospective suivante en vérifiant si elle a fonctionné.
Si vos équipes mènent des rétrospectives qui ne changent jamais rien, le conseil en réalisation de programmes et de projets de XNM peut vous aider à bâtir des habitudes de livraison qui tiennent vraiment.