[Agile France] – Kapla World Tour : Revisitez Scrum !

Pour cette édition de l’Agile France 2012 tout simplement excellente, nous nous sommes amusés à créer un serious game qui visite toutes les cérémonies et artefacts Scrum en accéléré à l’aide de Kapla.

Ce billet a pour objectif de vous expliquer les principes de ce serious game, ce qu’il cherche à obtenir, ses limites et une rétrospective de la session qui a eu lieu à Agile France.

Mais pourquoi les Kaplas ?

Les Kaplas présentent le gros avantage de ne nécessiter aucun prérequis d’âge ou de compétences. La prise en main allait donc être facile et nous allions pouvoir faire passer un maximum de pratiques Agile en très peu de temps (2 heures). Même si le principe est simple, ces petites planchettes nous permettent de réaliser de splendides constructions en très peu de temps sous réserve d’arriver à travailler en équipe en utilisant la créativité de chaque participant. C’est donc à la fois simple pour n’exclure personne et suffisamment compliqué pour se rapprocher un peu de la complexité liée au développement logiciel.

Les règles du jeu

L’objectif

Satisfaire notre Product Owner (client) en lui donnant un maximum de monuments les plus utiles pour lui et la visibilité sur l’état d’avancement du projet (obtenir un climat de confiance).
Pour gagner, il faut donc avoir un maximum de constructions avec le plus de business value (trouver le bon équilibre : complexité VS business value.)

Les contraintes

Les monuments doivent résister à un tremblement de terre de magnitude 4 sur l’échelle de Richter.

Les ingrédients

N équipes de 5 à 9 personnes s’affrontent avec exactement les mêmes règles.
1 product backlog avec des monuments identiques et leur “business value” associée.

3 sprints contenant les cérémonies scrum timeboxées :

  • Sprint planning (4 min) où les équipes doivent s’engager sur un périmètre fonctionnel (monuments à réaliser pendant ce sprint)
  • Réalisation (7 min) où les équipes construisent
  • Démo commune et validation (7 min)
  • Rétrospective (4,5 min)

Minimum 500 kaplas par équipe (mais plus vous en avez mieux c’est !)
Des post-it représentant les monuments ;
Des photos de chaque monument à réaliser pour minimiser les temps de “flottement” dans le jeu ;
Un radiateur d’informations pour afficher la progression des réalisations ;


Des smileys “stickers” pour le Product Owner afin qu’il puisse donner son feedback directement.

Le déroulement

Adaptez-vous au niveau des participants

Selon l’audience dans la salle, présentez le cycle Scrum dans ses grandes lignes sans trop expliquer Scrum et l’Agilité.
Le but est que les participants pratiquent en faisant des erreurs, qu’ils se posent des questions en découvrant le principe par le jeu (l’apprentissage par la pratique est beaucoup plus efficace).
Il faut donc que les participants soient un peu perdus pendant le jeu.

Le product backlog

Celui-ci est présenté et expliqué par le Product Owner. Il expose ce qui est important pour lui en introduisant le vocabulaire “business value”. Il doit bien insister sur la visibilité qu’il doit avoir sur l’avancement des travaux et sur la notion d’engagement sans quoi il ne sera pas content du tout 🙁

Composition des équipes

Les équipes se répartissent si possible avec un “facilitateur” connaissant très bien l’Agilité (possible si vous êtes un grand nombre d’animateurs, sinon il faut se démultiplier). Le facilitateur est externe à l’équipe, il expliquera les concepts de Scrum tout au long du jeu en guidant les participants (facilitateur de proximité pour éviter tout flottement.)

Le sprint planning

Un planning poker ou équivalent peut être organisé avant de faire le sprint planning mais nous avons remarqué qu’il était trop laborieux de le mettre en place avec une faible valeur ajoutée (à cause du nombre réduit de sprints.)
Ici il faut expliquer la notion d’engagement, c’est aussi à ce moment que les équipes vont poser des questions aux products owners. A la fin du sprint planning, il faut voir les tâches sur lesquelles s’engage l’équipe pendant le sprint.

La réalisation

Laissez l’équipe s’auto-organiser, c’est le moment le plus “speed” du jeu où les participants sont imperturbables, le nez dans le guidon, ça discute et ça peut se chamailler !

Petite perturbation pendant les sprints

Pendant le sprint 2 nous avons choisi d’introduire une perturbation avec l’arrivée de notre ami renard qui est venu faire des “câlins” aux bâtisseurs. Cette perturbation doit faire réfléchir les participants sur l’importance d’avoir une personne qui protège l’équipe des perturbations extérieures. A notre plus grande surprise, les bâtisseurs étaient tellement concentrés qu’ils n’ont pas vu le renard …

Entre le sprint 2 et 3 le product owner peut injecter de nouveaux monuments et changer des spécifications pour simuler le refactoring.

La démonstration

Laissez l’équipe choisir une personne pour présenter les réalisations. Le product owner donne son retour en direct en acceptant ou pas les réalisations. En fonction de la personnalité de votre product owner (tatillon, chieur, exigent en changeant d’avis …), les équipes pourront se rebeller contre ce client qui “ne comprend rien à rien, grrrrr” 🙂
Cette réaction face à un client est très fréquente dans les équipes et souvent contre-productive. Si tout se “passe bien”, cette “mauvaise” réaction servira potentiellement d’axe d’amélioration pour l’équipe dans votre jeu.

La rétrospective

Demandez à chaque personne un axe d’amélioration sur post-it, à tour de rôle, chaque personne s’exprime en écrivant ce qui est le plus important pour elle. L’équipe se met ensuite d’accord pour prendre le sujet qui fera augmenter le plus la performance de l’équipe. Idéalement, il faut chercher une mesure fiable qui vous permettra de savoir si ce que l’équipe a mis en place a été efficace ou pas.

Et le gagnant est …

A la fin des 3 sprints, le burn-up du radiateur d’informations vous donnera l’équipe qui a fourni le plus de business value à notre Product Owner. Les smileys que le product owner a distribués au court de jeu servent de bonus ou malus.

Le debrief

On refait le film. Le but du debrief est de comprendre ce qui s’est passé. L’équipe a travaillé en accéléré, les mêmes comportements, réactions, interactions se produisent dans nos équipes de développement. Le debrief va permettre au groupe de comprendre pourquoi telle ou telle pratique issue du “bon sens” est si importante et pourquoi le “bon sens” est parfois si difficile à avoir quand on est le nez dans le guidon et en situation de stress. Le plus amusant est qu’il ne se passe jamais la même chose quand on organise le jeu. Il faut donc observer et mettre en évidence les événements les plus percutants pour retenir les apports de Scrum.

Conclusion

Ce serious game très simple permet de sensibiliser les participants aux valeurs de l’Agilité suivantes :

  • Auto-organisation
  • Feedback rapide du client (mode itératif)
  • Cycle d’amélioration continue
  • Management visuel
  • La “protection” de l’équipe face aux perturbations
  • L’engagement de l’équipe
  • Estimation collective de la complexité d’une tâche
  • Importance de la démonstration et de ses difficultés
  • Priorisation

Ce jeu peut servir dans les cas suivants :

  • Etre une bonne introduction à Scrum pour les néophytes qui retiendront plus de choses en 2 heures de jeu qu’en 2 heures de séance en mode slideshow, surtout si vous avez des étudiants le vendredi matin 🙂
  • Si vos équipes font de l’Agilité “comme-ci comme-ça” cela peut être un bon moyen d’organiser ce jeu avec elles, sans remettre en cause leur Agilité. Au pire, cela fera une bonne séance de “team building”.

Un grand merci aux participants qui sont venus jouer avec nous à Agile France. On s’est bien amusé 🙂

Si vous souhaitez animer ce serious game dans vos équipes, nous pouvons vous envoyer les supports sur simple demande mais pas les Kaplas, ils ont été réquisitionnés par Yann Béllières, un grand joueur parait-il …

Nombre de vue : 249

COMMENTAIRES 5 commentaires

  1. Rafin Olivier dit :

    Bonjour,
    Nous sommes une jeune et petite société de conseil dédiée à l’Agilité des S.I (Sur les aspects Méthodes de pilotage Agiles et Architecture).
    J’ai trouvé très intéressant le serious games autours des Kappla et souhaiterais pouvoir l’utiliser avec nos équipes en phase amont de projets pour les sensibiliser/informer/préparer aux proces Agiles à mettre en oeuvre.
    Pourriez vous m’indiquer la marche à suivre pour récupérer le matériel et éventuellement un contact pour échanger sur la meilleure manières d’aborder les différents points du jeu.
    Merci et bonne journée

  2. Bruno Fargeon dit :

    Bonjour,

    Etant à la recherche d’une moyen de sensibilisation d’équipe aux méthodes agiles, je souhaiterais expérimenter ce jeu. Vous serait-il possible de m’envoyer les supports?

    Un grand merci par avance.

  3. G. Chabrol dit :

    Bonjour,
    Enseignant-chercheur en école d’ingénieur, je souhaite organiser ce jeux pour sensibiliser les étudiants aux méthodes agiles.
    Est-ce qu’il serait possible d’avoir les supports?
    Merci d’avance.
    Cordialement

  4. […] Grégoire, who is really found of Kapla, has found the very nice agile game Kapla Workd Tour. […]

  5. C. Monnier dit :

    Bonjour,

    Je souhaiterais animer ce jeu pour faire une introduction aux méthodes agiles au sein de notre équipe. Serait-il possible d’avoir les supports ?

    Par avance merci.

AJOUTER UN COMMENTAIRE