Avec mon confrère Hervé Tran nous nous sommes lancé un défi et avons détourné un classique des jeux agiles : Le Marsmallow Challenge !
Nous l’avons décliné « à l’échelle », avec l’intention de faire remonter des comportements et des bonnes pratiques liées aux structures projet de grande taille mais aussi les risques potentiels.

Je vous explique dans cet article les règles, les apprentissages et les surprenantes observations lors de l’animation du jeu.

Marshmallow challenge

Le Marshmallow Challenge fût présenté pour la première fois en 2006 par son créateur Peter Skillman, ingénieur chez Palm, et sa notoriété renforcée en 2010 par le TED de Tom Wujec qui partageait ses conclusions après plusieurs dizaines de tests en atelier.

http://www.youtube.com/watch?v=1p5sBzMtB3Q

Présentation par Peter Skillman

http://www.youtube.com/watch?v=H0_yKBitO8M

TED de Tom Wujec

Pour rappel, le jeu consiste à former des équipes (3 à 6 personnes) qui doivent construire la plus haute tour possible avec 20 spaghettis, 1m de ficelle, 1m de scotch et 1 marshmallow à mettre au sommet. Le tout en 18 minutes.

Le jeu permet d’observer plusieurs choses :

• Les méthodes projets et les différentes résultats (vaut-il mieux faire un long design puis construire, construire et tester directement, faire un petit design puis de la construction… ?)
• Les dynamiques de groupe, de leadership
• Les modèles comportementaux. J’avais joué à une partie organisée par Didier Bourdenet et Franck Baudouin où le jeu était mis en perspective avec la méthode DISC pour étudier les comportements individuels.

Pour avoir d’autres informations sur le jeu, je vous renvoie à cette vidéorègle que j’avais réalisé il y a quelques années.

http://www.youtube.com/watch?v=bFF2N_suSd8

Marshmallow challenge à l’échelle

C’est à l’occasion d’une présentation dans une école que l’idée de mettre le marshmallow challenge à l’échelle nous est venue. Nous devions animer des ateliers pour 80 étudiants et le Marshmallow Challenge nous a semblé adapté, Hervé s’est dit qu’il serait amusant de proposer une version à l’échelle. Nous avons donc imaginé une partie où les joueurs et joueuses devraient connecter leurs tours avec un pont pouvant soutenir un marshmallow.

Étant donné le succès, nous l’avons proposé à Grenoble sous une version un peu différente.

Je vous propose ci-dessous les deux versions.

Éléments communs

Cas d’usage : Parler d’agilité, d’agilité à l’échelle ou de leadership avec un grand groupe, faire du team building tout simplement
Nombre de joueurs : minimum 9, maximum 1356 personnes (plus ou moins)
Durée : 25mn + debrief
Matériel par équipe (de 3 à 6 joueurs) :

• 25 spaghetti
• 1,5m de ficelle et 1,5m de scotch
• 1 marshmallow blanc à mettre sur la tour et 1 marshmallow par pont entre deux tours

Les règles restent les même que le jeu de base et on ajoute la règle sur les ponts.

Nous avons augmenté les ressources et le temps pour sortir la variable “moyen” de l’équation.

Version avec 2 connexions

C’est la version que nous avons proposé à l’école.

Indication : Vous devez former la plus haute tour possible interconnectée à deux autres tours et reliées à chaque fois par un pont pouvant soutenir un marshmallow, vous avez 25mn.

Chaque équipe doit donc former sa tour avec son marshmallow au sommet mais aussi travailler avec deux autres équipes pour connecter les tours.

Observations :

• Nous avions affaire à des débutants de l’agilité et n’ayant jamais joué le jeu. Les étudiants se sont quasi-exclusivement concentrés sur leur tour ne respectant pas la demande client, valeur du résultat 0.
• Quelques équipes ont réussi à déplacer leur tour pour s’interconnecter (avec un peu de stress) et une seule équipe a réussi le challenge.
  Aucune équipe n’a pensé son architecture sous l’angle de l’interconnection. Cela nous a permit de parler “integration by design” avec une petite ouverture sur le DevOps (qui n’était pas la thématique mais une belle opportunité)
• Les équipes ayant essayé de s’interconnecter ont dû réfléchir au meilleur endroit pour modifier la structure. Des comportements de type rejets de faute sont apparus et nous avons entendu “votre structure ne tiendra pas” ou “comment voulez vous qu’on se connecte avec votre truc ?” qui, face au besoin de réussir et au temps limité, ont laissé place à la co-construction
• J’aime bien demander si les équipes étaient sereines à la livraison. Cette question me permet de mettre en perspective la construction itérative, la prise de risque et la confiance dans le processus. La plupart du temps, seules les équipes ayant monté leur tour petit à petit ou ayant gardé 2 à 3 mn de temps pour s’assurer que la tour tient, finissent sereines.

Au delà de l’apprentissage classique d’un Marshmallow Challenge, ce que je retiens de cette session est qu’elle met en lumière le principe de “l’intégration by design”, une problématique récurrente sur les projets à l’échelle.

On peut dès lors questionner :

• La vision globale partagée
• Le design et la construction pensés à plusieurs
  Lorsque le design n’est pas pensé en multi-équipe, on voit rapidement apparaître des rejets de faute, d’erreur, un manque de confiance inter-équipe
• Le changement de leadership entre ceux qui mènent la construction de la tour et ceux qui mènent la relation avec les autres

Version objectif et auto-organisation

Pour Agile Grenoble, nous avons discuté longtemps avec Hervé car le public est drastiquement différent… il est plein “d’agilistes”  (haaa courreeezzz), une population particulière qui crée des biais dans tous les sens.

Pour rappel, la plupart des jeux agiles sont à destination d’un public en pleine découverte des concepts, des pratiques agiles.

Les agilistes démarrent le jeu en ayant déjà les apprentissages et les comportements “agiles” ce qui, comme vous le devinez, a tendance à mettre au tapis les conclusions prévues.

Il y a aussi beaucoup d’agilistes joueurs, encore une population qui amène plein de biais puisqu’ils décortiquent la mécanique et cherchent à prendre de court les règles avant même de jouer.

Qu’à cela ne tienne, en connaissance de contexte, nous avons poussé notre proposition et nous sommes partis sur un objectif de jeu basé sur la valeur client.

Règles

Formez plusieurs équipes qui vont devoir construire une tour connectée à d’autres tours.

L’animateur.trice représente le client qui va mesurer la valeur des structures.

Valeur =  SOMME(hauteurs des marshmallows aux sommets des tours) +
2 x SOMME(hauteurs des marshmallows posés sur les ponts).

50 points étaient octroyés en plus à l’équipe ayant la tour la plus haute.

Nous avions imaginé plusieurs cas de figures, plusieurs stratégies de joueurs :

• Ceux qui allaient se concentrer sur leur structure afin de maximiser la hauteur et  limiter ainsi le risque lié à l’interconnexion
• Ceux qui tenteraient de connecter leur structure avec d’autres pour augmenter leur gain
• Ceux qui se connecteraient juste à une ou deux autres tours et se concentreraient sur les interconnexion.
  Potentiellement en construisant de tours solides mais basses (peu de points sur la hauteur des tours) mais en tirant un maximum de résultat grâce au multiplicateur des marshmallows sur les ponts (qui valent X2 pour rappel)
• Et le dernier, une structure unique formée par les tours de chaque équipe

Et évidemment c’est la dernière stratégie qui a été lancée par nos agilistes férus “d’individus et d’interactions” poussés à l’extrême.

Nous avions 4 équipes qui se sont vites rassemblées. Les participants ont réuni toutes les tables pour former un plan de travail commun.
Le groupe était mené par 1 ou 2 personnes qui faisaient les propositions d’architecture. Surtout, tous sont partis bille en tête sur de la construction.
2 équipes ont construit ensemble sur le plan (en prod) et 2 équipes ont construit leur tour dans leur coin avant de les intégrer.
Nous sommes vite arrivés à 1 structure co-construite en production.

Le résultat fût une très belle structure qui a tenu et de beaux apprentissages.

Ce que nous avons observés :

• La réunion initiale a principalement poussé le fait de s’interconnecter rapidement et surtout construire rapidement. Il y a eu peu d’échanges orientés “architecture” ou “organisation” et l’équipe a hérité de ça tout au long de la partie.
• 18 participants dont 4-6 actifs et 12-14 en retrait. Et oui, sans réunion sur comment s’organiser ? Impossible de gérer la complémentarité des compétences, comment tirer parti de chaque individu
• Les tours co-construites et intégrées directement étaient plus petites que les tours créées dans leur coin. De là à conclure qu’une pratique agile poussée à l’extrême génère des résultats fiables, solides mais moins ambitieux, il n’y a qu’un pas… que je ne ferai pas
• Les interconnexions construites rapidement ont rendu la structure difficilement évolutive, faut-il y voir un apprentissage sur les architectures monolithique et mettre ça en perspective des pratiques micro-service, feature flipping, feature branching ou feature toggle ?
• Une demande de “pause” pour faire une rétrospective a été demandée par des personnes en retrait et n’ayant pas réussi à s’imposer face aux leaders/constructeurs
• L’équipe a tout de même réussi le challenge puisqu’à la fin nous avions une structure qui a tenu voir que l’on a pu manipuler (avec grande précaution tout de même). Toutes les tours étaient interconnectées entre elles, ce qui est tout de même remarquable.
• Le bonus de 50 points a été totalement oublié au profit du collectif. Je pense que l’ambiance globale a généré une appartenance au groupe complet. Ceci dit, il pourrait être intéressant d’étudier cela sous l’angle du dictat du collectif. Ce n’est peut être pas bon pour l’ambiance mais ça mérite d’être analysé par celles et ceux qui le souhaiteront.
• On a senti une fierté collective à la fin du chronomètre et c’était simplement agréable à voir

Pour information, le total était à peu près à 200 points (les présents me corrigeront) : record à battre !

Conclusion

Quelque soit le mode choisi, je vous invite à avoir un débrief très ouvert en commençant tout simplement par “Que s’est-il passé ?” cela amènera directement le groupe sur l’apprentissage principal, à savoir :

Les points principaux restent :

• Organisation inter-équipe / interactions / communication
• Design “integration by design”, architecture
• Méthode de travail, agilité et limites de l’agilité en fonction du public
• Leadership

Quelque soit la version, j’aime beaucoup cette façon de pratiquer ce jeu qui amène d’autres concepts que l’agilité et s’approche d’une réflexion globale sur les organisations, les comportements, les paradigmes et les pratiques.

Envoyez vos feedbacks si vous le jouez et vos scores qui pourraient enrichir un comparatif