Vendredi – 16:00 Sprint Rétrospective
Ah, ce doux rappel de calendrier… Un rituel bien rodé où les bons élèves égrènent consciencieusement les points positifs et les axes d’amélioration, tandis que d’autres, moins assidus, griffonnent leur to-do list du week-end ou se perdent dans la contemplation silencieuse de la semaine écoulée.
Rétro ou routine ?
Depuis plusieurs mois, l’équipe utilise des templates classiques de rétrospective : Le voilier et son île imaginaire, la rétro en 4L (Liked, Learned, Lacked, Longed for), ou encore la simple matrice des émotions (énergie, frustration, idées). Si ces formats ont d’abord aidé à structurer les discussions, une monotonie s’est progressivement installée. Les participants viennent sans enthousiasme, et les mêmes sujets reviennent sans réel impact. Il est temps de changer d’approche.
Thomas, le Scrum Master, lève la main pour capter l’attention. « On démarre. Qui veut partager un point positif pour commencer ? » lance-t-il avec un sourire, cherchant à instaurer une atmosphère constructive.
« Les nouvelles Nespresso Voluptuoso Doro sont excellentes » plaisante une voix au fond, déclenchant quelques hochements de tête approbateurs.
Pauline, nouvelle développeuse, saisit l’opportunité. « J’aimerais qu’on parle des problèmes de licences que l’on a rencontrés cette semaine sur l’environnement de dév » commence-t-elle. « Enfin, je ne sais pas si l’on a droit d’en parler ici. »
Un court silence suit. Jean-Luc, le Product Owner, lève les yeux au ciel, visiblement agacé. « Oui, on doit faire le point mais ce n’est pas le lieu pour en parler, c’est un investissement qui demande un arbitrage et bon bref… »
Thomas, fidèle à son rôle de facilitateur, intervient calmement. « Jean-Luc, ces problèmes techniques ne sont pas des plaintes anodines. Ils révèlent des blocages qui impactent directement la productivité et la qualité des livraisons. Prenons le temps de comprendre ce qui se passe. Une rétro, ce n’est pas qu’une liste de bonnes intentions, c’est le moment d’identifier ce qui freine la valeur que nous délivrons. »
Psychological safety : la clé d’une discussion ouverte
Thomas poursuit, rappelant les bases de la psychological safety : « Ici, tout le monde a le droit d’exprimer des problèmes, sans jugement. C’est comme ça qu’on progresse. »
Il ajoute : « La sécurité psychologique, c’est ce qui permet à chacun de parler des vrais sujets, même les plus sensibles. Sans ce cadre, on risque de se limiter à des discussions superficielles, où les problèmes restent sous le tapis. Nous sommes une équipe, et chaque voix compte. »
Pauline, encouragée par ces mots, se redresse légèrement. Les regards des autres membres de l’équipe s’adoucissent, certains hochant la tête en signe d’approbation. Thomas vient de poser une base essentielle : le droit de questionner, d’explorer et d’améliorer collectivement sans peur de jugement ou de représailles.
L’UX Designer entre en scène
Thomas reprend avec un ton engageant : « Écoutez, je sais que ce problème est complexe. Essayons une approche différente. Hugo, tu peux nous guider ? »
Hugo, l’UX Designer, reprend calmement. « Bien sûr. Je vous propose de construire ensemble une Developer Journey Map. C’est une méthode qu’on utilise pour comprendre les utilisateurs finaux, mais elle fonctionne aussi pour analyser nos propres processus internes. »
La révélation des Pain Points
Hugo ouvre Miro, dévoilant une matrice divisée en étapes clés de la journée d’un développeur : démarrage, développement, résolution de problèmes, réunions. « L’idée est simple : identifiez où vous avez été bloqués à cause du problème de licence et décrivez l’impact. Ajoutez aussi des idées de solutions si elles vous viennent. »
Hugo donne quelques minutes à l’équipe pour remplir la matrice. Les stickies s’accumulent rapidement dans l’application, dévoilant les points de friction. Une fois terminé, il invite à la discussion :
« Merci à tous. Voyons les éléments clés. Pauline, tu veux commencer ? »
Pauline consulte la matrice et répond : « C’est toujours au moment de la configuration des outils que je perds du temps. J’ai dû refaire la même manipulation trois fois cette semaine. »
John enchaîne : « Moi, c’est pendant les tests. Sans licence valide, impossible de tout vérifier correctement. Ça ralentit tout. »
Jean-Luc, les bras croisés, lâche : « Tout ça, c’est bien beau, mais ça ne va pas résoudre nos problèmes d’achat. »
Hugo répond calmement : « Jean-Luc, l’objectif ici n’est pas de résoudre tout d’un coup, mais de mettre en lumière l’ampleur du problème. Regardez cette carte : elle montre combien de temps, d’énergie et de qualité nous perdons chaque jour. »
Thomas rebondit : « Ces données, c’est du concret. Elles nous aideront à convaincre les décideurs. Mais concentrons-nous aussi sur ce qu’on peut faire dès maintenant. »
La collaboration porte ses fruits
Les idées fusent rapidement : mutualiser une licence, utiliser une alternative open source, ou réorganiser les priorités pour limiter l’impact à court terme.
Jean-Luc, intrigué malgré lui, demande : « L’open source, c’est compatible avec nos outils ? »
John sourit : « Oui, et ça ne demande pas de configuration lourde. »
En une heure, l’équipe identifie des solutions pratiques et construit un dossier solide pour défendre un investissement à long terme.
Hugo conclut avec un sourire : « Cette carte, ce n’est pas juste un outil. C’est votre histoire, vos frustrations, vos idées. Vous avez construit une vision claire à partir de vos expériences. C’est ça, le vrai pouvoir de la méthode. »
Une équipe soudée autour d’une vision
Jean-Luc, presque à contrecœur, admet : « OK, je ne pensais pas qu’on irait aussi loin en si peu de temps. J’étais sceptique, mais je dois dire que c’était… utile. »
Thomas conclut : « Ce qu’on vient de faire, c’est une démonstration de l’intelligence collective. Et la Sprint Review n’est pas juste un moment pour exposer des problèmes, c’est une opportunité pour les résoudre ensemble. »
Hugo ajoute, sourire en coin : « Et parfois, ça demande de mettre un peu de méthode dans le chaos. »
Et trois mois plus tard ?
Trois mois plus tard, l’équipe ne peut plus imaginer travailler sans les ateliers collaboratifs initiés par Hugo et Thomas. Les Sprint Reviews, autrefois expéditives, sont devenues des espaces stratégiques et constructifs. Chaque membre, du développeur au Product Owner, sait que son rôle compte et que ses idées ont un impact.
Grâce aux outils comme le Developer Journey Map, les blocages sont identifiés en amont, et les solutions adaptées émergent rapidement. Même Jean-Luc, le sceptique de toujours, ne tarit plus d’éloges : « Ces ateliers nous ont fait gagner plus qu’une licence logicielle. Ils ont révélé une nouvelle manière de travailler, où chaque problème devient une opportunité. »
La collaboration, autrefois source de tension, est désormais une véritable force pour l’équipe. Pauline résume l’évolution avec un sourire complice : « On avance enfin, ensemble, et ça change tout. »
Optimiser l’impact des rétrospectives Agile
- Donner du sens à la rétrospective. Rappelez à l’équipe que c’est une occasion de progresser, pas une formalité. Montrez des exemples concrets d’améliorations réalisées grâce à ces moments.
- Instaurer un climat de confiance. Créez un espace sans jugement où les membres de l’équipe peuvent parler librement.
- Rendre la rétrospective vivante et engageante. Mettez fin à la monotonie : utilisez des outils comme Miro ou Mural, des post-it, ou des activités collaboratives pour dynamiser les discussions.
- Impliquer un UX Designer. Grâce à son expertise, il aide à cartographier les parcours, identifier les points de friction et aligner les solutions techniques sur les besoins utilisateurs.
- Assurer le suivi des décisions prises. Attribuez des responsabilités avec des délais réalistes pour passer à l’action et motiver l’équipe.
- Encourager la participation de tous. Chaque voix compte : créez des conditions où chacun, du junior au senior, peut contribuer sans crainte.
- Faire de l’amélioration continue une culture. Intégrez les rétrospectives dans l’ADN de l’équipe et valorisez les petites avancées pour maintenir la motivation.
Pour aller plus loin : Pilotez vos débriefings comme un pilote de chasse
Pour illustrer l’importance de la rétrospective, faisons une analogie avec les pilotes de chasse. Saviez-vous que ces professionnels de l’aviation effectuent systématiquement un débriefing après chaque mission ? Qu’il s’agisse d’un entraînement ou d’une mission stratégique, cet exercice est aussi, voire plus, important que leur mission dans les airs. Pourquoi ? Parce que c’est un moyen crucial de progresser, d’apprendre de leurs erreurs et de leurs succès, et de s’assurer qu’ils sont toujours prêts pour la prochaine mission. Et, fait intéressant, les débriefings sont tout aussi essentiels — sinon plus difficiles à mener — lorsque tout s’est bien passé. Reconnaître les succès, analyser les décisions qui ont permis de les atteindre et les formaliser demande une rigueur souvent sous-estimée. Pourtant, c’est ce qui garantit que les bonnes pratiques ne disparaissent pas dans l’oubli et deviennent des réflexes pour l’avenir.
Écoutez Virginie Guyot, ancienne pilote de chasse de la Patrouille de France, dans l’épisode 151 du podcast Generation Do It Yourself : Débriefer pour atteindre l’excellence. Elle explique comment le débriefing est un élément essentiel de leur routine pour atteindre des niveaux d’excellence inégalés.
En route pour l’enfer dans une forteresse volante
Enfin, si vous souhaitez comprendre l’importance historique du débriefing, regardez la série Masters of the Air. Inspirée des récits des aviateurs américains pendant la Seconde Guerre mondiale, elle montre comment ces pilotes, malgré des conditions extrêmes et souvent tragiques, ne manquaient jamais de débriefer après leurs missions. Ces sessions n’étaient pas simplement des formalités : elles étaient vitales pour adapter les tactiques, sauver des vies et améliorer la coordination des équipes.
