L’équipe dans laquelle je suis a adopté le cadre SCRUM pour son mode de fonctionnement. Les rituels classiques tels que la réunion du matin et l’indéboulonnable trio revue/rétrospective/planning est appliqué scrupuleusement.

Les Sprints de deux semaines s’enchaînent. Si le format de la rétrospective peut varier en fonction de la situation (c’est même hautement conseillé), celui de la revue et du planning sont plutôt standards. Pour éviter de tomber dans une routine qui lasserait les participants, je me suis appuyé sur la Faciliation Graphique pour les dynamiser un peu.

Ambiance feutrée

La revue d’un sprint, c’est souvent une démonstration auprès du Product Owner suivie d’un bilan du travail qui a été accompli ainsi que les obstacles/frottements rencontrés. Notre Sprint 13 avait beaucoup (trop) de story démarrées en plus d’être non priorisées ou non chiffrées. Comment représenter graphiquement cette accumulation de travail non terminé ? J’ai eu l’idée de dessiner une livraison par avion :

  • les story finies et livrées sur une ile à la taille restreinte,
  • les story non priorisées en cours de réalisation en plein ciel,
  • une non chiffrée juste balancée depuis l’avion (car “prise en compte à la dernière minute”).

Revue du Sprint

Représenter ce Sprint de cette manière :

  • interpelait chaque membre de l’équipe
  • pouvait servir de terreau pour la rétrospective. Le problème était visible, compris par chacun, l’équipe a décidé d’agir dessus. Du coup la rétrospective a été assez courte mais efficace

Dessein animé

Nous avions plusieurs thèmes et le responsable de l’équipe devait prioriser selon la valeur business recommandée par chaque porteur du thème. J’ai dessiné une place de marché dans laquelle chaque porteur devait présenter les stories prêtes à être engagées et sa préférence en terme de priorité. Le responsable de l’équipe n’avait plus qu’à construire le backlog représenté par un “panier”.

Planning du Sprint

L’utilisation de la facilitation graphique dans ce contexte-là n’avait pour but que de changer la forme et non le fond (qui reste une priorisation d’un backlog), afin de le rendre un peu plus vivant. Les porteurs devaient bien préparer le “pitch” de chaque story afin que l’ensemble de l’équipe comprenne bien son enjeu.

Revenons au Sprint 13 dans lequel l’équipe s’était un peu éparpillée, la décision issue de la rétrospective a été de se focaliser sur un plus petit nombre de story. Pour le planning du Sprint 14, l’objectif de l’équipe devait être écrit dans un soleil situé à l’horizon, entre deux montagnes et les story priorisées sur la route qui mène droit à cet objectif.

Planning du Sprint

Alors, dessiner c’est gagné ?

À la manière d’un coach, le facilitateur doit veiller à ne pas introduire de biais afin de ne pas influencer la direction que l’équipe souhaite prendre. Pour la rétrospective ce sprint 13, nous étions tous conscients qu’elle serait fermée. L’important pour nous était de régler un problème majeur dans l’immédiat. Nous avons peut-être raté certains sujets mais s’ils étaient importants, ils seraient revenus par la grande porte à la rétro suivante. Les effets furent intéressants. En n’ayant que 3 stories, nous avons profité pour attaquer (et livrer !) des petites taches de refactoring legacy.

Encore une fois, être bon au dessin n’est pas un pré-requis. Il faut juste avoir les idées claires, ne pas hésiter à s’entraîner et demander l’avis à son entourage. Personne ne vous en voudra pour avoir raté certains pictogrammes, l’important est que le dessin ait un sens et qu’il aide l’équipe à décider.