2 Jours à l’Agile Tour Nantais 2022 - Gunther La Licorne

Les 3 et 4 Novembre dernier se tenait l’Agile Tour Nantais 2022 à l’IUT de Nantes.
Cette année le thème était :

Valeur et agilité ?

Si je vous dis : “valeur et agilité ?” Avez-vous pensé immédiatement aux 4 valeurs du manifeste agile ? Et c’est peut-être là une source de confusion ! Si vous relisez le premier principe, il est question de livrer des fonctionnalités à haute valeur ajoutée. Et si on parle de Scrum, il y a aussi 5 valeurs. Pis, si on parle de code, certains estiment la valeur au nombre de lignes…Il y a de quoi y perdre son Latin UTF8 !

Et VOUS, comment vivez-vous cette notion de valeur en agilité ? Comment cela s’exprime-t-il au quotidien ? Venez partager votre vision de la valeur, en participant à des ateliers ou des conférences autour de ce sujet, qui nous glisse entre les doigts dès qu’on pense l’avoir saisi =)

Et surtout, demain, de retour dans vos équipes, qu’allez-vous en faire ?

Nos 4 membres Nantais de la Practice Agile ont eu la chance d’y participer. Nous reviendrons à travers cet article sur les principaux talk et ateliers qui ont retenu notre attention.


Nous vous proposons une série de 3 articles consacrés à ces deux jours.
Ce troisième et dernier article sera consacré à Gunther le Jeu.
Vous trouverez l'article dédié à la journée du Jeudi ici et le second article sur la journée du vendredi ici.


Gunther, c'est LA découverte pour les Ippons de cet Agile Tour Nantais 2022.

https://www.gunther-le-jeu.fr/

https://twitter.com/techsys_fr/status/1588523414922596353?s=20&t=OK6UavrDcAsdnWCHE_NRCA

Gunther la Licorne est un jeu créé par les équipes de passionnés de chez TechSys :

“Gunther-le-jeu est un jeu de plateau issu du serious gaming, on y parle de DevOps et d’Agilité, de comment améliorer tout ça, par où commencer, éviter les pièges, …C’est à destination des organisations qui abordent le DevOps d’une façon ou d’une autre, ou tout simplement des personnes qui souhaitent en apprendre plus sur ce mouvement culturel.”

Ce jeu de plateau met en scène une équipe IT composées de devs et d’OPS, séparés par le mur de la honte qui les empêche de communiquer (au début en tout cas).
Leur objectif : réussir à développer et à mettre en production les besoins clients, sans atteindre les limites de WIP (Work In Progress), ce qui serait synonyme de défaite.
Ces besoins clients seront représentés par des blocs en plastique d'une grande marque.
Le jeu est constitué d’un plateau qui représente les étapes de développement successives :

Etapes de développement :

  • Backlog
  • En cours de Dev
  • A packager

Etapes OPS :

  • Intégrer
  • Meper (du verbe “mettre en prod” bien sûr).

Ce plateau évoluera au cours des phases pour venir ajouter des étapes.
Exemple : "À tester" pour les devs, "à monitorer" pour les OPS.

En plus du plateau, deux totems gradués de 1 à 7 représentent le RUN (les anomalies de prod) et le RISK (en 3ème phase).
Pour les devs, la WIP Limit prend en compte les blocs présents dans un groupe d’étape.
Pour les OPS, c’est identique mais on y ajoute la valeur du Totem de RUN.

Chaque joueur possède un jeton représentant son rôle (DEV, OPS) qu’il placera sur l’étape sur laquelle il souhaite travailler durant le tour.

Chaque phase comprend plusieurs tours de jeu.


Déroulé d’un tour :

  1. Chacun choisit son action de travail. Les DEVS peuvent coder ou packager ; les OPS peuvent intégrer, meper ou s’occuper du RUN (ce qui aura pour effet de retirer 1 au totem en question)
  2. On réalise les actions en partant de la prod (les OPS en premier) : donc les blocs avancent sur les étapes jusqu’à finir en production appelée et représentée “Poubelle de prod”.
    Chaque bloc arrivant en prod ajoute 1 au totem de RUN.
  3. Calcul des WIP Limit. Si dépassement, c’est la défaite
  4. Un événement externe se produit :
             # +1 ou +2 en RUN
             # Apparition d’un bug de prod (ajout d’un bloc en Todo) qui peut être                       bloquant ou non (à traiter obligatoirement en priorité ou non)
             # Un membre tombe malade et ne jouera donc pas au prochain tour

Nous étions 4 joueurs (2 DEVS et 2 OPS) pour cette partie, qui s’est déroulée en trois phases.

1ère Phase

Une seule règle pour cette première phase et pas des moindres : interdiction de se parler (bah oui y a le mur de la honte…), mais on est aussi dans des “bureaux différents”, donc pas moyen de se parler même entre DEV ou entre OPS.
Donc chacun choisit ce qu’il fait, sans savoir ce que font les autres.
Attention spoiler alerte !
Sans communication, on perd très vite cette phase et bien sûr c’est voulu.
On se lève et on va débriefer, la conclusion est unanime, on a besoin de parler.
On nous propose aussi de choisir des améliorations pour la prochaine phase : 8 idées devant nous, 4 bonnes réponses et 4 mauvaises réponses.
Cela nous permet de débloquer notre premier item de Licorne (qui n’a aucune incidence, c’est le fil rouge du jeu, devenir une licorne en s’améliorant)

2ème Phase

Cette fois-ci, les DEVS peuvent se parler, les OPS peuvent se parler, mais le mur de la honte est toujours présent entre les DEVS et les OPS. Et au-delà de nous empêcher de communiquer, chaque groupe ne voit pas ce que fait l’autre non plus.
Le plateau a évolué ! Une nouvelle étape pour chaque groupe : “A tester” pour les DEVS, “à monitorer” pour les OPS.
Ces nouvelles étapes sont facultatives et peuvent être passées.
Le cas échéant, la valeur du totem de RISK sera incrémentée de 1.
Mais à quoi sert ce totem du RISK ?
Si sa valeur dépasse 2, les événements externes à chaque fin de tour augmente en gravité (moyennement difficile).
Si le risque dépasse 4, les cartes passent en mode “très difficile”.

On constate une amélioration par la communication entre OPS ou entre DEV : meilleure répartition et synchronisation. Par contre, on ne sait pas ce qu’il se passe de l’autre côté du mur, donc les OPS ne peuvent pas prévoir ce qu’il vont recevoir dans les prochains tours, et les DEVS ne se rendent pas compte si le travail s’accumule de l’autre côté, et peuvent donc faire dépasser WIP Limit des OPS.
Mais avec ce mur et un OPS malade trop souvent, les Devs poussent trop de blocs côté OPS et la WIP Limit dépasse la limite. Comme dans la réalité, c’est la faute des dévs :)
Nouveaux debriefing, nouveau totem de licorne et début de la troisième phase !

3ème Phase

Le mur de la honte a disparu : nous pouvons enfin communiquer librement !
De plus, une nouvelle option a chaque tour est disponible : faire de l’amélioration continue (ça commence à ressembler à une équipe tout ça !).
Ces améliorations ont comme conséquences :
- Les anomalies bloquantes ne sont plus à traiter
- Les cartes “+2 RUN” n’ont plus d’effet
- On automatise les tests (on saute donc cette étape sur le plateau)
- On automatise le monitoring
- etc…

L’équipe de DEV peut maintenant utiliser des package applicatifs : il est désormais possible de mettre jusqu'à 5 blocs/besoin en prod en une fois plutôt que un par un, mais attention, la valeur du package correspond au nombre de blocs dans le compte des WIP Limit.

On va rapidement miser sur ces nouvelles améliorations pour nous permettre de nous concentrer sur notre chaîne de travail qui apporte de la valeur (tiens tiens, comme par hasard).
Avec la communication et ces améliorations, tout se passe bien mieux, mais on a quand même réussi à perdre… Alors que cette phase est réalisable contrairement aux précédentes qui étaient là pour nous pousser à l’erreur et ensuite de comprendre pourquoi.
Notre erreur ? Une petite erreur de calcul sur une WIP Limit, un package de 5 blocs qu’on pensait de 4.


A ce jour, les équipes de Techsys travaillent encore sur le jeu, il n’est donc pas commercialisé mais on espère que vous aurez la chance de l’essayer sur un Agile Tour ou autre événement.

Chez Ippon, on va se tenir au courant car on a hâte de voir l'évolution du jeu et aussi très envie de le faire essayer à nos collègues !