Agile Games France 2013, le feu d’artifice du jeu agile

Pierrick et Grégoire étaient à Avignon pour cette seconde édition « Agile Games France », ils nous font part de leurs retours sur cet évènement qui devient incontournable pour les utilisateurs intensifs de jeu de coaching / formation / facilitation de réunion / …
Comme l’an passé à Nantes, cet évènement auto-organisé a été redoutablement efficace, un énorme plaisir pour nous, fait de rencontres, de découvertes, et d’expérimentation.

Voici les jeux que nous avons testés, observés ou facilités lors de ces 2 jours :

Excellente entrée en matière proposée par Alexandre Boutin, sur la suggestion de Gilles Mantel : impromptu speed networking, un ice breaker qui consiste à aller à la rencontre des participants qu’on ne connait pas et de faire ressortir en un mot ce qu’on a retenu d’eux en 5 minutes de discussion. On a pu par exemple faire la connaissance de Jean-Yves l’agilosceptique convaincu et Olivier, l’himalayen connexionneur.

Idée à expérimenter : mixer cet ice breaker avec le Low Tech Social Network, l’un incitant les participants à entrer en contact, l’autre apportant une visualisation plus navigable des connexions créées.

Delegation Poker (proposé et facilité par Gilles Manteltesté par Grégoire)

Un jeu de Jurgen Appelo permettant de mettre en pratique l’échelle des 7 niveaux de délégation décrite dans Management 3.0. Les niveaux vont de 1 : je décide seul à 7 : je laisse l’équipe décider seule, sans l’influencer. Le monde réel nous offre en effet bien plus de subtilité que ces 2 choix radicaux. Par exemple, le niveau 3 me propose, en tant que manager, de consulter l’équipe mais que je prenne la décision finale.  Le niveau de délégation que je choisis dépend de ce que j’ai à traiter, du niveau d’auto-organisation de l’équipe et de mon niveau de confiance en tant que manager.

Les réponses sont rarement triviales : quel niveau de délégation pour le cas « Une restriction budgétaire m’oblige à licencier 2 collaborateurs » ? On pourrait par exemple choisir un niveau proche du totalitarisme pour concentrer les éventuelles rancœurs et préserver la cohésion de l’équipe (1 ou 2). Mais encore une fois, cela dépend du contexte, et on pourrait imaginer qu’une équipe très mature pourrait être assez forte pour prendre cette décision en autonomie sans se briser.
Lors du debrief nous convenons que l’attribution de points n’est pas nécessaire et biaise l’atelier.
Ce jeu peut être utilisé : pour animer des communautés de pratiques (PO, management), au sein d’une équipe agile pour la confronter à son besoin d’autonomie, en rétrospective pour obtenir un feedback de l’équipe suite à une prise de décision…

Le site du jeu : http://www.noop.nl/2011/03/delegation-poker-game-description.html

 

Kanbanzine (proposé et facilité par Claude Aubry et Jean-Pierre Bonnafous« entamé » par Pierrick)

Nous sommes nombreux à l’avoir réclamé, séduits par l’esthétique du plateau de jeu. Et c’est vrai qu’il est beau ! Mais, après l’introduction de Claude, j’ai trouvé ce jeu trop proche de GetKanban pour consacrer 2h à l’expérimenter. J’ai donc cédé ma place pour aller voir les autres jeux lancés en parallèle. Les personnes qui ont participé à Kanbanzine ont confirmé mon à priori : pas de différence majeure par rapport à GetKanban à part le sujet (la rédaction d’un magasine) très prenant, ce qui peut constituer un plus pour entrer dans le jeu mais qui risque d’éloigner le joueur de l’objectif premier qui est de comprendre les rudiments de Kanban.

Le site du jeu : http://kanbanzine.wordpress.com/

 

« Le management par objectif m’a tué » (proposé et facilité par Fabrice Aimetti, observé par Pierrick)

J’ai rejoins les joueurs en phase de debrief de ce jeu créé par Fabrice Aimetti. Le principe : on bande les yeux d’un participant, puis on donne un objectif à un groupe de managers : guider l’ »aveugle » pour qu’il récupère un crayon posé dans la pièce. Dans un second temps, on dispose plusieurs crayons dans la pièce (un par manager) et on demande à chaque manager de guider l’ »aveugle » pour récupérer son crayon. Évidemment, c’est la guerre, l’ »aveugle » recevant des consignes contradictoires.

Le message parait clair : ne pilotons pas nos réalisations par des sous-objectifs isolés, sans organiser la collaboration des parties prenantes pour atteindre l’objectif commun qui pourrait être ici de rapatrier tous les crayons.

Lors du debriefing collectif, il est apparu que faire concevoir une phase 3 idéale par les joueurs en ferait un excellent jeu, comme démarrage d’une journée avec des managers.

Agile Oops ! (proposé et facilité par Irène Doan,)

Sur le principe du célèbre Taboo : deviner des termes agiles en évitant certains mots. Très bon moyen de valider des connaissances à l’issue d’une formation car ça oblige à reformuler avec ses propres mots une notion abordée en se débarrassant des mots « tout fait » que le formateur a pu y associer. On s’est vraiment amusés en essayant la version mimée mais l’intérêt est bien moindre à mon avis en usage professionnel.

Le site du jeu : http://julezwitschert.blogspot.fr/2011/06/oops-agile-oops.html

Les Derdians (proposé et facilité par Lan Levy et Irène Doan, testé par Pierrick)

Sans doute le jeu le plus surprenant de ces 2 jours. Il s’agit de simuler un travail collaboratif entre des équipes très éloignées culturellement. Un groupe joue le rôle des Derdians : une population d’un petit village qui doit construire un pont pour s’éviter deux heures de marche quotidienne, et une équipe d’ingénieurs européens qui viennent les y aider. Le but du jeu est que les Derdians construisent ce pont en carton entre 2 tables espacées de 80 cm sous la direction des ingénieurs, cela dans un temps limité, avec l’objectif qu’ils deviennent autonomes sur la réalisation de ce type de construction.

Petits problème : les Derdians ont des us et coutumes que les ingénieurs ignorent (on a passé un bon moment à les assimiler en l’absence des ingénieurs occupés à définir leur stratégie de construction dans une autre pièce). Exemple : un homme Derdian refuse de parler à un homme qui ne lui a pas été présenté par une femme. Certains objets sont considérés par les Derdians comme « sexué », un homme Derdian refusant de manipuler une règle ou un crayon. Pour ne rien arranger, lorsqu’on ne respecte pas ses us et coutumes, le Derdian hurle.

Forcément, tout ça était très déstabilisant pour nos ingénieurs, qui malgré leurs excellentes capacités d’adaptation ont eu énormément de mal à démarrer le projet et à le faire avancer. Le pont a certes fini par être construit, mais dans la panique avec une autonomie atteinte proche de zéro.

Les observations :
  • Certains membres de l’équipe d’ingénieurs, échaudés par leurs premiers essais de communication, se sont mis en retrait pour échapper aux cris des Derdians. Ils ont utilisé l’intermédiaire d’un membre de leur équipe qui a réussi à entrer en communication avec les villageois.
  • Dans un premier temps, l’ingénieur entré en communication avec les Derdians leur parlait comme s’il parlait à un jeune enfant ou un vieillard : fort et distinctement alors qu’ils parlent la même langue.
  • Il a fallu beaucoup de temps pour que les ingénieurs posent des questions simples aux Derdians sur leurs usages comme « Mais qu’est-ce qui te gêne dans le fait d’utiliser cette règle et ce crayon ? ».

Le premier usage qui vient à l’esprit est la préparation d’une équipe projet qui devra collaborer en mode offshore. Mais après debrief, il me semble qu’on peut également l’utiliser pour mettre en relief les conséquences d’écarts de culture plus subtils comme ceux qui peuvent exister même entre 2 services d’une même entreprise.

Le message que je retiens au final de cet excellent jeu : inutile d’attaquer une réalisation en équipe sans s’assurer qu’on se comprend mutuellement.

Un site ressource : http://www.etudiantsetdeveloppement.org/article/animer-un-jeu-sur-linterculturalite

« Minimum Viable Product » (proposé et facilité par Alfred Almendra, testé par Grégoire)

Alfred nous a proposé un cocktail « MVP » intéressant. L’utilisation de plusieurs outils successifs en groupe restreint (4 à 6 personnes) permet d’obtenir (très) rapidement un produit cohérent.
L’objectif est de pouvoir valider au plus tôt l’existence d’un besoin et l’adéquation avec la solution imaginée.
Les étapes :

  • Création d’une Empathy Map
  • Écriture d’un (micro) elevator pitch
  • Création de mockups papier et des enchainements d’écrans
  • Confrontation des résultats à l’avis d’un utilisateur potentiel, puis amélioration avant nouvelle confrontation.

Notre expérience consistait en la création d’un GPS pour cyclistes urbains souhaitant favoriser les trajets « verts ». Résultat étonnant, de belles idées, de beaux designs …. rapidité, efficacité, convivialité !

Cette démarche est une combinaison d’activités parmi d’autres et montre une nouvelle fois qu’il est possible de créer énormément de valeur sur un temps très court !

La Crevasse (proposé par Olivier Soudieux, facilité par Frédéric Dufau-Joël)

Ce jeu a été plébiscité par ceux qui y ont participé, sans doute à peu près tout le monde au final, car il a été joué au moins 3 fois sur les deux jours. Merci à Fred d’avoir animé cette ultime session.
Ce jeu se pratique par binôme, l’idée étant de faire évaluer par chaque binôme sa capacité à franchir un obstacle (jusqu’à quel degré de difficulté parviendrons nous?), puis de tenter un niveau modeste, avant de passer au suivant.
La photo illustre bien ce jeu, les deux participants s’appuient l’un sur l’autre et ne parviennent a franchir l’obstacle que si la position est bonne mais surtout si la confiance en soi et en l’autre est réelle.
Le jeu est à la fois fun et riche d’enseignement. Il a généré beaucoup de discussions autour de la confiance, de l’apprentissage, et de la force des succès (même les petits succès).

Fearless Journey (proposé et facilité par Gilles Mantel, testé par Pierrick)

Tiré du livre « Fearless Change » de Mary Linn Manns et Linda Rising, ce jeu nous propose d’aborder les 50 stratégies du changement sur un cas concret par le jeu. Les participants se mettent d’accord sur un but à atteindre (pour nous : « Que l’évènement Agile Games France passe au JT »). Le but est d’atteindre l’objectif en surmontant les obstacles soumis par les membres de l’équipe en adoptant une des stratégies que l’un ou l’autre à en main (cartes à jouer).

Ce jeu est de mon point de vue un excellent moyen d’apprentissage des concepts du livre (que je n’ai pas lu). On peut également utiliser les cartes seules pour générer de la créativité d’une équipe devant conduire un changement et débloquer une situation. En effet, il permet à chacun de voir les problèmes sous plusieurs angles et déclenche des discussions productives.

Le site du livre : http://www.fearlesschangepatterns.com/

Le site du jeu : http://fearlessjourney.info

Lego4Kanban

C’est un prototype de jeu que nous avons créé et que nous avons souhaité expérimenter à Agile Games France pour savoir si il pouvait atteindre notre objectif : répondre au besoin de certaines équipes Scrum formées via le Lego4Scrum souhaitant explorer la voie Kanban en leur faisant vivre l’expérience Kanban sur la même réalisation.

Nous avons mis en place un Kanban minimaliste avec des limites de WIP, une réunion d’amélioration cadencée toutes les 7′ (objectif pour cette réunion : trouver une action d’amélioration sur la base de l’observation du kanban), un Product Owner (un participant), un coach Kanban (un facilitateur) et une personne chargée de relever les temps de cycle des User Stories livrées (un facilitateur).

Pas de revue, la récolte de feedback se fait au fil de l’eau par l’équipe sur chaque réalisation. Idem, la priorisation se fait au fil de l’eau lorsque des slots se libèrent dans la colonne d’entrée du Kanban.

Après 2h de jeu + debrief, voici ce qui en ressort :

L’équipe a été moins efficace qu’une équipe Scrum :

Normal : Scrum fournit un cadre projet optimal dans la plupart des cas, Kanban permet de faire émerger un cadre adapté à son contexte et ne fait qu’enclencher un cycle d’amélioration continue. Dans le cadre du jeu, Scrum est efficace, donc si on choisit Kanban, on part de plus loin. Par exemple, un des problèmes principaux de l’équipe a été l’occupation du Product Owner, qui avait beaucoup de mal à répondre à toutes les sollicitations des équipiers le sollicitant constamment pour demander d’expliquer une User Story à réaliser ou pour obtenir du feedback sur une User Story développée, et ce, souvent en même temps. Scrum répond à ce problème en groupant ces activités : on explique toutes les réalisations lors de la planification (ou du moins la plus grosse partie), et on regroupe l’obtention du feedback sur l’ensemble des User Stories d’un sprint (lors de la revue de sprint).

La qualité a été meilleure (meilleure adéquation avec les attentes du PO)

Tiens !? Eh bien oui : sur Lego4Scrum, on est souvent amené en tant que facilitateur à rappeler que le PO est là et prêt à répondre aux questions des développeurs, chaque sprint (surtout les premiers) donnant lieu à un mini effet tunnel où les développeurs ne se rendent compte qu’il sont à côté de la plaque qu’à la revue de sprint. Là, c’est tout le contraire : les développeurs n’ayant que très peu d’info au départ et en l’absence de revue, ils prennent touteur de suite l’habitude de collaborer (très) intensivement avec le PO. Communication coûteuse mais payante.

La notion de flux tiré n’a pas vraiment été ressentie

L’équipe de dev en difficulté n’a pas été en mesure de tirer du travail. Seul notre PO a dû ressentir cet effet (tiens, j’ai oublié de lui demander, Vincent si tu m’entends …).

L’amélioration continue n’a que peu été ressentie

Pourtant, en tant qu’observateur, j’ai trouvé que ce n’était pas si mal : l’équipe a revu une limite de WIP, appris à mieux utiliser une colonne file d’attente (attendre que le PO tire les US dans la colonne dev terminé plutôt que de courir vers lui avec la US à valider) et fait émerger un nouveau rôle d’assistant PO. Certes, les résultats de ces essais n’étaient pas spectaculaires, mais c’est déjà quelque chose, et le temps de cycle commençait même à se stabiliser voire à diminuer.

Conclusion : nous ne jouerons pas ce jeu pour le but initial de faire découvrir Kanban à une équipe Scrum car il génère de la frustration chez les participants qui ont l’impression de « patauger » dans leur organisation. Mais cette frustration pourrait être utilisée dans certains cas comme par exemple pour faire prendre conscience à une équipe qui réclamerait Kanban plutôt que Scrum pour un projet de 3 mois (« parce que Kanban c’est plus léger que Scrum ») que Kanban est un investissement plus long terme.

Question qui reste en suspens : comment faire comprendre sur le temps d’un jeu que les retours de Kanban sont inestimables : une meilleure appropriation du processus émergent, et une plus grande capacité des équipes à s’améliorer. Pour ces derniers points, atteint-on la limite d’un jeu sur une durée courte ?

Bilan

Pierrick : 5/5 en terme de retour sur temps investi pendant ces deux jours, y compris pour la partie « off » (repas, jeux de société le soir) pendant laquelle j’ai eu plaisir à passer un moment simple avec ces personnes que j’apprécie. À froid, après un petit débat sur les résultats de la rétro, il me semble qu’il n’y a pas d’amélioration majeure à apporter au format de cet évènement. Comme l’a très bien dit Gilles, en voulant faire des améliorations à la marge, on risque de baisser la satisfaction globale. Pour aller plus loin, on pourrait réfléchir à comment faire en sorte que les participants à Agile Games France (qui prend le chemin de devenir un rendez-vous annuel des experts du jeu agile) pourraient unir leurs forces pour générer de l’innovation : si le partage est riche, on voit peu de création sortir de ces rendez-vous, alors qu’en ayant appris à connaître les participants, je suis certain que le potentiel est énorme ! Vivement l’an prochain.

Grégoire : Intense et enrichissante expérience : 60 participants impliqués, des jeux matin midi et soir, des jeux connus, des jeux en création, des jeux aboutis ou en amélioration, des jeux détournés, des jeux courts, des jeux longs,…. et une organisation que je me garde d’essayer de définir mais d’une efficacité redoutable !
Merci à tous et en particulier à Lan qui n’a pu être présente que la première journée et qui a pris le temps de me donner son feedback sur un concept de jeu sur la compétition individuelle Vs la performance d’équipe.

Play Again !!  (#AgileGamesFr)

Les autres compte-rendus de l’évènement :

 

Les commentaires sont fermés.