Scrum Tower Game

Le "Jeu de la tour Scrum", ou comment découvrir les concepts de base de l'agilité et de Scrum en s'amusant ...

Introduction

Il y a quelques années, sollicité par une entreprise pour sa transition vers l'agilité (merci à eux), j'ai mis au point un jeu permettant de découvrir quelques aspects de l'agilité, et les concepts de base de Scrum. Baptisé depuis "Scrum Tower Game", j'ai déjà déroulé plusieurs fois cet atelier, qui tient ses objectifs à chaque fois.

Après en avoir parlé au détour d'une bière, je l'ai fait jouer lors d'une soirée agile du CARA à Grenoble, avec des retours intéressants des personnes présentes. 

Lors de la dernière session de Agile Game France, je n'ai pas osé l'amener dans mes valises, mais certaines personnes me l'ont fait regretter, et m'ont motivé à diffuser cet article pour le présenter (1).

La Genèse 

Mon client de l'époque avait insisté pour intercaler un jeu dans le déroulement de la journée de formation. C'est d'ailleurs une bonne idée, ça permet de casser le rythme d'une journée intense. 

L'idée était donc de proposer un jeu permettant de découvrir les concepts de base de Scrum, après une grosse matinée d'introduction à l'agilité, et de présentation des principes de base de Scrum. 

Il y a pas mal d'années, lors d'une formation "Scrum Master", j'avais participé à un atelier qui m'avait pas mal déplu notamment pour un point : le "temps accéléré". Dans cet atelier, nous faisions des itérations "accélérées", de plusieurs minutes. Mais prenons le cas d'une rétrospective : on peut raccourcir le temps pour faire une rétro de 2', mais on ne parle pas plus vite pour autant (à la manière d'un 78 tours, pour les anciens ...). Je voulais donc absolument éviter ce "temps accéléré".

Par ailleurs, je ne suis pas forcément "créatif", surtout lorsque je participe à une formation. Je souhaitais donc éviter de polariser l'attention des participants sur ce qu'ils doivent produire, pour leur permettre de se concentrer sur les rôles, les règles, les principes, etc ...

Et bien sûr, il fallait un côté jeu, un côté plaisant : j'ai ressorti les "Duplo" basiques de mes enfants.

C'est ainsi qu'est né ce jeu, à base de "légo", à une époque où on en parlait pas du tout dans la communauté agile ....

Un jeu "cadré", oui mais ...

Le déroulement de ce jeu est assez contrôlé et guidé, mais cet aspect n'est normalement pas trop ressenti par les participants, et surtout, le fait que ce soit calculé et dimensionné, me permet de faire apparaître des "problèmes", des situations particulières, qui sont alors des occasions pour présenter certains particularités importantes de l'agilité : re-découpage, frustration, renoncement, ...

Rôles 

Les rôles sont répartis parmi les participants, éventuellement en collant aux futurs rôles de chacun pour le projet à venir :

• 1 animateur (rôle que j'assume à chaque fois) : l'idée est de veiller au bon déroulement du jeu, en m'arrangeant pour amener l'équipe dans des situations particulières, et en insistant tout au long du jeu sur les particularités liées à l'agilité
• 1 ScrumMaster (SM) : je lui fournis des feuilles A3 prêtes pour tracer les "Burndown Charts", il prépare le "Scrum Board", et devra s'assurer de l’enchaînement des différentes étapes et cérémonies. Ce rôle est assez léger, en général les personnes sont trop novices, je les assiste pas mal
• 1 Product Owner (PO) : je lui fourni une feuille avec des illustrations de ce qui doit être produit. Je l'incite à répondre aux questions de l'équipe, sans trop en dire ni devancer les informations à fournir. Je lui explique notamment 2 points qui seront importants : la nécessité de redécouper une histoire, et en fin de jeu, le renoncement à la totalité de la tour
• 4 équipiers : ils devront fournir les estimations, en questionnant le PO, puis produire le résultat attendu
• les autres participants sont observateurs et participeront à la rétrospective de l'atelier

On voit / On ne voit pas ...

Ce jeu permet d'appréhender :

• les rôles de Scrum
• la production itérative
• le rythme de Scrum et ses cérémonies
• certaines situations inattendues que l'agilité permet de gérer

Par contre, on ne peut pas tout mettre en oeuvre, et notamment :

• la notion de terminé (du moins très réduite ici)
• l'initiative technique et les choix par l'équipe
• la gestion "humaine" d'une équipe sur le moyen et long terme
• ...

Objectif pour l'équipe

L'objectif pour l'équipe est de produire une tour en légo comme celle-ci :

Les équipiers ont à leur disposition le matériel suivant, avec des Pièces Grandes (PG), des Pièces Moyennes (PM) et des Pièces Petites (PP)  :

La tour est composée de fondations, de 3 étages de couleurs différentes, et d'un sommet:

Le bloc de fondations est composé de 3 PG et 3 PM :

Chaque étage est composé de 6 PM de même couleur (1 couleur par étage) :

Le sommet est composé de 7 PP (dont "l’œil") :

Déroulement

Logistique

On s'organise pour avoir de l'espace devant le Scrum Board et pouvoir y faire les stands-up de chaque jour. L'équipe s'installe sur une table qui servira d'espace de travail "quotidien", et on prévoit un autre espace dit "d'intégration" ou seront déposés les éléments complets.

Démarrage

Le jeu se déroulera en 3 itérations de 3 jours. Il comme donc par la réunion de planification de la première itération, cumulant un peu un "sprint 0". L'équipe découvre l'objectif présenté par le PO, le matériel, et les règles.

Le PO présente les "Histoires" ("'Stories" (2)) initiales du "Carnet de produit" ("Product Backlog") et demande aux équipiers de lui donner des estimations. Pour simplifier le jeu, 1 jour de production pour 1 équipier = 1 pièce de légo posée = 1 point.

Après un échange de questions-réponses entre l'équipe et le PO, on aboutit à ces estimations :

• Fondations : 6 points
• Étages (une seule histoire initialement) : 18 points (3 x 6)
• Sommet : 7 points

Le SM demande alors à l'équipe d'estimer sa vélocité, donc sa capacité de production pour 1 itération. Donc 3 jours à 4 équipiers = 12 points.

L'équipe et le PO doivent alors décider ce qui sera réalisé pendant la première itération. Le premier "problème" apparaît : l'histoire pour les "3 étages" est trop grosse !

Redécoupage

Le SM demande alors au PO s'il serait possible de découper cette histoire. On obtient alors 3 histoires différentes estimées chacune à 6 points : "étage 1", "étage 2", "étage 3".

L'équipe peut alors s'engager pour la première itération sur : les fondations pour 6 points et l'étage 1 pour 6 points, puisque sa vélocité estimée est de 12 points.

On peut alors préparer le Scrum Board avec les post-its pour les histoires, pour chaque tâches (1 tâches = 1 pièce de légo), le Burndown Chart, etc ...

Oui mais .... les aléas ....

C'est alors que j'introduis une élément supplémentaire, une règle "oubliée" : avant de fournir sa production quotidienne, chaque joueur doit lancer ce dé "spécial" :

Et s'il tombe sur la face rouge, la journée ne s'est pas passée comme prévue, il passe son tour et ne produit rien.

Multi-tâches (multi-histoires) ?

Et pour "gagner du temps" (enfin ....), j'incite fortement l'équipe à se répartir le travail en "binôme" pour attaquer en même temps les fondations et l'étage.

Itération 1 : Aïe !

On déroule alors l'itération de façon "classique", en s'appuyant sur les cérémonies de Scrum. Chaque journée commence par un stand-up devant le Scrum Board qui est mis à jour ne fonction de ce qui s'est passé la veille, et de ce qui est prévu pour la journée à venir.

Durant cette itération, je m'assure que chaque "binôme" a au moins un "obstacle" avec le dé, sinon, j'interviens pour forcer la face "rouge" [NDLA : en général, cette intervention néfaste est tout de même bien acceptée par l'équipe qui comprend qu'il y a un objectif pédagogique].

En fin d'itération, si tout s'est déroulé comme prévu (du moins pour moi), aucune des histoires n'est terminée, l'équipe n'a donc rien à montrer .... Je lui laisse donc le soin de faire venir le PO pour le lui dire ... A ce moment-là, souvent, des équipiers essaient de trouver une solution pour tout de même montrer quelque chose, mais la règle est claire : on montre ce qui est terminé ! Donc rien à ce stade du jeu ...

On enchaîne alors sur la rétrospective pour évoquer ce qui s'est passé, et évidemment, le fait que d'attaquer plusieurs histoires en parallèle n'est pas un bon choix. L'équipe devrait alors décider, pour l'itération suivante, de mettre les efforts pour finir les histoires commencées, puis de travailler plus collectivement sur les histoires suivantes.

On fait également le bilan concernant la vélocité qui est en générale mesurée à 9 ou 10, et souvent revue à la baisse à 10.

En général, l'équipe attaque cette première itération dans une certaine euphorie ludique, mais la finit dans une ambiance plus morose ...

Itération 2 : Yeah !

Avant de lancer la deuxième itération, on commence évidemment par une réunion de planification. On est alors dans une situation particulière. L'équipe voit bien qu'elle peut s'engager à terminer les fondations et le première étage, et qu'elle peut également s'engager sur le deuxième étage. Mais il reste quelques points de vélocité ...

Avec mon approche pragmatique, je leur propose de voir avec le PO sur quelle histoire ils pourraient avancer si tout se passe bien, mais sans "engagement" sur cette histoire supplémentaire qui ne sera pas terminée.

La deuxième itération se déroule mieux. Les participants ont compris les règles, ils commencent à intégrer tout doucement le cycle des itérations, et surtout, en 1 tour de jeu ou 2, ils finissent les 2 premières histoires, et ressentent le plaisir de produire (enfin) quelque chose de terminé.

Au cours de cette itération, je m'arrange pour que les "aléas" du dé "à face rouge" ne permette pas à l'équipe de commencer une nouvelle histoire, tout en finissant celles prévues (j'interviens donc dans un sens ou dans l'autre sur le dé).

On peut également tomber sur une autre situation particulière, à savoir qu'un équipier risque de ne pas terminer sa tâche s'il a un obstacle alors qu'un autre a un peu d'avance et pourrait attaquer l'histoire "bonus". J'accompagne alors l'équipe pour qu'elle s'organise au mieux, notamment dans l'ordre des tours de jeu, pour assurer l'engagement pris, quitte à ce qu'un équipier change de tâche au dernier moment, pour ne pas attaquer l'histoire bonus mais vienne en aide à un équipier en difficulté.

L'itération se termine donc mieux que la précédent, avec notamment une démonstration au PO de ce qui est produit : les fondations et 2 étages. Si le temps le permet, on peut faire une rétrospective, sans qu'il y ait (pour cet exercice) de points particuliers à décider à ce stade du jeu.

Itération 3 : oups !

Comme précédemment, on attaque la troisième itération par la réunion de planification. Un constat apparaît tout de suite : l'équipe ne pourra pas tout faire : avec une vélocité à 9 ou 10, on ne peut pas faire le troisième étage (6 points) et le sommet (7 points). 

Je laisse donc l'équipe et le PO échanger librement, en observant ce qui se passe, puis en intervenant pour pointer les bons ou mauvais réflexes. Souvent, des équipiers proposent, voire prennent des initiatives pour choisir ce qui sera fait, voir découper des histoires. J'insiste alors sur le fait que c'est au PO de trancher, fonctionnellement, et le PO, précédemment briefé, choisit alors de renoncer au 3e étage mais insiste pour avoir le sommet.

Il y a donc un "surplus" de vélocité qui amène souvent des questions, mais je présente souvent cette dernière itération comme la fin du projet, le temps restant permettant, dans la vraie vie, de fignoler certaines parties, de finir la documentation, etc ...

Le déroulement de la 3e itération est souvent accéléré, le sommet est rapidement réalisé, on n'oublie pas la démo finale, sans se priver de faire une photo de toute l'équipe (PO et SM compris) autour de la tour produite !

Synthèse

• Matériel : Duplo (en nombre suffisant), 1 dé "spécial", tableau blanc, post-its, feutres
• Nombre de participants : 6 + 1 animateur + observateurs
• Durée : environ 1h30
• Objectif : Scrum, ses rôles, son rythme, ...

Conclusion

Plus intéressant à dérouler qu'à expliquer (longuement) dans un article, ce jeu me donne à chaque fois entière satisfaction, il répond vraiment à mes attentes, dans un contexte de formation d'introduction à l'agilité et à Scrum. 

Outre le fait de permettre aux participants de mettre en oeuvre certains rôles, certains supports, le rythme de Scrum, etc ..., ce jeu me permet également tout au long de son déroulement de pointer et insister sur certaines particularités de l'agilité. 

Il pourra également me servir de référence lorsque, par la suite, j'accompagnerai l'équipe dans sa transition agile, nous pourrons alors nous remémorer certaines scènes du jeu.

N'hésitez pas à me laisser des commentaires pour me faire part de vos réactions et interrogations. Bien sûr, vous pouvez me laisser vos question, ou me contacter pour plus de détails, ou si ce jeu (et la formation dans laquelle il s'intègre) peuvent vous intéresser pour votre entreprise, pour votre équipe !

Merci !

(1) Remerciements et dédicace à D. ... ;-)

(2) Lorsque je parle de Scrum, j'aime bien utiliser du vocabulaire Français, dans la mesure du possible