L'effet domino

domino.jpgCe billet est dédié aux participants du jeu Domino4Scrum vendredi dernier à Agile tour Toulouse. En effet (domino), nous n'avons pas eu le temps de faire le débriefing à la fin du jeu, il a fallu laisser la place au projet Aristote.

J'écris donc ce billet pour offrir aux participants un peu de ce que nous aurions pu échanger. Je l'écris aussi en remerciement pour Jeff, le créateur du jeu qui m'a gentiment invité à l'animer avec lui.

Les autres lecteurs peuvent être aussi intéressés car le type de projet simulé avec ce jeu est rarement traité en agilité.

Domino4Scrum est donc inspiré d'un jeu qui a eu son heure de gloire en 1991. Il s'agit de disposer des dominos de façon à provoquer une réaction en chaine spectaculaire qu'on déclenche en faisant tomber le premier domino.

Il existe de nombreux jeux pour apprendre Scrum, comme avec des légos ou du papier ou des pièces de puzzle, dans lesquels on construit sprint après sprint un morceau du résultat final. Avec les dominos, c'est différent, le résultat ce n'est pas des dominos assemblés, c'est le spectacle déclenché par la chute des dominos.

Il s'agit d'un projet à un coup. Du one shot. En effet le résultat obtenu ne sert qu'une fois, on ne le change plus une fois qu'il a servi. Il n'y a donc qu'une seule mise en service qui correspond à la fin du projet.

Ce jeu est une simulation pour apprendre Scrum, dans des conditions (le one shot) qui sont aussi celles de nombreux projets/produits/services en particulier quand il ne s'agit pas que de logiciel, par exemple :

  • pour l'écriture d'un livre (un sujet que je connais bien)
  • pour l'organisation d'un événement (comme une conférence agile ou un mariage)
  • pour l'envoi d'un satellite avec une fusée
  • pour des produits physiques qu'on ne peut plus modifier une fois mis en service, car ils ne contiennent pas de logiciel (il y a encore quelques temps, il y avait de nombreux logiciels embarqués qui n'étaient jamais mis à jour, cela devient moins fréquent)

Scrum est naturel pour développer des produits qui évoluent, mais qu'en est-il pour des projets à un coup ? Si ces projets ont une durée suffisante pour faire plusieurs sprints, l'agilité a son intérêt habituel : permettre de réajuster le développement en s'adaptant à des facteurs impossibles à connaitre dès le début du projet. Ces changements peuvent venir de ceux qui font (ils apprennent) ou de ceux pour qui c'est fait (ils donnent leur feedback).

Donc oui si on ne sait pas tout au début (ce qui est rare à notre époque), l'utilisation de Scrum a du sens pour ce type de projets. La difficulté est de savoir quoi montrer à la fin des sprints intermédiaires pour bien apprendre et avoir le bon feedback.

Revenons à notre jeu Domino4Scrum. Le cadre du jeu présenté au début, c'est de faire 3 sprints. Le déclenchement de l'effet domino est fait à la fin du 3e sprint.

À Agile tour Toulouse, nous avions 6 équipes de 4 personnes. Les parties prenantes étaient constituées des animateurs et de toutes les personnes qui observaient dans la salle.

Nous avions donné aux équipes deux résultats importants pour nous, nous les parties prenantes :

  • la durée de l'effet, en gros le nombre de pièces qui tomberaient lors de la mise en service à la fin du 3e sprint
  • l'effet artistique qui serait produit

Nous avons laissé les PO de chaque équipe choisir l'objet qui serait "dessiné" avec les dominos. Vendredi, pour les 6 groupes, c'était une salamandre, un papillon, une maison, une fleur, un arbre en automne et une vache (à cornes).

À quoi ont servi les sprints 1 et 2 pour les équipes ?

La plupart du temps, elles ont prévu de faire une partie de l'objet, puis une partie plus grosse au sprint 2. Quelle est leur définition de fini pour cette partie ? Dans ce que j'ai vu vendredi, c'était "dominos posés sur la table". Par exemple, la tige pour la fleur et le tronc pour l'arbre. Mais ce n'était pas testé en déclenchant l'effet. On comprend que ça fasse réfléchir parce que si on déclenche, ben après il faut remettre tous les dominos tombés… Tout recommencer. L'équipe de la salamandre s'en est rendu compte 30 secondes avant la fin du 3e sprint.

Pourtant il est possible de tester partiellement pour s'assurer de l'écartement des dominos et pour vérifier quelques configurations de virage sans faire tout tomber. Ce qu'auraient dû faire le papillon (photo du haut) et la maison, car l'effet n'est pas allé bien loin.

maison.png

Les revues de fin de sprint ont bien servi à apprendre sur la capacité de l'équipe ce qui a amené à simplifier le dessin imaginé, compte tenu de ce qui a été réalisé et du temps qui reste. C'est ce qu'a fait l'équipe partie sur l'arbre en automne, qui a remplacé son projet de branches ramifiées par une canopée circulaire ( les feuilles n'étaient pas encore tombées, disons que c'était le début de l'automne). Et c'est elle qui a le mieux réussi sa mise en service.

arbre.png

Oui, tout va tomber ! (c'est un marronnier bien sûr)

Comme c'est souvent le cas dans les jeux prenants pour l'équipe et fortement contraints par le temps, le feedback des parties prenantes a été un peu négligé. Si chaque équipe a bien fait une revue, c'était pour présenter ce qu'elle avait fait et l'objectif du prochain sprint plus que solliciter les avis des parties prenantes.

C'est pourtant au cœur de l'agilité : apprendre sur le produit/service/projet en demandant aux parties prenantes leur feedback. Cela avait été suggéré par la note artistique exposée au début du jeu par les animateurs. Comment savoir ce qui plait aux parties prenantes si on ne le demande pas ?

Domino4Scrum est donc un jeu bien sympa, qui permet d'apprendre à collaborer et à s'adapter en équipe. Ce que nous avons appris tous les deux, c'est que 40' c'est pas assez pour espérer avoir le temps de faire un débrief à la fin.

TiJeff le présentera à Agile Grenoble.