Débutant

[Rétro] C’est l’histoire d’une US…

Quand je dois animer une rétro et que j’ai envie de varier un peu le format, je pars en chasse sur la toile. J’ai alors le loisir de découvrir plein d’ateliers différents, tous plus intéressants les uns que les autres ! Il y en a donc beaucoup que j’ai envie d’essayer mais qui, soit par leur format, soit par ce qu’ils cherchent à faire émerger, ne sont pas forcément adaptés à ma situation. Alors, je les garde sous le coude en attendant le moment propice. Celui que je vais vous présenter dans cet article est un format que je garde en réserve depuis un sacré bout de temps et que j’ai enfin pu mettre en œuvre ! Il se base sur une US pour mettre en relief les améliorations à apporter dans l’équipe.

Contexte

J’ai récupéré cette équipe depuis quelques semaines et le principal problème est le manque de confiance (bidirectionnel) qui existe entre le PO et l’équipe de dev. J’ai donc commencé à travailler sur ce sujet, notamment d’un point du vue management visuel afin de donner un maximum de visibilité dans tout ce qui est fait et pour faire en sorte de réaligner tout ce beau monde. Cela s’améliore donc petit à petit.

Mais une situation se reproduit malgré tout trop souvent : le PO se plaint que l’équipe de dev n’avance pas sur une US tandis que l’équipe de dev se plaint de la qualité de l’US. Bref, chacun se renvoie la balle !

En me baladant sur le site FunRetrospectives, je suis tombée sur cette rétro, qui se base sur l’analyse d’une US pour tenter de s’améliorer. Elle m’a semblé parfaitement adaptée à la situation : les US sont souvent un sujet de discorde qui reflète bien les difficultés de l’équipe.

Déroulement

Le déroulement de cette rétro est assez simple et peut se résumer en 4 étapes :

Etape 1 (10’) : Sélectionner une US représentative du Sprint
Etape 2 (10’) : Identifier les éléments marquants de la vie de cette US
Etape 3 (30’) : Identifier les points positifs (à garder) et négatifs (à arrêter ou améliorer) de ces éléments
Etape 4 (30’) : Regrouper ces informations par thèmes et trouver des actions à réaliser

Note : Je n’avais pour ma part qu’une heure et demie pour faire cette rétro. Les durées sont notées à titre indicatif et peuvent bien sûr être adaptées à votre situation 😉

Matériel

Voici ce dont vous aurez besoin :

  • Un moyen d’afficher l’US (soit sur un écran, soit sur un papier)
  • Un support (type PaperBoard) pour afficher les étapes de vie de l’US.
  • Des feutres et des post-its avec 3 couleurs différentes si possibles
  • De la bonne humeur et la volonté de s’améliorer !

Préparation

Sélection de l’US

À la fin du Sprint, j’ai demandé aux personnes de l’équipe s’il y avait une US représentative de tout ce dont elles se plaignaient depuis quelques temps. Préalablement, j’avais pris soin de lister ces cas, car il arrive souvent que les gens oublient le sujet de leurs râleries lorsque l’on commence à les impliquer 😉 Fort heureusement, je n’en ai pas eu besoin : la réponse a été immédiate et tout le monde a été unanime sur l’US à sélectionner !

Logistique

J’ai ensuite cherché un moyen pour que tout le monde se souvienne de l’US lors de la rétro. L’option la plus simple était d’afficher l’US dans JIRA sur un écran en salle de réunion pour que tout le monde puisse bien la visualiser et se la remémorer. Mais, trouver une salle avec un écran n’est pas si facile, et souvent l’écran ne fonctionne pas !

Pour pallier à ce potentiel problème, j’ai également recopié l’US sur une feuille A3 :

Je n’ai pas trouvé le résultat très satisfaisant du fait du nombre (un peu trop) conséquent de règles à recopier. Autant vous dire qu’elles sont assez illisibles ! J’ai donc prié le Dieu des Réunions de me donner une salle avec un écran fonctionnel (je suis surtout allée vérifier avant la rétro) et mon vœu a été exaucé !

J’ai également réalisé sur une feuille de PaperBoard un magnifique support représentant le chemin de l’US :

Tout est donc prêt pour commencer cette rétro !! Voyons maintenant comment elle s’est déroulée.

En pratique

La vie de l’US

J’ai d’abord pris le temps avec l’équipe de bien relire l’US. Nous avons un peu re-discuté de la façon dont elle s’était déroulée pour ceux qui n’avaient pas eu à intervenir dessus et qui connaissaient moins les détails.

Ensuite, j’ai demandé à l’équipe de noter les événements marquants de l’US, cela va de la rédaction de l’US à son estimation, sa réalisation, ses tests, sa validation, les bugs remontés… Bref, toute sa vie est passée au crible !

Ces événements ont été affichés sur la ligne de vie de l’US :

Là, j’ai pu voir que l’US avait été bien choisie car de nombreuses et surtout diverses choses se sont déroulées : plusieurs devs y sont passés, il y a eu des blocages (techniques et fonctionnels), des bidouilles, une validation tardive… Bref, beaucoup d’éléments ! Cette rétro ne suffira sans doute pas à traiter tous les points à améliorer mais au moins ils seront visibles.

Analyse de l’US

Dans cette étape, tout le monde a vraiment été mis à contribution : ceux qui ont vécu l’US et donc qui ont vécu les problèmes. Et ceux qui l’ont vécue de plus loin avec un certain recul (et donc un regard différent) mais qui sont forcément aussi impactés.

J’ai demandé à l’équipe de noter sur les post-its verts le positif et sur les post-its oranges le négatif. Voici le résultat :

Je trouve ce résultat assez impressionnant ! Et je note plusieurs choses :

  • Malgré les difficultés rencontrées dans cette US, il y a beaucoup de positif aussi car l’équipe est restée soudée. Il m’a semblé utile lors du débrief de faire remarquer que la cohésion d’équipe était là malgré tout 😉
  • Les difficultés portent aussi bien sur la partie PO (rédaction des US, validation…) que la partie dev, ce qui a poussé les 2 parties à prendre du recul.
  • Beaucoup de post-its ont été générés et cela a pris du temps de les présenter. Une limite pourrait potentiellement être mise sur le nombre de post-its à générer pour permettre à l’équipe de se concentrer sur le principal.

Les actions

Concernant les actions à prendre, cela s’est fait de manière assez classique. Les difficultés ont été regroupées par thèmes, un dot voting a été effectué pour choisir les thèmes à résoudre. Après analyse de ces thèmes pour déceler l’origine du problème, des actions ont été prises. La priorité a été mise sur :

  • La rédaction des US pour partir sur de bonnes bases,
  • L’aspect organisationnel.

Débrief

J’ai beaucoup apprécié cette rétro car elle collait parfaitement à ma problématique et a généré plus que ce que j’attendais : chacun a pu voir ce qui se passe chez l’autre et les problèmes de communication ont été mis en exergue.
Le PO a ainsi pu se rendre compte des difficultés engendrées côté dev quand l’US n’est pas de bonne qualité au départ. Les devs ont aussi réalisé que certains de leurs problèmes auraient pu être résolus s’ils en avaient en fait parlé avec le PO.

Le plus difficile pour moi a été de réussir au début à impliquer les devs qui ne se sentaient pas concernés par cette US. Heureusement, ils se sont vite rendus compte que les problématiques rencontrées étaient aussi les leurs et tout le monde a finalement participé.

Conclusion

Cette rétro exige peu de préparation et peu de matériel. Elle permet d’unir toute l’équipe sur un sujet commun et évite les désagréments du type “je ne me souviens plus de ce qui s’est passé dans le sprint” !
En prenant conscience de ce que chacun a vécu pendant cette US, l’équipe a pu prendre du recul et arrêter de rejeter la faute sur l’autre.

Il serait également intéressant d’essayer ce type de rétro sur une équipe avec moins de problématiques, peut-être y aurait-il moins de contenu généré mais tout autant d’effets bénéfiques ?

J’ai également trouvé d’autres types de rétros qui utilisent les US sur Retromat :

J’ai hâte de les tester !

© SOAT
Toute reproduction est interdite sans autorisation de l’auteur.

Nombre de vue : 628

AJOUTER UN COMMENTAIRE