Jeune padawan dans le coaching d'équipe, la rétrospective de Sprint est un exercice que j'appréhende souvent car son format doit pouvoir s'adapter à la situation passée.

Un Sprint passé fut en échec car deux stories sur trois ne furent pas terminées. Le format de la timeline aurait pu être utilisé pour avoir la composante temporelle et trouver les causes racines mais je souhaitais que l'équipe voit l'accumulation des problèmes rencontrés au cours de l'itération.
Il était mercredi soir, le lendemain avait lieu la rétro. Autant dire que cela commençait à sentir le roussi.

Dans le RER, je lisais l'adaptation en manga du roman "Le sommet des Dieux" (merci JP pour le prêt) - roman qui rappelle furieusement certains passages de Premier de cordée de Roger Frison Roche. Outre la beauté des paysages de montagnes retranscrits à travers le crayon de Taniguchi, le récit est également d'une fluidité exemplaire lors des scènes d'escalade. C'est après une "grimpette" qui finit mal que j'ai eu une idée sur le format de rétro :

  • [1 min] Former des groupes de 3 ou 4 personnes
  • [1 min] Chaque groupe prend un postIt géant et 1 feutre
  • [10 min] Chaque groupe trace une courbe de dénivelé (sachant que la courbe idéale est plate).
    • L'axe horizontal représente le temps (l'itération),
    • L'axe vertical représente la difficulté ressentie des obstacles rencontrés.
  • [5 min] Chaque groupe explique sa courbe
  • [10 min] Sur un tableau blanc, l'équipe va extraire les sujets de discussions et voter (2, 3 ou plus selon les disponibilités)
  • [60 minutes] Discussions autour des sujets votés par l'équipe

Jeudi matin, j'ai proposé de diviser l'équipe en deux groupes et d'appliquer le format ci-dessus. Nous avons obtenu des résultats assez homogènes (par souci de compacité de l'article, un seul graphe est affiché ici) :

Les premiers sommets correspondent aux problèmes rencontrés sur deux stories non validées. En effet, elles comportaient des hypothèses fonctionnelles qui n'étaient pas encore confirmées par le client alors que nous les avions engagées sur le Sprint. Nous avons dû relancer (et patienter) avant de pouvoir poursuivre leur développement.

Ensuite le graphe a surtout mis en évidence l'accumulation des problèmes en fin de Sprint ainsi que leur non-résolution :

  • Beaucoup de réunions impliquant la présence de l'expert fonctionnel furent programmées en fin de Sprint. Ce dernier a été fortement ralenti dans ses tâches de validation des deux stories en question,
  • L'équipe a consommé beaucoup d'énergie dans la réparation des environnements de recette et de benchmarks. L'expert fonctionnel a dû patienter que la plateforme de recette fonctionne pour exécuter certains cas de tests.

Nous avons engagé les actions suivantes :

  • Communiquer au client que l'expert fonctionnel n'accepte plus les réunions sur les deux derniers jours du Sprint afin qu'il puisse valider les stories "plus sereinement",
  • Rajouter un statut Non Engageable pour les stories dont le chiffrage se base sur des hypothèses non validées par le client.

En conclusion, ce format est intéressant car il a incité l'équipe à se rappeler de manière chronologique les obstacles rencontrés et à mesurer son ressenti à chaque instant du Sprint. Il est aussi adapté pour des Sprints réussis. En effet, on peut réussir factuellement un Sprint et en avoir "bavé" tout au long de l'itération.