J’ai récemment animé une formation de 2 jours Agile-Scrum pour une des équipes que j’accompagne.

Je suis joueur, j’essaie au maximum d’agrémenter chaque apprentissage par un atelier type jeu d’entreprise.

Durant cette formation, pour illustrer l’organisation Scrum, je voulais faire un atelier avant la partie de présentation et surtout jouer le classique des classiques Lego4Scrum dont le but est de construire une ville avec des Playmobils (petit malin…) en passant à travers tous les concepts du framework.
Des personnes de l’équipe avaient déjà joué cette version. Il fallait donc ruser.

En discutant avec Christophe Keromen, j’ai appris qu’il jouait beaucoup le jeu Birdie Birdie ou un Lego4Scrum avec le backlog Birdie Birdie.
J’eu donc l’idée de fusionner les deux jeux afin de créer (je ne suis peut être pas le seul) le :

Birdie4Scrum

Birdie Birdie créé par Alan Cyment. Je me suis basé sur une traduction d’Alexandre Boutin (@agilex) que je remercie donc pour ce travail.

Lego4Scrum créé par Alexey Krivitsky  et traduit dans la langue de Molière par Fabrice Aimetti (@Agilarium) and Sylvain Fraïssé (@sfui) que je remercie aussi

L’objectif de l’atelier

Construire un oiseau en Lego tout en intégrant les concepts Scrum.

Le background

Je suis le chef de produit (selon Birdie Birdie, l’animateur joue le Président) de la société TopToys dont le projet est de lancer un nouveau produit avec pour nom de code : MegaZozio.

Le jouet appartient à la ligne de produits « 153 » qui est un des fleurons de la société. Ce sont des jouets construits avec exactement 153 pièces assemblées (ce détail sera utile au moment du debrief et instruit la notion de gâchis du lean).

Organisation

Le Lego4Scrum se joue en 2h quand le Birdie Birdie peut être fait en un peu moins d’1h30, j’ai préféré garder le timing à 2h pour plonger l’équipe dans l’organisation Scrum malgré la densité de l’atelier, donner un peu d’air aux participants.

Comme le recommande Lego4Scrum, j’ai laissé les équipes se former, ils étaient 12 et leur ai donc demandé de créer 2 équipes de 6 en mélangeant leurs postes.

J’ai estimé le timing de la session comme suit :

• Préparation : 15mn
• Présentation du backlog : 15mn
• Estimation : 5mn (x3 itérations)
• Planification : 3mn (x3 itérations)
• Réalisation : 8mn (x3 itérations)
• Revue : 5mn (x3 itérations)
• Rétrospective : 3mn (x3 itérations)
• Débrief : 15mn

Total : environ 120mn (plus ou moins 2h en fonction de l’état des participants que vous êtes censé guider).

Démarrage du projet

J’ai d’abord présenté le background tel que décrit plus haut puis leur ai fait part du fait que j’allais leur fournir une liste de fonctionnalités. J’avais imprimé auparavant 2 fois le backlog du jeu Birdie Birdie pour que chaque équipe s’approprie les cartes

En tant que chef de produit, je suis le principal décideur sur le produit, il s’agit de mon produit (j’ai déjà dis produit ?) et je serai impliqué dans le processus de développement en étant disponible pour répondre aux questions et fournir mes feedbacks.

L’équipe a 4 itérations pour faire un bel oiseau. Sauf que, tel qu’énoncé dans le Birdie Birdie, l’équipe n’aura que 3 itérations (parce que le concurrent sort son produit plus tôt que prévu).

C’est un apprentissage du Birdie Birdie qui n’existe pas dans Lego4Scrum et que je trouvais vital pour tester la puissance de la gestion par la valeur métier de l’agilité vis à vis de la notion de time to market.

Construction du backlog

Là j’effectue un mélange des règles du Lego4Scrum et du Birdie Birdie, j’affiche sur un mur (j’ai bien sûr utilisé le kit du facilitateur pour ma formation) la liste des histoires de la première itération selon les recommandation du Birdie Birdie :

• Iteration 1 : User Story 01 à 08 : Nom d’oiseau, Roues, Bec, Ailes, Initiale, Jambes, Hauteur, Tête
• Iteration 2 : User Story 09 à 12 : Rangement, Couleur, Symétrie, Barrière
• Iteration 3 : User Story 13 à 19 : Bébé, Remorque, Jambes Noires, Bicéphale, Queue, Yeux, Résistance

A la différence de Lego4Scrum, on n’affiche pas la totalité du backlog. La liste des demandes pour l’itération 1 n’est (à priori) pas faisable en 1 itération et va générer un décalage entre le demandé et le créé.

On représente bien le travail du gardien de produit qui présente les histoires prêtes à être présentée. On distingue dans les itérations suivantes ce qui a été identifié et ce qui a émergé des revues et des retours marketing (les nouvelles histoires entrées dans le backlog).

Chiffrage

J’ai repris le fonctionnement Lego4Scrum et ai opté pour la méthode Extreme Quotation pour ne pas perdre trop de temps. J’ai dessiné un tableau avec, en colonne : 1,2,3,5,8 et ai laissé l’équipe se débrouiller.

 

De manière instinctive, sans connaître le fonctionnement d’une phase de chiffrage, ils ont designé une petite histoire qu’ils ont positionné à 2 et une grosse à 8 et ont pratiqué le chiffrage par comparaison et HOP !

Pour aider l’équipe, demandez pour chaque histoire : ça vous semble gros ? Pas gros ?

Le but de la phase de chiffrage est aussi de challenger le product owner et lui poser des questions pour faire émerger des critères d’acceptance cachés (ceux de la liste du Birdie Birdie) donc incitez l’équipe à vous poser des questions pour mieux cerner la demande et valorisez ceux qui posent des questions.

Attention ! : Dans cette phase, assurez vous que l’équipe vous définit en tant que gardien de produit et non d’animateur (je n’ai malheureusement pas été assez clair et ai eu du mal à jongler entre les casquettes). En tant que chef de produit, vous êtes naturellement celui qui peut répondre aux questions fonctionnelles. En tant qu’animateur, l’équipe n’aura pas le réflexe de vous challenger. Soyez clairs dans votre posture.

Planification de l’itération

Toutes les histoires présentées sont chiffrées, il est temps de demander à l’équipe ce qu’elle pense être en mesure de faire dans l’itération.

J’avais dessiné le tableau Lego4Scrum pour les 4 itérations :

Lorsque l’itération est terminée, après la revue, remplissez la ligne “actuel” avec les points réellement fait (la vélocité de l’équipe) et n’oubliez pas aussi de noter la valeur métier générée dans un coin.

Après quelques itérations, votre tableau devrait ressembler à ça :

 

Bien sur la 4ème ligne ne sera jamais remplie MOUAHA MOUAHA MOUAHAHAHA

Itérations

Le temps de l’itération est fixée à 8mn, si vous le pouvez, affichez un grand chronomètre.

Normalement, la règle du Birdie Birdie demande à ce que l’équipe produise un visuel permettant au chef de produit de voir l’avancement. J’avais moi-même décidé de produire un kanban board “A faire”, “En cours”, “Terminé” et de placer les histoires dessus mais logistiquement, l’équipe n’arrivait pas à visualiser les critères et ont demandé s’il était plutôt possible de garder les histoires près de la zone de construction. Le tableau a vite été abandonné, j’ai juste demandé à ce qu’elles soient mises dans la colonne “Terminé” pour savoir lesquelles je devais passer en revue.

Revue

La règle du Birdie Birdie nous dit :

Les User Story disposent d’Acceptance Criteria incomplets dont certains ne sont pas forcément intuitifs (par exemple : le bec doit être ouvert). Et seul le facilitateur (le président) dispose de ces informations complémentaires. Le gardien de produit a des besoins définis mais ne sais pas exactement ce qu’il veut.

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 ? ». Il acceptera plus facilement de discuter régulièrement avec un représentant de l’équipe (type : Scrum Master).

Les critères d’acceptance manquants émanent du tableau Birdie Birdie :

Je n’avais pas designé de Scrum Master puisque je jouais le jeu avant de traiter la partie Scrum de la formation.

J’ai donc joué le rôle du chef de produit pour la revue et ai retoqué un paquet d’histoire. Le but est normalement de faire réagir afin que l’équipe pose plus de questions à la phase de chiffrage de l’itération suivante.

Point intéressant : j’étais assez mal à l’aise avec le fait de dire à des personnes dont l’habitude est d’avoir les spécifications les plus précises possible : « non je n’accepte pas l’histoire pour un critère que je ne vous avais pas donné ». Étonnamment, cet aléa a été totalement accepté par les participants et j’ai entendu des : « Tiens, on connait ça, typique du marketing ! ».

Retrospective

Laissez l’équipe gérer sa rétrospective et lui demandant comment elle pense pouvoir s’améliorer.

3ème itération

J’ai repris les règles de Birdie Birdie à la lettre :

3 minutes après le démarrage de la 3ème réalisation, le chef de produit interrompt toutes les équipes pour dire qu’un concurrent va lancer sur le marché un jouet concurrent de façon imminente et qu’il faut absolument commercialiser le projet « Mega Zozio » à la fin de cette itération.

Et là c’est la révélation pour les participants. Cet aspect que je n’avais pas retrouvé dans le Lego4Scrum donne tout le sens de la démarche de priorisation par la valeur.

Debrief

Bien sur, n’oubliez pas le debrief en vous appuyant sur les propositions de questionnement du Lego4Scrum et du Birdie Birdie, ça foisonne c’est parfait

Petits exemples :

• Qu’avez-vous ressenti pendant ce jeu ?
• Avez vous utilisé moins de 153 pièces ?
• Qu’aurions-nous pu faire différemment ? (j’aime beaucoup cette question)
• De quelle façon votre stratégie va-t-elle changer si vous savez que le Product Owner ne sera pas disponible pendant les sprints ?
• Qu’avez vous appris ?
• …

Mon feedback sur l’atelier

Bien séparer le rôle animateur/PO

Le gros point noir de l’animation a été de mal différencier mon rôle d’animateur et de PO donc soyez vigilants et clairs sinon l’équipe n’arrivera pas à appréhender le rôle du PO.

Essayez tant que possible de poussez les participants à vous questionner. Observation très intéressante : je suis allé voir une des équipes, qui ne me questionnait pas beaucoup, pendant la phase de réalisation, en leur précisant que j’étais disponible s’ils avaient besoin d’informations complémentaires. La réponse a été « non c’est bon, on se débrouille, on fait à notre façon »… mmmh intéressant.
Moralité, sur la dernière itération, j’ai refusé les ¾ de leurs histoires (soit 6 ou 7 histoires quand même).

Ce qui peut être très intéressant et formateur est de proposer en amont de la session de formation à un participant (la personne identifiée comme étant le PO de l’équipe ?) de tenir le rôle de Product Owner pendant l’atelier, vous lui fournissez la liste des histoires, le timing et les critères d’acceptance cachés et laissez faire la maaagiiiie.

Frustrer oui, punir non !

Il est important dans ce type d’atelier de générer de la frustration, c’est un élément moteur de l’apprentissage mais aussi du plaisir de jouer. Auriez vous autant de plaisir si les questions du trivial pursuit n’étaient pas difficiles ou piégées ? Mario Bros serait-il aussi amusant si certains sauts n’étaient pas millimétrés ?

Cependant, pour la première itération, j’ai demandé à ce que les constructions liées à des histoires refusées soient démontées. Grossière erreur de ma part, à mon avis.

D’une ça ne représente pas la réalité, de deux ça génère une sacré dose de frustration inutile. Je préfère que l’équipe soit frustrée parce qu’elle n’a respecté la demande et doit démonter la totalité ou partie de sa construction plutôt que parce que je leur demande directement de détruire leur travail.

Ne soyez pas avares en Lego

Prévoyez la dose de Lego, attention à la limitation technique en terme de couleurs et de nombre de brique, ça peut devenir un piège pour l’animation où vous allez devoir jongler entre les spécifications des histoires et la réalité du terrain (ça peut être intéressant comme ça peut compliquer l’apprentissage).

Rappelez vous aussi, le projet doit s’inscrire dans la chaîne de production 153, vous devez jouer avec cette notion à la fin du jeu pour savoir si les participants ont bien pris en compte cette notion de gâchis. Si vous n’avez pas assez de briques différentes en quantité, vous ne pourrez pas jouer avec cet apprentissage.

 De la liberté

Ce que j’ai vu aussi, c’est qu’il faut parfois savoir flouer les règles pour avoir le produit le plus agréable. J’ai donc parfois fait fi des règles pour que les équipes produise un résultat qui me plaisait. Finalement c’était ma vision du produit.

« ICare » de l’équipe B

Je conseille aussi le billet d’Alexandre Boutin et son adaptation du Lego4Scrum