Birdie-Birdie pour expérimenter l’agilité à distance

En tant que formateur Agile-Scrum, j’utilisais régulièrement le jeu BIRDIE-BIRDIE au cours de mes sessions de formations.

Ce jeu, inventé par Alan Cyment, a pour objectif de découvrir l’agilité et SCRUM par la pratique. Les participants réalisent de manière itérative un jouet en LEGO ayant pour apparence un oiseau préhistorique.

“Si vous souhaitez en savoir plus sur ce jeu, je vous encourage à consulter la description du jeu original. N’hésitez pas non plus à nous contacter directement, nous nous ferons un plaisir de répondre à vos questions.”

Seulement voilà, avec la situation sanitaire actuelle, l’utilisation de LEGO n’est plus vraiment une option. Mais alors quelle alternative trouver pour permettre aux participants de construire simplement un produit de manière collaborative dans un monde virtuel ?

L’idée m’a été soufflée par mon collègue Jean Dupuis (Coach Agile et Directeur chez Zenika Grenoble), pourquoi ne pas utiliser des sets de TANGRAM à la place des LEGOS !

Des TAN-quoi ? C’est à peu près la réaction que j’ai eue lorsque Jean m’a parlé de TANGRAM pour la première fois. Il faut dire qu’il est né au XXème siècle 😉 Mais alors de quoi parle-t-on ?

Le Tangram est un jeu de puzzle dont le but est de construire une forme donnée à partir d’un ensemble de pièces provenant de la dissection d’un carré composé en 7 pièces élémentaires (cf. exemple ci-dessous) :

Les règles sont simples : on utilise toujours la totalité des pièces qui doivent être posées à plat et ne pas se superposer.

L’idée a depuis fait du chemin et nous avons adapté le jeu Birdie Birdie en remplaçant les LEGOS par des sets de Tangram, le tout jouable à distance sur un support MURAL (https://www.mural.co/).

Objectif

T-Birdie 4 Scrum est donc une alternative au Birdie Birdie. Il permet de faire découvrir l’agilité et Scrum aux participants avec les mêmes apports que le jeu original, le tout jouable à distance.

Le jeu est dimensionné pour 2 équipes maximum composées de 4-5 personnes chacune. Bien qu’il soit possible d’assurer seul l’animation, je vous conseille d’avoir un animateur pour chaque équipe.

Environnement du jeu : 

• MURAL comme espace de travail collaboratif virtuel. Nous avons créé un template pour le jeu que vous pouvez récupérer ici. 
• Un outil de visio (Zoom, Discord, Teams …) permettant de créer des sous-groupes.

Afin de faciliter le démarrage le jour J, organisez en amont de la session un webinar de préparation avec les participants (45 min environ). Ce webinar est l’occasion de s’assurer du bon fonctionnement des outils et permettre aux personnes de se familiariser avec leurs utilisations.

Contexte / Immersion

Le contexte est très proche du jeu d’origine. En tant qu’animateur, je me présente comme étant le président de la société MonJoliTangram dont le projet est de lancer le prochain produit. Celui-ci est un modèle de Tangram représentant un super oiseau préhistorique ayant pour nom de code : Ptérodactyle.

Les participants vont jouer les heureux membres de l’équipe R&D et vont devoir réaliser ce modèle de Tangram en 4 itérations successives.

L’équipe ne le sait pas encore, mais elle n’aura que 3 itérations au lieu de 4 pour réaliser le modèle (la concurrence sortira entre temps un nouveau produit sur le marché).

Afin de mieux suivre l’avancement du projet, j’impose l’utilisation d’un tableau de suivi d’itération composé de 3 colonnes “A faire”, “En cours”, “Terminé”.

Organisation et règles du jeu

La durée totale du jeu est d’environ 2 h. Il est possible de le jouer en 1 h 30 mais je préfère garder plus de temps pour assurer la prise en main des outils par le groupe et réaliser un debrief approfondi.

Le timing de la session est découpé de la manière suivante :

• Introduction (présentation des participants, du contexte et des règles du jeu) : 20 mn
• Constitution des équipes et warm up : 20 min
• Présentation du backlog : 10 mn
• Réalisation des 3 itérations : 45 min (3 x 15)
• Débrief : 20 min

La construction du modèle est réalisée au cours d’itérations de 15 minutes organisées de la manière suivante :

• Présentation des User Stories + Planification : 5 min
• Réalisation et livraison : 7 min
• Revue : 2 min
• Rétrospective : 1 min

Les User Stories (US) de l’itération sont présentées par mes soins en préambule de l’étape de planification.

Le résultat de chaque itération doit être livré (copier-coller) par l’équipe dans l’espace de livraison dédié.

Pour des raisons économiques, le modèle doit être composé de 8 sets (carrés) de Tangram au maximum. La totalité des pièces de chaque nouveau set de Tangram doit être utilisée.

Warm up !

Une fois les équipes constituées et avant de démarrer le jeu, je propose aux participants de se familiariser avec la manipulation et la rotation des pièces de Tangram sous Mural. Ils vont pour cela réaliser chacun un joli lapin à l’aide d’un set de Tangram.

Après avoir écrit leur prénom sur l’un des post-it de couleur mis à leur disposition. Chacun sélectionne l’ensemble des pièces du Tangram (utilisation de la sélection multiple) dont la couleur correspond à celle du post-it choisi. Ce set est ensuite copier-coller à proximité de celui-ci.

Vient ensuite l’explication sur la manière de déplacer et faire pivoter un élément. Vous trouverez l’explication complète à l’adresse suivante : https://support.mural.co/en/articles/2113724-rotate-elements

Attention : la rotation d’élément sur Mural est loin d’être intuitive et pourra être source de frustration pour les participants lors des premiers usages. Le parallèle avec la situation ou l’équipe ne maîtrise pas certains outils, langages et/ou frameworks lors du démarrage d’un projet est un point intéressant à aborder lors du debrief.

Je laisse ensuite 10 minutes maximum aux participants pour faire preuve de créativité et réaliser leur lapin avec l’ensemble des éléments du Tangram.

Démarrage et présentation du backlog

Maintenant que les participants sont (plus ou moins) à l’aise avec la manipulation des Tangrams, j’annonce que je vais jouer le rôle de responsable de ce nouveau produit. En tant que tel, je suis le principal décideur sur les priorités et serai impliqué en étant disponible pour répondre aux questions et vérifier la conformité de la réalisation avec le besoin.

Les US (User Stories) du jeu d’origine ont été revues pour coller au contexte. Celles-ci sont toujours réparties sur 3 itérations. Vous pouvez les consulter en accédant à la section Product Backlog du Mural.

Selon les recommandations du Birdie-Birdie, j’affiche uniquement la liste des éléments prévus pour la 1^ère itération. La réalisation de l’ensemble de ces éléments est difficilement réalisable sur une itération de 7 minutes. Un décalage va donc se créer entre mes souhaits et le réalisé. Se décalage va forcer les participants à dialoguer avec le responsable produit pour définir les priorités sur les itérations à venir entre le non réalisé et les nouvelles US présentées.

Planification d’itérations

Après avoir présenté succinctement chacune des US de la première itération, je demande à l’équipe ce qu’elle est en mesure de terminer. Je les incite alors à me questionner pour s’assurer de la bonne compréhension des éléments et expliciter certains critères d’acceptance flous et/ou cachés.

Pour rappel, le Birdie-Birdie impose la règle suivante : 

« Les User Story disposent de critères d’acceptances incomplets dont certains ne sont pas forcément intuitifs (par exemple : le bec doit être ouvert). Et seul le président dispose de ces informations complémentaires. Il a des besoins définis mais ne sais pas exactement ce qu’il veut. »

Vous trouverez ci-dessous la liste des critères cachés pour chaque US qui ont également été adaptés.

Une fois le périmètre éclairci, l’équipe définit l’objectif à atteindre et la manière dont elle pense s’organiser pour y parvenir et tout cela dans les 3 minutes imparties.

Réalisation d’une itération

Je n’interviens quasiment pas au cours des itérations, uniquement sur demande et lorsque les participants en expriment le besoin. Par exemple pour répondre à des questions fonctionnelles ou vérifier si la réalisation est conforme au besoin exprimé (ce qui arrive rarement lors de la première itération).

J’insiste en revanche pour que l’équipe mette à jour le tableau de suivi de l’itération afin que je puisse avoir de la visibilité sur l’avancement de l’itération.

Revue

Selon les instructions originales :

« Une fois la réalisation terminée, le facilitateur passera voir le résultat de chaque équipe et acceptera ou refusera les User Story (sur la base de la totalité des Critères d’Acceptation).

Il répondra uniquement si un équipier lui demande explicitement ‘Pourquoi la Story est rejetée ?’ »

A ces règles s’ajoute la contrainte de « déploiement ». Une Story n’est acceptée que si elle a été copiée-collée dans l’espace de livraison dédié.

En tant que responsable du produit un brin autoritaire, je refuse généralement de nombreuses stories sur la base de l’ensemble de ces critères. L’objectif étant de « bousculer » l’équipe pour que celle-ci pose plus de questions sur les critères d’acceptance et me sollicite plus régulièrement au cours des prochaines itérations.

Rétrospective

Je n’impose pas de format particulier pour la rétrospective. Je demande juste à l’équipe de réfléchir sur ce qui a bien fonctionné, moins bien fonctionné et la manière dont elle pourrait s’améliorer lors des prochaines itérations.

Fin avant l’heure

Un point d’apprentissage que je trouve particulièrement intéressant dans le jeu Birdie Birdie arrive quelques minutes après le début de la troisième itération. C’est le moment que je choisis pour annoncer un peu paniqué qu’un concurrent va commercialiser dans quelques jours un modèle identique au nôtre et qu’il faut absolument sortir le produit à la fin de cette itération.

Les participants comprennent alors tout l’intérêt d’une approche empirique dont les éléments à réaliser sont priorisés par la valeur.

Debrief 

A l’issue des trois itérations et avant de débriefer avec les participants, je leur demande s’ils sont satisfaits du résultat et si le modèle créé ressemble à un ptérodactyle.
La réponse au deuxième point étant souvent non, c’est pour moi l’occasion d’évoquer le fait qu’un produit n’est pas qu’une somme d’US… Il faut lui associer une vision : personne n’arrive à faire un ptérodactyle qui ressemble à un ptérodactyle sans s’être accordé au préalable sur ce qui caractérise l’animal préhistorique… Sans ce travail de vision, le résultat obtenu se rapproche alors plus souvent d’une poule ou d’une autruche 😊.

Ce que j’adore avec ce jeu, c’est qu’il permet de découvrir de nombreux concepts. Je profite donc du debrief pour aborder les points suivants avec les participants :

• Avantage d’une approche itérative / empirique piloté par la valeur 

• Importance de communiquer directement et continuellement avec le PO :
  • lever au plus tôt les ambiguïtés sur le besoin exprimé
  • vérifier rapidement l’adéquation entre le besoin et le réalisé
  • réagir et s’adapter rapidement en cas de changement ou d’imprévus

• Intérêt d’intégrer, vérifier et déployer en continue : si chacun fait son US de son côté et qu’on intègre en dernière minute alors on a souvent des problèmes…

• Principe et efficacité d’un processus d’amélioration continue

• Efficacité de l’auto-organisation et identification des critères permettant de la faire émerger avec succès au sein de l’équipe (communication, droit à l’erreur…)

Je trouve également intéressant de faire réfléchir les participants aux impacts de la distance sur la collaboration et la communication.

Voici quelques exemples de questions qui vous permettront d’engager le débat : 

• Quels ont été les impacts de la distance sur votre manière d’interagir et de communiquer entre vous ? Et avec le PO ?
• Qu’est-ce qui aurait été différent dans votre manière de collaborer si vous aviez pu réaliser cette expérience en physique ?
• Qu’aurait on pu faire différemment pour améliorer la communication ?

Pour conclure …

Cette adaptation permet de faire les mêmes découvertes que le jeu original, le tout avec la même efficacité. Je trouve le ratio valeur ajoutée / temps investi top, mais attention toutefois à ne pas négliger la montée en compétence sur la prise en main des outils notamment sur la manipulation des éléments de Tangram.

Si vous souhaitez en savoir plus ou nous faire part de votre retour d’expérience n’hésitez pas à nous contacter, nous serons ravis d’échanger avec vous sur ce jeu et à vous aider à l’animer.

Découvrez toutes nos formations Agilité