Comment réaliser un atelier Lego4Scrum
Lego4Scrum est un atelier qui a pour but de mettre en pratique le cadre méthodologique Scrum.
En 3 Sprints courts, les participants ont pour objectif de construire une ville en Lego.
Le jeu est volontairement limité dans le temps, avec un Backlog produit chargé, afin de stresser des participants qui, généralement, découvre Scrum. Il en résulte, lors du 1er Sprint, l’oublie de la méthode, la désorganisation, une mauvaise gestion des priorités, des spécifications et de la communication. La 1ère rétrospective permet de recadrer les mauvaises habitudes et de comprendre les apports de la méthodologie qui sera appliquée dès le sprint suivant.
Le jeu commence par la définition du projet. La durée de cette présentation est de 5 minutes.
Il s’agit d’une description de la ville idéale vue par son maire (le Product Owner).
Suivi par la présentation du backlog. En effet, le « maitre de jeu » (qui joue aussi le rôle du Product Owner) aura pris soin de préparer les user stories. Cette présentation durera 15 minutes (présentation, questions/réponses sur les spécifications, priorisation).
Commence ensuite les Sprints. Au nombre de 3, chaque Sprint dure 23 minutes ainsi réparties :
- Estimation des demandes par le planning poker (5 minutes)
- Planification du Sprint à venir (3 minutes)
- Sprint (7 minutes)
- Revue de Sprint (5 minutes)
- Rétrospective de Sprint (3 minutes)
A l’issue des 3 Sprints, un débriefing est prévu (15 minutes). Suivant comment se passe le 1er Sprint, je vous conseille de prendre quelques minutes pour débriefer ce Sprint.
La définition du projet
Lors de ces quelques minutes, vous présenterez le texte suivant aux participants et rien que ce texte, sans plus d’explication.
Par contre vous pouvez, et devez, répondre aux questions de participants sans jamais donner plus de détails que demandés.
Ce texte sera affiché à côté du Product Backlog.
« Ma ville idéale dispose de tous les aménagements dont les habitants ont besoin, que ce soit des maisons individuelles ou un immeuble d’habitation. L’ensemble, très harmonieux, est situé dans un coin calme de la ville.
Pour aller au collège qui est en dehors de la ville, le maire a mis en place un système de bus avec plusieurs arrêts dont un à proximité de l’école. Le bus dessert aussi les habitations, l’hôpital et le magasin.
Tout est prévu pour le confort des familles, que ce soit pour réaliser leurs courses, pour l’éducation des enfants, avec une école, pour leur santé.
Lorsqu’il fait chaud, les habitants aiment se promener dans le parc, à l’ombre des arbres ou près de la fontaine.
D’autres constructions sont en cours telle une nouvelle mairie ou une zone industrielle.
Le maire »
Ce texte donne plusieurs indices aux participants :
- La priorisation : on commence par une maison, puis l’immeuble, les routes, etc.
- Certains détails qu’on ne trouvera pas dans les user stories : habitation à l’écart du reste de la ville, des détails pour le parc (des arbres et une fontaine)
A sa lecture, les participants ne prêteront pas attention à ces détails.
Si jamais discussion il y a lors du débriefing, vous pourrez leur apporter la preuve que lors du jeu, ils avaient toutes les informations nécessaires à la construction de la ville. S’ils n’ont pas bien cerné les spécifications ce n’est pas en raison de dissimulations de la part du « maitre de jeu » mais bien par manque de communication avec le Product Owner.
Présentation du Backlog
Pour gagner du temps, les user stories seront déjà écrites sur des post-it. Elles seront présentées aléatoirement, les participants devant penser à la priorisation (s’ils ne demandent pas, tant pis pour eux… je vous rappelle que vous ne devez simplement répondre à leurs questions).
- Un immeuble (en tant que maire, je veux un immeuble pour loger plusieurs familles)
- Une école (en tant que maire, je veux une école pour scolariser les enfants jusqu’au CM2)
- Une petite maison (en tant que maire, je veux une maison pour loger une petite famille)
- Une grande maison (en tant que maire, je veux une maison pour loger une grande famille)
- Une route (en tant que maire, je veux une route pour desservir la ville et joindre les autres villes)
- Des arrêts de bus (en tant que maire, je veux des arrêts de bus pour desservir l’école, l’hôpital, le magasin et les habitations)
- Un hôpital (en tant que maire, je veux un hôpital pour soigner mes concitoyens)
- Un magasin (en tant que maire, je veux un magasin pour les produits de base)
- Un jardin public (en tant que maire, je veux un jardin public pour que mes concitoyens puissent se détendre)
- Etc.
Prévoir en fonction du nombre de personnes et de leur connaissance Scrum.
Vous lirez les post-it et les collerez dans le Product Backlog sans aucune explication autre que celles-ci :
- Vous pouvez dessiner les routes.
- Vous pouvez dessiner les arrêts de bus.
- Vous pouvez dessiner les contours du parc public.
- 1 étage équivaut à 4 briques (par ex.) de Lego.
- Fenêtre (ne doit ni toucher le sol, ni le plafond), porte (ne doit pas toucher le plafond), baie vitrée (ne doit pas toucher le plafond) sont des espaces vide.
Aux participants de poser des questions pour connaitre les spécifications et critères d’acceptation.
Par exemple, l’immeuble doit être rectangulaire, faire 2 étages, avoir une porte d’entrée à l’avant, un toit plat, un parking 6 places à l’arrière (qui peut être dessiné), avoir une fenêtre par étage sur la largeur et 2 fenêtres par étage sur la longueur.
Si personne ne demande si il y a un parking, ne pas leur donner l’information. Lors de la revue, vous refuserez la livraison en raison du non-respect des spécifications : « et mon parking ? »
Idem, s’ils oublient la priorisation et livre le magasin en 1er par exemple, vous refuserez le livrable en expliquant que bien que vous ayez demandé un magasin, celui-ci n’était pas votre priorité. Si jamais les participants ont oublié de prioriser le backlog, ils le feront.
Estimation des demandes
Qui est capable d’estimer la construction d’une ville Lego en fonction des spécifications données ci-dessus ?
Pour être franc, personne. Toute estimation sera fausse lors du 1er Sprint.
Pire, les participants vont calculer leurs estimations en fonction du nombre d’user stories : on a 3 Sprint pour réaliser 12 constructions, soit 4 constructions par Sprint, soit…
Or, je le rappelle, votre backlog doit être impossible à réaliser sur 3 Sprints mais doit le laisser penser (évitez de mettre 100 user stories).
Pour quelles raisons ?
Mettre une forme de pression pour que les mauvaises habitudes reviennent lors du 1er Sprint.
En cours de Sprint, lorsque les participants se rendent compte que les délais sont intenables, la panique et la désorganisation gagne tout le monde. La rétrospective sera l’occasion de certaines prises de conscience sur sa façon d’organiser son travail.
Avec le chrono sous les yeux (seulement 7 minutes), ils ne penseront même pas à remettre en cause le jeu et l’impossibilité de le terminer.
Sans expérience, ou retour d’expérience, il est difficile de donner des estimations. Celles-ci s’affinent à chaque Sprint.
C’est seulement à l’issue du 1er Sprint que les participants le comprendront.
Ce sera l’occasion, lors de la revue, de discuter et de négocier avec le Product Owner (qui devra rester ferme sur ses positions… alors que le chrono, lui, continuera d’avancer). Le groupe devra pouvoir dire au Maire, qui attend une ville à la fin des Sprints, qu’il ne l’obtiendra pas, mais seulement entre X et Y bâtiments… comme quoi un plan de release n’est pas si inutile que ça :)
Planification des Sprints
En tant que « maitre de jeu », vous aurez pris soin de préparer le Scrumboard.
Les participants prépareront le backlog du sprint et s’organiseront pour la réalisation.
Sprints
En tant que « maitre du jeu » vous observerez les comportements et écouterez ce qui se dit. Ceci pour préparer le débriefing.
Pour être efficace, limiter le nombre de participants. Au-delà de 2 groupes de 4 Sprinters, je ne vois pas comment il est possible de faire un retour d’expérience pertinent et sur mesure.
Durant les 2ème et 3ème Sprints, vous pouvez ajouter des user stories prioritaires (1 par Sprint suffit).
Par exemple, interrompre le Sprint (et le chrono) pour expliquer que suite à la réalisation des routes un grave accident est arrivé. En tant que maire vous exigez que des feux de signalisation soient immédiatement mis en place à chaque intersection.
Si normalement en Scrum, on n’agit pas ainsi, il en va autrement dans la vraie vie. Laissez le groupe se réorganiser pour continuer son Sprint et intégrer cette demande. Observez.
Revue de Sprint
Des choses vont être livrées. Mais si les spécifications n’ont pas été correctement cernées, des surprises sont à prévoir.
Lorsqu’en tant que Product Owner vous refusez une livraison, expliquez pourquoi :
Product Owner : « il manque des fenêtres à mon immeuble, ce n’est pas ce que j’ai demandé. Je ne peux pas accepter ce livrable »
Participants : »ce n’était pas précisé dans la demande »
Product Owner : « peut-être, mais il me semble évident que… Il fallait demander »
De là, les participants vous poseront surement tout un tas de questions pour cerner les spécifications.
But de la manœuvre : Que l’habitude soit prise de poser des questions au Product Owner afin de cerner les spécifications. La plupart du temps, beaucoup de chose ne sont pas précisées par les demandeurs, ces choses leur paraissant évidentes.
Rétrospective de Sprint
Les participants font faire le bilan de leur Sprint passé et changer pas mal de chose.
Je me permets de les aiguillez s’ils oublient certaines pratique Scrum, en les rappelant.
Débriefing
Il y a de fortes chances pour que le 1er Sprint se passe mal pour les participants. Relevez les erreurs si elles ne sont pas évoquées lors de l’autocritique.
Pour autant n’insistez pas dessus et rassurez les participants : « c’est normal, le jeu est fait pour vous mettre sous pression et vous poussez à commettre des erreurs lors du 1er Sprint. »
Le plus important est la 1ère rétrospective : comment a-t-elle été gérée et insistez sur les améliorations lors des Sprints suivants.
Le but n’est pas de démolir les participants mais de montrer vers quels travers on tend en mode panique, et comment les rétrospectives aident à rectifier le tir.
Exposez ce que vous avez relevé et rappeler le fonctionnement de Scrum.
La suite
Une formation a surement été délivrée en amont du Lego4scrum.
Pour autant, et malgré l’apport incontestable du jeu, veuillez accompagner les participants sur leur 1er projet.
Car si l’application aura bien été comprise, mettre en œuvre une nouvelle méthodologie n’est jamais évident la première fois.