Meetup Agile Bordeaux 24.1

 

[English version below]

Mardi dernier, vous avons expérimenté dans le cadre du Meetup Agile Bordeaux 24.1 l’atelier créé par Ben Linder sur la gestion de problèmes nommé Impediment Board Game.

L’ordre du jour était donné : Expérimenter cet atelier fraichement acquis (et pour seulement 15€, je conseille cet investissement à tout le monde, surtout lorsque l’on pense au travail nécessaire pour créer un atelier).

Je remercie donc les 12 valeureux cobayes qui se sont joint à moi pour cette expérience. Merci Adrien, Alain, Alexis, Alice, Carole, Caroline, Helie, Jean-Marc, Nazha, Patrick, Vanessa, et Wilson.

Cette édition hébergées par Randstad Digital (merci Laurence) m’a fait d’autant plus plaisir que cela faisait un moment maintenant que nous n’avions pas proposé ce type de soirée en présentiel.

L’enjeu de cet atelier est donc d’apprendre à collaborer pour gérer des problèmes et s’améliorer dans cette pratique, de façon collaborative.
Il est basé sur une dynamique de jeu de l’oie et s’articule autour de 3 supports principaux :

• Un ensemble de 79 problèmes (qui peuvent d’ailleurs être acquises à part) qui correspondent à un ensemble de situation déjà rencontrées par Ben, et qui porteront les échanges collaboratif autour de leur gestion possible
• Un ensemble de carte “chance” qui, à l’instar du Monopoly, ne sont pas toujours des chances 😅
• Un plateau de jeu de l’oie adapté par Ben pour porter l’atelier

En ce qui me concerne, j’ai trouvé cet atelier très intéressant, en particulier dans la découverte de stratégies de gestions de problèmes auxquelles je n’aurais pas pensés par moi-même. C’est toujours là l’intérêt du collectif ! Mais aussi, dans le support qu’il propose pour faire grandir une équipe dans une compétence essentielle qui est sollicité quasi-quotidiennement : la gestion de problèmes en s’appuyant sur le collectif.

Après cette première expérimentation (et sachant que je vais proposer cet atelier dans le cadre d’Agile Game France à Valence dans moins d’un mois), voici ce que je vais faire évoluer dans son animation :

• L’atelier est basé sur la dynamique d’un jeu de l’oie.
  Je me suis un peu trop attaché à cela. Et j’ai fait patienter les participants pendant que les autres équipes traitaient leurs problèmes. Cela a généré quelques frustrations inutiles chez les équipes qui tombaient sur des cases sans activité prescrites.
  Avec le recul, je ne bloquerai plus le jeu pour cela.
  A y réfléchir, c’est d’ailleurs la vie des projets : les équipes ne s’attendent pas entre elles. Lorsque les choses se passent bien pour une équipe, elle n’est pas ralentie jusqu’à rencontrer un problème.
  Mes prochaines animations se baseront donc sur ces principes :
  • C’est votre tour (on conserve le fait que le dès tourne dans le sens horaire)
    • soit vous êtes dispo et vous lancez le dès pour tenter d’avancer
    • soit vous transmettez le dès à votre gauche
  • Cela implique qu’il est normal qu’une équipe qui tombe sur une case neutre puisse rejouer quasi instantanément si toutes les autres équipes sont occupées à gérer leurs problèmes
  • Cela implique aussi que chaque équipe n’aura que la pression qu’elle se mettra elle-même sur le temps consacré à la gestion d’un problème
• L’atelier est aussi basé sur l’élaboration d’hypothèses d’expérimentations possibles face à un problème.
  Sur ce point, j’ai eu tendance à être un peu large dans l’acceptation des actions, hypothèses d’impacts, et critères d’acceptation. Je les ai questionnés à l’occasion en passant au sein des groupes, mais finalement, j’envisage à présent de tous les chalenger.
  Autrement dit, lorsqu’une équipe estimera être venu à bout de la gestion d’un problème, nous ferons un break pour l’équipe expose son problème, et ce qu’elle a prévu pour le gérer. Tout un chacun pourra alors faire des feedbacks et éventuellement des préconisations.
  Sur ce point, il faut encore que j’identifie comment valider la gestion d’un problème de façon la plus “objective” possible. Il ne s’agit pas qu’une équipe un peu trop compétitive ne bloque systématiquement une autre équipe en faisant preuve de mauvaise foi.
  => Vous avez des idées ? N’hésitez pas à les partager : Chris
• Les problèmes rencontrés sont tous axés sur des problèmes qu’une équipe agile est susceptible de rencontrer. Sincèrement, sachant que je prévois principalement d’exploiter cet atelier avec des équipes que j’accompagne, ce n’est vraiment pas un problème. Bien au contraire.
  Si vous l’utilisez dans un contexte mixte (agilistes/curieux), n’hésitez pas à rappeler que les agilistes ont la responsabilité d’éclairer les non-agilistes curieux autour du vocabulaire qui pourrait leur sembler abscon.
  Par contre, il s’agit de problèmes “hors-contexte”. Cela implique que face à chaque problème, l’équipe doit rapidement se mettre d’accord sur un contexte d’apparition de ce problème.
  -> Je n’ai manifestement pas été assez clair sur ce point lors de l’explication des règles. J’y prêterai attention sur mes prochaines itérations pour éviter un léger flottement en début de partie.
  => En fait, pour clarifier les choses, j’envisage de donner un exemple complet de traitement d’une carte problème lors de l’explicitation des règles.
  Pour être transparent, ceci est clairement expliqué dans le support “handout” que j’ai hésité à mettre à disposition juste parce qu’il était en anglais : j’ai eu tort.
• Un dernier point purement technique : les rôles de timekeeper et de banquier (pour gérer les récompenses/investissements) sont initialement attribués à des participants. J’assumerai ces rôles en tant que facilitateur à l’avenir afin de permettre à tous les participants de rester impliqués au sein de leurs équipes.

En bref, cet atelier s’appui principalement sur les échanges possibles autour des cartes “problème”, mais le plateau, et surtout les cartes chances, apportent une dynamique très riche.
J’ai vraiment kiffé la carte “chance” obligeant à revoir une gestion de problème précédemment traitée sous un autre angles. Les expérimentations qui en émergent sont tellement plus riches.

J’ai hâte d’exploiter à nouveau cet atelier !

Alexis nous a aussi fait un retour sur cette soirée : Merci Alexis.

Merci Anaïs pour la soirée passée avec moi sur le découpage des supports, et merci Kim pour la relecture de ma traduction.

 

In English:

Last Tuesday, we experimented during  Meetup Agile Bordeaux 24.1 the workshop created by Ben Linder on impediments management called Impediment Board Game.

The agenda was fixed : To experiment with this newly acquired workshop (for just 15€, I advise this investment to anybody, at least when you think of the work needed to create a workshop).

I thank the 12 test subjects who joined me in this experiment. Thank you Adrien, Alain, Alexis, Alice, Carole, Caroline, Helie, Jean-Marc, Nazha, Patrick, Vanessa, and Wilson.

This meetup hosted by Randstad Digital (thank you Laurence) was a real pleasure, especially because we didn’t offer such a face to face event for a while now.

The purpose of this workshop is to learn to collaborate to manage impediments and to improve in doing it, in a collaborative way.
It’s based on the rules of the game of goose and use 3 main supports :

• a deck of 79 impediments (which can be bought on their own) which describes impediments that Ben already met in teams, and which will drive the production of collaborative ideas to manage them
• a deck of “chance” cards which, as in Monopoly game, are not always lucky 😅
• a board from the game of goose adapted by Ben to handle the workshop

For my part, I founded this workshop very interesting, especially for discovering strategies to manage impediments I wouldn’t think about on my own. It’s the main advantage of collective work!
It’s interesting too in the way you can use it to level up a team in an essential skill used quite daily : a collective management of impediments.

After this first try (and knowing I will offer to discover this workshop during the next Agile Game France in Valence this month), here is what I will change in my facilitation :

• The workshop is based on the game of goose rules.
  I took that point a little bit too seriously and I asked the participants to wait until other teams finished to managed their impediments. Teams who didn’t meet problems were frustrated and it wasn’t useful.
  With this experience, I won’t stop teams anymore.
  And finally, it’s the life of project : Teams don’t wait for each other. When everything goes well for a team, it doesn’t slow down until it meets an impediment.
  My next facilitations will include these principles :
  • When it’s your turn (we keep the fact to turn in clockwise)
    • either you can play and you launch the dice to try to go on
    • or you push the dice to your left
  • This implies that a team which falls on an neutral box can replay quite immediately if all other teams are focused on an impediment management
  • This also implies that each team will just have the pressure they put on themselves for the time they allow to manage a problem
• The workshop is based on the development of hypothesis of possible experimentations facing an impediment.
  On that point, I accepted some actions, impact hypothesis, and acceptance criteria too easily. I challenged it when I passed in different teams, but finally I think to challenge all of them now.
  In other words, when a team will think they have managed an impediment, we will all have a break to allow the team to share how they managed it. Everybody will be able to offer feedbacks and advice.
  On that point, I still have to find a way to validate a solution as “objectively” as possible. I don’t want to have a competitive team which always stops other teams just to win.
  => Do you have any ideas? Don’t hesitate to share them: Chris
• The impediments are based on agile teams contexts. To be honest, it’s not a problem for me as I want to exploit this workshop with agile teams’ coaching. It’s even a good point.
  If you use it in a mixed context (agile people/non-agile people), remember that for the agile people they have the responsibility to explain specific words to non-agile people.
  But the impediments are given without context. That implies when facing each impediment the team has to quickly find and agree on a context for this impediment.
  -> I wasn’t clear enough on that point when I gave the rules. I will pay more attention on this point in the future.
  => In fact, to clarify things, I think I will give a full example of managing an impediment during the rules explanations.
  To be honest, it’s clearly explained in the “handout” support, but I hesitated to give it as it was written in English : I was wrong.
• A last point that is just technical : the timekeeper and bank manager roles (to manage rewards/investments) are assumed by participants in the rules. I will assume those roles in the future to allow participant to stay focused on their contribution inside their teams.

To conclude, this workshop is mainly based on exchanges between people around impediments cards, but the board and more over the “chance” cards bring a richer dynamic.
I really loved the “chance” card asking participants to re-think a problem they already solved, using another point of view. New solutions are so much more powerful.

I’m eager to use this workshop again!

Alexis offered us a feedback on this evening. Thank you Alexis.

Thank you Anaïs for the evening spent with me to cut all the supports, and thank you Kim for the corrections of my translation.