Mon jeu Agile préféré …

Je suis joueur, ce n’est pas une nouvelle pour ceux qui me connaissent, et je suis convaincu des bienfaits et de l’efficacité de l’apprentissage par les jeux. Tellement convaincu que j’en ai fait un sujet de présentation que j’ai donné plusieurs fois lors des conférences agiles en 2012 après en avoir fait la primeur à Toulouse en 2011 (Lire : Keynote « Des Jeux Agiles pour Apprendre »).

J’aime tous les jeux d’apprentissages Agiles, et si après avoir beaucoup pratiqué le XP Game à l’origine car je lui trouvait beaucoup de vertus … et je lui en trouve encore beaucoup, j’avoue que mon jeu préféré est depuis 2 ans le génial « Artistes et Spécifieurs », que je ne pratique plus vraiment dans sa version d’origine … et je vais vous expliquer pourquoi !
J’ai découvert Artistes & Spécifieurs en 2008 lors de la regrettée conférence « Agile Valence ». Le jeu a été créé par Alistair Cockburn et c’est Géry Derbier (lui aussi un vrai joueur et qui connait bien Allistair) qui animait la session.Le jeu consiste à faire réaliser par des Artistes – en 10 minutes – un dessin visible par les Spécifieurs dans une autre pièce. La difficulté réside dans le fait que les Artistes et les Spécifieurs n’ont pas le droit de se parler et que les Spécifieurs n’ont pas le droit de dessiner.

J’ai tout de suite apprécié le jeu car je le trouvais particulièrement simple à mettre en oeuvre, sans matériel spécifique (qui n’a pas des feuilles – même de récupération – et des stylos à proximité), très dynamique du fait que les spécifieurs vont et viennent et même avec un peu de stress bénéfique pour les artistes (donc un bon moyen pour retenir les apprentissages, même si je n’avais pas identifié à l’époque la nécessité de créer une émotion pour ancrer le savoir).

Tels que présentés par Allistair, les objectifs principaux de ce jeu sont :

• Faire l’expérience de l’incommunicabilité au sein d’une équipe
• Comprendre que l’éloignement fait mal (Préférer la colocation des équipes)
• L’intérêt de la pratique de la rétrospective
• La communication orale a ses limites

Aujourd’hui je pratique le jeu dans une version identique sur le plan de la mise en œuvre, mais je l’utilise beaucoup plus pour expliquer les mécanismes de Scrum et plus généralement les pratiques de gestion de projet Agile.

La première session se déroule sur 10 minutes sans consigne particulière ce qui fait que les participants rencontrent beaucoup de problèmes et produisent un résultat de mauvaise qualité, après un débriefing par équipe sous forme de rétrospective, nous réalisons un débriefing en commun.

Sur chacun des problèmes évoqués, j’en profite alors pour proposer des pratiques agiles qui pourraient améliorer la situation, vous trouverez ci-dessous une liste des problèmes généralement rencontrés et la manière dont je les lie à l’agilité.

Spécifications Imprécises : Collaboration

Souvent les Artistes ont eu du mal à bien comprendre les spécifications écrites par les spécifieurs. Les solutions vont de « Il faut qu’ils écrivent mieux car c’est illisble » à « Nous allons définir un langage commun pour se comprendre » (Non je n’ai pas dit UML 🙂

C’est donc l’occasion d’insister sur l’aspect « collaboratif » de l’agilité en proposant la technique dite du « Client Embarqué » (tiens de l’XP). Plutôt que de travailler sur une amélioration des spécifications écrites, il est préférable d’avoir un Spécifieur en permanence dans la pièce des Artistes pour voir ce qu’ils font et compléter  les spécifications en cas de divergence constatée.

Délai d’arrivée des spécifications : Découpage du besoin en Story – Itération ou Flux

Les premier éléments de spécification arrivent généralement au bout de 6 à 7 minutes (voir beaucoup plus tard) car les Spécifieurs essayent de tout spécifier avant d’aller voir les Artistes (souvent les Spécifieurs croient qu’ils ont 10 minutes seulement pour écrire les spécifications !!). Les Artistes sont alors submergées par les Spécifications à réaliser dans un délai très court (quelques minutes) et c’est la panique totale.

Les solutions identifiées consistent généralement à travailler forme par forme, soit un découpage en Story du besoin initial qui s’y prête tout particulièrement puisque le produit à réaliser est un ensemble de formes géométriques indépendantes. Cette approche est plus proche du Kanban (pilotage du Flux avec un WIP de 1) mais j’avoue utiliser plus souvent le terme « Itération » avec une réalisation séquentielle que je recommande avec Scrum.

Client insatisfait : Valeur Métier et Définition des priorités

Durant ce jeu, je joue le rôle du client (et du facilitateur du jeu) et lors de la présentation des résultats je râle car je ne suis pas content de ne pas avoir telle ou telle forme. Souvent ce problème est totalement oublié par les participants – il y en a tellement – alors que c’est crucial car j’explique que je garde mes M&Ms et que je ne paye aucune équipe – Un peu de frustration des joueurs ne fait jamais de mal 🙂

Bien entendu, j’en profite pour expliquer le concept d’ordonnancement des travaux à faire et la nécessité de demander son avis au client pour savoir ce qui lui apporte le plus de valeur afin de commencer par cela.

Durée trop courte : Approche incrémentale

La durée de 10 minutes revient souvent dans les problèmes évoqués et comme solution les équipes réclament plus de temps. C’est ce que j’appelle l’effet « Élastique du Cycle en V » qui tire vers l’arrière car dès que l’on donne un périmètre et une durée aux participants, ils sont persuadés qu’il faudra tout faire dans le temps imparti, même si ce n’est pas possible et même si ce n’est pas ce qu’attend le client (et qui était explicitement affiché tout au long de l’exercice). D’ailleurs plusieurs participants indiquent qu’ils avaient réalisé que ce n’était pas possible avant la fin des 10 minutes … et lorsque je demande ce qu’il ont fait … ils répondent « Ben rien, on a essayé quand même ! »

J’en profite alors pour expliquer les bénéfices de l’approche incrémentale qui consiste à avoir un produit fonctionnel en permanence. La solution consiste à reporter sur une feuille unique les formes au fur et à mesure qu’elles ont été validées sur un brouillon par le Spécifieur présent dans la salle. Le produit final s’enrichit par incrément et est disponible en permanence, ce qui annule totalement le stress lié au temps qui s’écoule (et que j’annonce à haute voix). Souvent j’entends les équipes dirent lors de l’itération suivante « Il ne nous reste pas assez de temps pour finir, alors on s’arrête là pour cette itération », YEAHHHH !!!

Nombreux Défauts : Planification Agile

La plupart des réalisations sont refusées par le client car elles comportent de nombreux défauts. Souvent le « bug de la fin » est très visible (la forme la pire), car c’est la forme qui a été ajouté dans les dernières secondes suivant le principe du « plus il y en a mieux c’est, même si c’est faux » qui est très présent chez les Artistes. Bien souvent ce problème n’est pas identifié puisque les équipes considèrent qu’elles ont fait de leur mieux en 10 minutes, alors ce n’est pas de leur faute si le produit final est tout faux et refusé par le client … incroyable mais véridique !

Lorsque je demande aux équipes le temps qu’il leur faudrait pour reprendre les défauts et produire un résultat acceptable, aucune d’entre elles ne se prononce … qui n’a pas entendu un développeur dire « Mais comment veux-tu que j’estime le temps de correction d’un bug ? ». C’est le moment pour expliquer la faiblesse de la planification traditionnelle (ce sont souvent les tests à la fin qui font exploser le planning) et l’avantage de la planification Agile. En effet si au bout de 10 minutes je dispose d’un incrément de produit sans défaut et si j’estime son effort de réalisation, puis relativement l’effort nécessaire pour faire les autres formes (disons en points), j’obtiens un indicateur fiable (que j’appellerais vélocité par exemple) qui me permet d’évaluer le temps nécessaire pour finir le projet (en nombre de sprint de 10 minutes). Après la question est de savoir si j’ai le budget pour finir mon projet, mais cela est une autre histoire 🙂

Conclusion

En résumé, Artistes et Spécifieurs me permet d’aborder des aspects aussi variés que la collaboration, le découpage du besoin en story, la valeur métier, la définition des priorités, l’approche itérative et incrémentale et la planification Agile … pas mal pour un petit jeu simple qui se joue en 1 bonne heure 🙂

Je dois avoir jouer A&S au moins une 50aine de fois maintenant, avec des Présidents de sociétés, des Directeurs, des personnes du métier/marketing/business, des développeurs/testeurs/architectes et des étudiants … et toujours avec la même efficacité, je ne m’en lasse pas 🙂