J’ai eu l’occasion de jouer ce jeu lors de Agile France 2011 (cf. bonus en fin d’article) et plusieurs fois lors de formations sur le Kanban que je donne régulièrement chez mes clients, et Laurence s’y était essayée avec réussite lors de Agile Grenoble 2010. Les feedbacks ont toujours été unanime sur l’efficacité de ce jeu pour porter les messages principaux et pour son coté ludique et amusant.

Plutôt que de l’envoyer à chacun des demandeurs, je me suis dis qu’il était préférable de faire un article dans ce blog, le voici.

Je suis preneur de toutes vos remarques ou questions.

Description du Jeu en 2 pages

CasinoGame_Description

Faire des sessions de 15 tempos et mesurer les résultats (garder les résultats pour comparer les sessions d’une itération à une autre)

Ne faire qu’une session pour la première itération, puis 2 sessions pour les itérations 2 et 3, et 3 sessions pour l’itération 4.

Fiches des personnages

Fiches Personnages 2.1 (face) : A imprimer sur du carton ou a plastifier (1 fiche par joueur)

Fiches Personnages 2.1 (dos)

Agiletoyou – Petits personnages Pour mettre au dos des boîtes qui contiennent les dés

Fiches des tâches

Agiletoyou – Fiches Jetons 2.1 Imprimer au moins 2 jeux (1 pour jouer pendant que vous classer l’autre)

Support de présentation

Agiletoyou – Presentation 2.1

Matériel

Trouver des boîtes qui peuvent contenir 2 dés et qui disposent d’une face vitrée (pour pouvoir jouer debout).

Affectation des dés

1. Patron du Casino                                                  1D6 + 1D6
2. Banquier                                                                  1D6 + 1D8
3. Garde du corps                                                      1D6 + 1D6
4. Joueur                                                                       1D4 + 1D4
5. Porte bonheur                                                       1D6 + 1D6
6. Croupier                                                                   1D6 + 1D6
7. Collecteur de fonds                                             1D6 + 1D6

Total des dés : 11 fois 1D6, 2 fois 1D4, 1 fois 1D8

Bilan des Cycles

A chaque cycle faire la somme des éléments suivants :

-          Nombre de fiches dans le système (« stock »)

-          Nombre de fiches produites

-          Bonus éventuel (toutes les fiches d’une même couleur) : Attention, il n’y a que 9 cartes dans la 1^ère série et 10 dans les autres

Bonus

Une très belle description de ricardo.minhoto sur le déroulement du jeu lors de Agile France 2011 (http://blog.soat.fr/2011/05/agile-conference-kanban-au-casino/#more-3721) … avec beaucoup d’informations pour les futurs facilitateurs de ce jeu.

Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.

L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.

Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement (« Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !

Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de  passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.

Et vous, comment trouvez vous du temps pour réduire votre dette technique ?

L’article est plutôt long ou je dirais plutôt très complet, alors prenez votre temps

L’auteur explique de façon très pédagogique les apports de la méthode Scrum et ses limites dans le contexte du jeu vidéo. Il explique ensuite la manière dont l’équipe a mis en place puis surtout amélioré son système Kanban et révèle les gains de productivité associé (56%). Il détaille et argumente chaque changement en se référant aux 7 concepts du Lean Software Development.

Bref, pour moi qui suit un fana du Lean, c’était un pur moment de plaisir que de lire cet article, j’espère qu’il en sera de même pour vous, bonne lecture.

Coté sessions:

• Gery Derbier m’a fait jouer à « Artistes et Spécifieurs » pour me faire réaliser, en autres, qu’il n’y a pas de solutions parfaites pour spécifier quelque chose. Ce jeu Agile m’a beaucoup plu et je vais le travailler pour mieux le comprendre et le reproduire en interne.
• L’amphi était plein pour ma présentation du retour d’expérience Yahoo sur le passage d’une méthode Waterfall à Agile entre 2005 et 2008. Les premiers feedbacks à chaud étaient très positifs. Par contre, en tant qu’orateur, j’ai bien réalisé la difficulté de tenir sur un format de 50 minutes – ce que nous avions imposé à Grenoble
• Une petite dizaine de personnes ont contribué à l’Open Forum que j’animais, les questions que nous avons traités concernaient la contractualisation Agile, le rôle et l’intervention des experts, et les difficultés rencontrés lors d’une itération.
• Retour en Amphi pour écouter Géry Derbier nous parler des principes de Crystal dont les 3 essentiels que sont la livraison fréquente, la communication dans l’équipe et la réflexion pour s’améliorer. Géry a indiqué que les équipes Crystal avaient tendance à abandonner au bout d’un certain temps les itérations à durée fixe pour du KANBAN (Lean). Ce que je retiens surtout de Crystal c’est qu’il faut adapter ses pratiques en fonction du contexte et donc de l’avancement du projet car les besoins sont différents et début, milieu et fin de projet. Cette approche, qui me semble maintenant être une évidence, ne se retrouve pas clairement dans Scrum, surement quelque chose à réfléchir et murir.

Ensuite, beaucoup de discussions autour du buffet, que ce soit avec Hubert pour discuter des différences d’implémentation Agile chez Yahoo et Thales (il a contribué aux 2), avec Nicolas sur le déroulement des rétrospectives, avec Emmanuel sur la gestion des membres d’une équipe Scrum … et avec bien d’autres sur des sujets divers et variés, bref une très bonne après-midi.