Product Tank #16 : des produits et des jeux

La gamification était bien le thème de cette nouvelle rencontre. Avec 2 interventions très enlevées.

Siffler en travaillant, avec Anna Livia Gomart-Cardin

Anna Livia nous vient du marketing du jeu video, et elle va décortiquer pour nous certains mécanismes du jeu ! Pour commencer, elle distingue 2 notions :

  • « play » : sans règle
  • « game » : avec des règles

Les raisons principales qui nous conduisent à jouer sont aussi au nombre de deux :

  • On est très bon à ce jeu : on joue pour le plaisir, parce que cela met en avant nos compétences.
  • Pour apprendre, acquérir des compétences ; pour une vision de soi une fois ces compétences acquises.

Le jeu, c’est également le fun. Il provient de la vision, du sens que l’on donne à notre travail. Les chants de marins symbolisent l’engagement, le plaisir de l’action. Ce sont 4 types de « fun » que distingue Ann Livia :

  • « easy fun » : un moment sympa, facile.
  • « hard fun » : des moments qui nous grandissent. C’est la raisons pour laquelle on peut faire des mots-croisés, par exemple.
  • « fun social » : pour apprendre des autres
  • « fun sérieux » : des apprentissages qui servent hors du contexte d jeu.
image

Lire la suite

Agile Playground #19 : austèrement Kanban !

Je ne sais si ce début d’année est synonyme de démarrage en douceur, mais j’ai tendance à trouver nos premiers meetups doucement fréquentés…
Deux jeux au programme de cette 19ème édition et un ice-breaker !

image

Pendant que la glace fond…

L’ice-breaker, c’est en passe de devenir une tradition à l’Agile Playground ! Aujourd’hui, c’est au pied levé que Franck Beulé nous propose une petit activité pour mieux mémoriser le nom des autres participants. C’est là que je m’aperçois que je connais effectivement trois-quart de l’assemblée. Dois-je m’en inquiéter ou m’en réjouir ? Cela reste à déterminer…

image

Arrive le moment du choix : 2 jeux nous sont proposés :

  • Un « business value game » d’un côté.
  • Un « FeatureBan » de l’autre.

Le choix est plus cornélien qu’il n’y parait. En effet, si je connais le Business Value Game, j’ai du mal à apprécier celui-ci. Mais c’est peut-être que mon animation n’est pas au point. Aussi aimerais-je un de ces jours voir comment d’autres l’animent.

Mais ce ne sera pas pour aujourd’hui. Christophe Keromen nous propose un Featureban, qu’il nous présente comme une version austère des jeux Kanban. La tentation est trop grande pour moi !

image

Expérimenter Kanban avec Featureban

Le jeu que nous propose Christophe est une adaptation de celui de Mike Burrows. On peut trouver toutes informations nécessaires et les liens utiles sur le blog de Christophe.

Le principe est simple, simplifié à l’extrême même: Un Kanban avec 4 états et des pièces à passer à « terminé ». Tout est anonymisé : les étapes et les pièces (de simples pièces de Lego). Des tirages au sort déterminent si la pièce peut avancer (ou se débloquer selon le cas) ou se bloquer. Nous jouerons plusieurs expérimentations et comparerons celles-ci sur la base du nombre de pièces terminées et de l’en-cours. Nous formons deux tables, la première, animée par Christophe génèrera de nouvelles séries de tirages à chaque tour, tandis que la seconde (celle où je vais jouer) réutilisera la même série de tirages à chaque expérimentation. C’est Olivier qui animera cette table.

image

Premier tour

Sur ce premier tour, chacun joue pour soi (nous avons de pièces de couleur différente pour nous différencier), il n’y a pas de limite de WIP.

image

Le résultat obtenu n’est pas à la hauteur de nos espérances :

  • Nous sommes frustrés de ne pouvoir agir sur les autres pièces lorsque des opportunités s’offrent à nous.
  • La « double peine » nous obligeant à faire deux tirages « face » consécutifs biaisent un peu le jeu à mon avis.

Bref, pas beaucoup de pièces finies et un gros en-cours à la fin de ce round !

image

Second tour

Lors de ce tour, nous voulons observer l’impact d’une limite de WIP (limite de 3 dans les 2 étapes d’en-cours). Toutefois, les joueurs continuent à ne traiter que leurs pièces !

image

Résultat pas très convainquant sur ce round : le nombre de pièces terminées reste le même ! Par contre notre en-cours baisse sensiblement. Nous apprenons quelque chose au passage : grâce à la limite de WIP, quand on atteint les limites d’en-cours, un mauvais tirage peut avoir un effet neutre au lieu d’avoir un effet négatif !

Mais nous restons frustrés de ne pouvoir fluidifier le système en jouant n’importe quelle pièce !

image

Troisième tour !

Nous décidons (comme la fois précédente) de ne changer qu’un seul paramètre pour mieux observer l’influence de celui-ci ! Ici, nous ouvrons à tous les joueurs la possibilité de jouer n’importe quelle pièce. Enfin ! Par contre, nous gardons les limites de WIP du tour précédent.

Cette fois le nombre de pièces terminées augmente très sensiblement. Et non seulement nous jouons les pièces des autres, mais nous collaborons beaucoup plus afin de nous aligner sur une stratégie commune ! Bref c’est bien plus fun. Nous avons hacké le jeu qui devait être austère !

image

Notre capacité est plus grande, une fois que nous avons élargi notre capacité d’action. Mais cette foi, c’est notre limite qui nous parait trop basse !

Quatrième tour…

Pour ce dernier round, nous avons augmenté notre limite de WIP de manière très importante (nous l’avons doublé sur les 2 steps). Notre jeu gagne en fluidité, car nous sommes déjà très bien alignés sur la stratégie. Nous augmentons un peu notre réalisé, mais pas autant que nous l’avions imaginé. En effet la neutralisation des mauvais tirages joue moins lorsque nous augmentons notre limite de WIP !

image

Nous arrêtons là, en envisageant toutefois une expérimentation supplémentaire dans laquelle nous abaisserions la limite sur le step 2, afin de saturer plus facilement le premier step (si, si) et d’avantage neutraliser les mauvais tirages. Vous n’avez probablement rien compris à ma dernière phrase ? Vous n’aviez qu’à être avec nous !

Debrief

La première table a effectué de nouveaux tirages à chaque round. Cela a beaucoup handicapé leur capacité à tirer des enseignements de chaque changement. Ainsi nous pensons que conserver les mêmes tirages est un facteur important de ce jeu.

Par contre, ils ont rapidement hacké la règles des mauvais tirages, une liberté que nous ne nous sommes pas accordé. Il aurait été intéressant de tester cela. Peut-être faut-il clarifier la latitude des changements possibles ?

image

En bref, sur le jeu nous avons pensé que :

  • Il n’est pas adapté à ceux qui découvrent complètement Kanban. Il est trop abstrait pour cela. Kanbanzine ou Getkanban feront mieux l’affaire.
  • Les petites expérimentations très courtes qu’il permet sont excellentes pour découvrir et comprendre l’influence de chaque paramètre.
  • Ces mêmes itérations courtes donnent du fun, car une complicité s’établit entre les joueurs !

End of #19

Au playground, une soirée ça se termine par un buffet. On siffle une bière, malgré l’absence récurrente de décapsuleur et on partage nos expériences !

image

J’ai oublié d’évoquer le l’Agile Playcamp à venir. Un agile Playground sur une journée avec la participation exceptionnelle de Luke Hohman. C’est Greg Hutchings qui a rendu cet évènement possible. Cet évènement sera précédé la veille par une formation certifiante aux innovation games, toujours par Luke Hohman !

Agile Playground #18 : c’est mon tour !

Cela faisait un petit moment que je n’avais pas pris une part active à l’animation du Playground. L’occasion faisant le larron, la nécessité d’expérimenter un jeu autour de la mise en oeuvre de Scrum me donnait enfin l’occasion de prendre une part active à la soirée. Mais tout ceci n’est que vantardise de ma part : en réalité j’étais plutôt le co-animateur de ce jeu dont ma collègue Claire avait pratiquement fait tout le travail de préparation.

Mais revenons au début de cette 18ème rencontre. Une rencontre orchestrée par Cédric Chevalérias dans les locaux de Valtech que nous retrouvions ! Au programme : 3 jeux en parallèle et un Ice-Breaker.

Ice-Breaker : autour des rôles de Scrum

C’éait une demande venant d’Ideascale : faire un ice-breaker autour des rôles de Scrum. C’est Frank Beulé qui a relevé ce challenge en adaptant un autre jeu !

image

Ayant distribué des cartes aux différents participants, il fallait retrouver notre groupe et organiser nos cartes en une suite logique.

image

Enfin, le pitch avant les choses sérieuses.

image

A côté de notre « Live Scrum », il y avait un très attractif Sky Castle Game proposé par Yannick Quennec’hdu. Un jeu déjà pas mal éprouvé et très bien préparé: tables de jeux, cartes, Lego et tout et tout. Bref, quelque chose de bien attractif !

Etait également proposé un jeu autour du Story Mapping. Claire Léger s’essayait à l’animation de celui-ci.

Live Scrum !

Ce jeu a pour but de simuler les activités d’un projet Scrum : un backlog, un chiffrage et une priorisation de celui-ci. Puis, 2 itérations avec planning meeting, des sprints de 3 jours (avec leur stand-up), se terminant par une revue et une rétrospective. En fait, nous n’aurons le temps de ne faire qu’un seul sprint.

Petit comité autour de notre jeu clairement à l’état de MVP.

image

Nos buts premiers étaient de valider l’étude de cas travaillée par Claire, le timing des différentes phases et les difficultés de jeu que nous pouvions rencontrer.

image

Grand merci aux participants qui nous auront permit de noter des points importants :

  • L’étude de cas est complexe, mais sans l’être de trop. A garder !
  • Le timing doit être réviser. Le but est d’avoir des tranches courtes… mais pas trop quand même.
  • Mieux cadrer ce qui est attendu à chaque phase de jeu.
  • Clarifier explicitement l’objectif : la création d’une maquette et non un développement.
image

Le public de l’Agile Playground ne correspond pas nécessairement à celui des débutants que nous pouvons rencontrer en entreprise : parfois plus efficace, mais aussi s’enlisant parfois dans de longues discussions… Ils auront néanmoins produit un résultat tangible.

image

Fin de soirée

Que serait un Agile Playground sans l’indéracinable cocktail de fin de soirée ? J’avais prévu d’y amener une brioche maison, je l’ai ratée. Ce sera pour une prochaine fois.

image

Nous avons un autre jeu sur un thème complètement différent en cours d’élaboration, mais ce ne sera certainement pas disponible pour Janvier.

Formons-nous à Kanban avec le FKUG

Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.

image

Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !

Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.

Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

image

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

  • La qualité
  • Equilibrer le rapport demande / débit
  • Livrer souvent
  • Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

  • La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».
  • Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien…

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

  • Si notre flux de travail n’est pas équilibré.
  • Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

image

Commençons avec un tableau Scrum…

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

  • Voir ensemble
  • Agir ensemble
  • Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

  • Univoque
  • Visible
  • Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

  • Utile (ce qui n’est pas utile constitue une pollution)
  • Utilisable
  • Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l’Obeya

Que doit montrer d’autre notre management visuel ?

  • Les objectifs (le challenge)
  • Les règles
  • La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

  • De manière spontanée, durant l’itération, quand on tombe dessus !
  • En rétrospective
  • Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

image

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l’analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

image

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

image

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

image

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec’hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

image

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici…

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales.
Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

image

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

image

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

image

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

L’association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !

Agilité et hospitalité Libanaise

J’attendais cela depuis un moment, depuis le milieu de l’été pour être plus précis. Car Pierre Hervouet nous avait invité à venir partager avec la communauté Libanaise pour cette seconde édition de l’Agile Tour Liban ! Nous étions donc 4 Français à nous envoler vers le moyen-orient le vendredi matin pour une conférence qui se déroulerait en week-end.

image

La Suisse du Moyen-Orient offre des rivages cernés de montagnes. Le soleil s’y couche vite. Notre premier contact avec Beyrouth se fait au crépuscule. Qu’il s’agisse de quartiers islamique ou chrétiens, la vie nocturne est intense, mais bel et bien quadrillée de militaires ou de policiers dont l’équipement (étrangement semblable) ne laisse aucune place au doute.

image

L’hospitalité Libanaise est réputée, celle de l’hôte de la conférence est plus encore infaillible. Non seulement avons-nous été pris en charge par Rima, l’épouse de Pierre, dès l’aéroport, mais il nous invite dès le soir même à un diner entre speakers étrangers. Bâtiment ancien (il y en a), petite cours intérieure et large parasols de toile, nous laissons la ville nous imprégner de ses charmes.

Bienvenue à l’Agile Tour Beyrouth !

La conférence accueille cette année 130 personnes. Finalement, tous les billets auront trouvé preneur, même si il aura fallu attendre les deux dernières semaines pour en placer la plus grande partie ! Je dis « preneurs », mais je devrais aussi dire « preneuses », car la conférence affiche à vue d’oeil pas loin de 50% de public féminin ! Un sacré changement par rapport à nos conférences Françaises…

image

Le début est prévu pour 9h30. C’est l’opportunité de faire connaissance avec le concept du « 9h30 inch Allah ». Autant dire que nous n’avons pas du tout commencé à l’heure. Pierre Hervouet ouvre la conférence avec le discours d’accueil.

Outre la présentation de la journée, il met cette journée sous le signe du « Shu Ha Ri » … voilà qui met un peu de pression sur ma propre session, qui porte de facto l’emblème de cette journée !

image

Il est temps de présenter le programme, c’est la moment des pitches des sessions ! Nous sommes 14 speakers, ce qui est peu comparé aux Agile Tours Français. L’agilité est encore très peu développée au Liban, aussi n’y a-t-il que 7 présentateurs locaux. Les « internationaux » présenteront 2 sessions. Pour ma part, il s’agira du « Scrum Shu Ha Ri » le matin, et d’un Carpaccio game l’après-midi. Je ne suivrais donc pas beaucoup de sessions de mon côté.

image

En apéritif de la Keynote d’ouverture, nous avons deux sessions au format Lightning Talk, ou plus exactement de Type Pecha Kucha, donc 20 slides avec 20 secondes pour chacun d’entre eux sur une durée totale d’un peu plus de 6 minutes (si vous faites le calcul).

Pierre ouvre le bal.

Agile the Origin, par Pierre Hervouet

Pierre réussit un petit tour de force : nous présenter en 6 minutes, non seulement un bref historique du mouvement agile, mais aussi sa vision de ce qui est important dans l’agile :

  • Les livraisons fréquentes
  • Le focus sur la valeur métier
  • La communication et la collaboration
  • Le « team empowerment »
  • L’amélioration continue
image

Pour conclure, Pierre nous donne un exemple concret et personnel de la mise en oeuvre de ces valeurs : la construction de sa maison !

La vidéo est courte, n’hésitez pas à la regarder en entier. Voici également le support de sa présentation.

Scrum At a Glance, par Joanna Khoury

Il s’agissait lors de ses deux Pecha Kucha de présenter des fondamentaux de l’agile. Ainsi si Pierre nous a présenté les concepts fondamentaux, il revenait à Joanna de présenter Scrum, l’approche agile emblématique.

image

Pas de fantaisies dans cette présentation de Scrum « by the book ».Mais c’est bien ce qu’il faut pour mettre le pied à l’étrier d’une assistance qui en grande partie découvre l’agilité !

The Best Way to Convey Information, par Kimberly Samaha

Quelle est la valeur d’un face à face par rapport à un échange informatisé ? Mais aussi : l’échange informatisé peut-il apporter une valeur que n’apporte pas le face à face ?

image

J’ai eu un peu de mal à relier les fils du propos de l’oratrice, aussi vais-je en livrer quelques uns de manière déstructurée :

L’importance du contexte et de la perspective : Kimberly fait le rapprochement avec l’art, ou comment une partie du vécu de l’artiste transparait dans ses oeuvres (Velasquez, Francis Bacon). Il en va de même pour nous : il y a des éléments de nos intentions dans nos créations !

Arrêter de penser aux personnes comme à des objets : le contact avec d’autres personnes doit plutôt être perçu comme le déclencheur d’une expérience. La notion d’objectivité en prend un coup. Pour Kimberly Samaha, la vérité n’est d’aucune aide contre les perceptions.

Extreme Ice breaking

Joumana nous avait concocté un petit jeu, ou plutôt un grand jeu permettant à de petits groupes de se rencontrer. Autant dire qu’organiser une telle chose, surtout sur un temps limité était le gage d’un beau bordel ! Jugez-en

A mon grand étonnement (mais aussi avec une belle dépense d’énergie), Joumana est parvenu à mener la chose à bien. Je ne pense pas que j’aurais su en faire autant.

image

Ma propre session commence bientôt. Enfin j’imagine, car j’ai complètement perdu le fil de l’horaire.

Scrum Shu Ha Ri

J’avais déjà donné cette session au Printemps Agile, à Caen. Je l’ai un peu modifiée pour l’occasion, mais surtout traduite en Anglais.

image

Je publierai prochainement la vidéo montée lors du Printemps Agile (donc en Français). En attendant, vous pouvez trouver ici mon support de présentation (toujours en Français) et l’article que j’avais rédigé suite à l’évènement de ce printemps !

Agility for Customer Delight, par Mehmet Yitmen

Je n’ai pas regretté d’être resté dans la salle pour la session de Mehmet. Notre orateur est le chef de file de l’agilité en Turquie.

image

A l’aide d’histoires, Mehmet vient nous partager les enseignements tirés des réussites disruptives d’entreprises : comment Fuji, sur la base de sa réussite dans la production de film photographique est devenu numéro un au Japon des produits cosmétiques. Comment Zara à l’aide d’expérimentation et de cycle de feedback courts est-il parvenu à la réussite que nous connaissons.

Je vous invite à regarder cette intervention très inspirante !

Pause déjeuner

Elle sera assez courte, une heure seulement pour savourer l’excellente cuisine Libanaise. Nous aurons néanmoins l’occasion d’y revenir ce soir !

image

Une petite pause pour dévorer des yeux aussi.

image

La salle ouvre sur un balcon, un oasis de fraicheur.

image

Et voilà, c’est déjà fini ! Je vais rejoindre la session de Fadi Jeanbart.

Improve your Public Speaking Skills, par Fadi Jeanbart

Fadi est chanteur d’opéra. Il nous a d’ailleurs fait une petite démo à la fin : il est vraiment chanteur d’opéra, aucun doute ! C’est à la technique Alexander qu’il va nous initier aujourd’hui. Technique que lui-même applique et enseigne pour le chant.

image

Avoir une conscience aiguë de notre corps et comment celui-ci influe sur notre respiration et par voie de conséquences sur notre capacité à maitriser les sons, voilà l’objectif. Nous arriverons juste à prendre conscience de la difficulté du chemin à parcourir. Mais un chemin commence avec un premier pas.

Carpaccio Game

Le temps file à toute vitesse et voici pour moi la dernière session de l’après-midi. Dernière session, car le Carpaccio Game qui j’anime occupe un double créneau.

image

Il nous fallait de nombreuses machines pour l’atelier le plus « geek » de l’après-midi, car il s’agit bien d’un atelier de programmation. Grace à Pierre et aux bonnes volontés des participants, nous y sommes arrivés. Je vous parlais en début de post de la proportion de femmes à la conférence. Je vous laisse constater ce qu’il en fut à mon atelier.

image

Malheureusement, le timing déjà court s’est trouvé raccourcis par les retards pris et la contrainte de la keynote de cloture qui, elle, ne pouvait être décallée !

Keynote de clôture : Ken Schwabber

C’est via Skype que le co-créateur de Scrum a partagé avec nous cette fin d’Agile Tour. Une liaison Internet hélas pas toujours optimale.

image

Je vous laisse découvrir son propos. Il reste assez classique par rapport à ce qu’il nous a habitué. J’ai noté qu’il écornait SAFe au passage. On sait qu’il n’éprouve pas un grand amour pour le framework de Dean Leffingwell. Il défend plus que jamais son approche non prescriptive en regard des pratiques à adopter. Je ne saurias le lui reprocher, et c’est hélas mal compris par beaucoup de praticiens. Au fond, Scrum c’est un peu l’agilité pour les grandes personnes !

Pierre Neis avait hacké le Lean Kanban France pour saluer l’Agile Tour Beyrouth. L’agile Tour Beyrouth tenait à rendre la politesse à l’Agile Tour Brest qui se déroulait peu après.

image

Vous avais-je parlé du charme des Libanaises ?

En finir avec l’Agile Tour

Quand c’est terminé, ce n’est pas encore tout à fait fini : Pierre avait invité son collège de speakers goûter l’excellente cuisine Libanaise. On commence par se chauffer dans un bar en ville, on se croirait en France !

image

Soirée chaleureuse entre speakers. On échange nos impressions, nos expériences.

image

Comme si cette splendide hospitalité ne suffisait pas, nous avons aussi eu droit à des souvenirs : un petit livre édité par Rima et la série de sous-verres « Shu Ha Ri » ! Et je ne parle même pas du régal pour les yeux et le palais que fut ce dernier repas…

image

En attendant le retour…

Nous étions quelques uns à choisir de rester une journée supplémentaire sur place. Nous n’avions juste pas prévu le marathon de Beyrouth qui se déroulait ce dimanche. Début des hostilités à 5 heures du matin avec la musique à fond ! En regardant par la fenêtre, ça n’a pas l’air de courrir des masses. En fait, on semble plutôt se balader !

image

Pourquoi ne pas y aller dans ces conditions ? Pierre Neis et moi-même nous sommes donc joins à la fête. Fête est le mot approprié : tous les 200 mètres, il y a un podium avec de la musique à fond et des pom-pom girls. En fait, le marathon, c’est juste une autre occasion pour faire la fête.
Je vous laisse admirer vos serviteurs en pleine souffrance dans cet exercice…

image

Amr et Mohamed nous ont accompagnés dans une balade sur la côte offerte par Pierre Hervouet. car vous savez, on est peut-être en Novembre, mais au Liban…

align=“center”image

Une petite ballade dans les grottes de Jeita (avec Marc Cerrone que Pierre Neis a reconnu !). Un dernier diner ensemble. Il est temps de rentrer à la maison. Goodbye Liban, ce fut une conférence et un séjour exceptionnel !

image

Agile Playground #17 : En interlude…

Nous avons conservé ce mois-ci la formule du mois précédant : un démarrage en mode « place de marché » d’un forum ouvert ! Dans la pratique, nous n’avions pas de jeu « à expérimenter » ce mois-ci. Mais Alexis Nicolas avait amené un Kanbanzine. C’était fort à propos !

image

Finalement, deux « ice breakers » et 2 jeux furent retenus pour cette soirée. Outre le Kanbanzine et l’ice breaker dont j’ai oublié le nom, je me suis donc retrouvé mis à contribution sur un ice breaker que j’avais proposé … et un « remember the speed boat » pour satisfaire une demande de mettre en oeuvre des innovation games !

Cassons la glace des estimations agiles !

Pas tout à fait en estimations agiles, en fait. Il s’agissait plus d’expérimenter une approche d’estimation inspirée du Wide Band Delphi. Une version un peu simplifiée, en fait.

1 – On forme plusieurs groupes

2 – Je propose un sujet à estimer.

3 – Chaque groupe discute entre eux pour déterminer une estimation durant 2 minutes

4 – Les groupes partagent les éléments les ayant conduit à choisir cette valeur.

5 – On fait un nouveau tour de ré-estimation d’une minute.

Est-ce parce que nous avions un parterre d’agilistes « chevronnés » ? Aucun groupe n’a jugé nécessaire de réviser l’estimation au second tour (bien qu’avec quelques hésitations). A tord. La réévaluation les auraient fait converger vers la bonne direction !

Remember the Speed Boat

Mariage forcé entre le « Speed Boat » et le « Remember the future », il s’agit d’une combinaison qui me parait aujourd’hui naturelle. Par contre, cette animation était un peu improvisée et j’avoue ne pas avoir été excellent. Hélas. Le sujet, s’il était fun, n’était pas non plus évident à mener à bien : Organiser une visite privatisée au Taj Mahal, avec nuit sur place … mais à un prix raisonnable !

image

Nous avons pu mener notre projet fictif (plus ou moins) à bien. Nous avons terminé en discutant librement des apports de cette approche. Finalement, notre jeu aura atteint son but, car plusieurs des participants vont s’y essayer.

image

Pendant ce temps, le Kanbanzine

Nous avons terminé un peu plus tôt que le second groupe. C’était donc l’occasion pour moi d’entretenir une petite frustration réccurente : cela fait déjà un certain temsp que j’aimerai tester le Kanabanzine ! Chaque fois je rate l’occasion à pas grand chose ! Mais un jour, j’y arriverais…

image

Agile Tour Beirut 2014 : j’y serais !

Deux sessions pour moi au programme de cet Agile Tour Beirut !

image

Scrum Shu Ha Ri

En voici le teaser

Most of time, when we start agility, we think about « doing agile ». In truth, it’s rather about being agile. And being agile is becoming agile, again and again. Agile is not a destination, it’s a journey.

During this session, we will have a different look at Scrum. We will discover a framework that can help you in each and every step of your journey. Scrum owns the qualities to do it. This is why we should appreciate Scrum.

Together, we will engage the « Scrum Journey ». This is a 3 steps journey and there is no shortcuts ! We borrowed names from martial arts, we call them Shu, Ha and Ri.

Shu belongs to apprentices. It’s for people discovering Scrum. It’s about putting Scrum in practice right !

Ha is about improvement. Once you master the basic Scrum, it’s time to adapt the practices or use new ones.

Reaching Ri is reaching the master level. Here we innovate, we reinvente our own way to be agile, based on values and meaning of agility.

This session is a perspective on your next journey. We want to help you start peacefully, staying away from mistakes or misdirections. And enjoy rediscovering Scrum in a new way each time !

Un carpaccio, un !

Cette fois, il s’agit d’un atelier. En voici le teaser

All agile approaches focus on working on small pieces of features. But development teams as well as business-oriented peoples (like Product Owners in Scrum) struggle to split functionalities into small chunks. They claim that it doesn’t make sense. On the other side, we met teams that split features from a technical perspectives, a strategy that matter only for the development team.

Yet, the feature split is possible more often than not. It’s often a question of practice and discipline.

During this workshop, we’ll train ourselves to split features to the extreme with a hard constraint on realization duration. Because, we will not only talk and imagine slicing, we will also argue about it and put it in practice through a programming episode led into very small slices.

Agile Tour Beirut 2014 : j’y serais !

Agile Playground #16

L’Agile Playground ne se repose jamais … ou si peu ! Après une rencontre organisée mi-Juillet, on reprend nos bonnes habitudes dès mi-Septembre. Pierrick fait office de grand orchestrateur aujourd’hui. Et il nous propose un mode d’organisation inspiré de l’open-space, avec 2 catégories de propositions :

  • Les jeux que l’on souhaite proposer.
  • Les jeux auxquels on souhaiterait participer.

Le formule marche bien, nous recueillons quelques propositions, largement assez pour animer la soirée, pas trop pour ne pas être obligé de rentrer dans une gestion compliquée ! Voilà dejà une formule que l’on pourra rééditer !

image

Pour cette reprise nous étions un peu plus d’une trentaine de personnes, à vue d’oeil. Comme on dit lors des open-space : les personnes qui sont là sont les bonnes personnes !

image

Le « software ball » que propose Pierrick m’intrigue, ne serait-ce que par son nom : allons-y !

Le Software Ball

Le principe de ce jeu est simple et curieux et finalement pas si facile à saisir ! Les participants sont invités à se lancer une balle selon un schéma défini par le maître de jeu (nous ferons 5 itérations en complexifiant ce schéma). Pour exécuter cela, il faut « programmer » chaque participant avec des instructions en français à suivre très précisément. Elles sont inscrites sur des post-it que l’on colle sur soi.

A chaque itération, nous gagnons 10 points, moins le nombre d’instructions nécessaire pour programmer tout le dispositif (les instructions sont les verbes des phrases). C’est là que ça se gâte, n’est-ce pas ? Ce n’est pas fini ! On a droit au copier-coller et c’est gratuit ! Si 2 participants (ou plus) ont les mêmes instructions, on ne décompte que les instructions d’un seul participant. De même, si l’on garde des instructions entre 2 itérations, c’est aussi gratuit !

image

Bref, c’est quand même compliqué, vous pouvez toujours faire un tour sur le site du Software Ball. Pas mal de perte de temps au début : nous essayons un peu vainement de « bien » conceptualiser la chose avant de commencer. En fait, il est plus simple de se lancer et d’expérimenter sur le tas : nous nous lançons donc à deux pour commencer. Rapidement, après une paire d’itération, nous nous rendons compte que notre implémentation initiale génère des coûts exponentiels, car toute la complexité est sur le rôle du « lanceur-dispatcheur » qu’il faut réimplémenter à chaque fois ! Peitit moment de reflexion.

image

Nous galérons un peu pour passer du mode « push » au mode « pull » où les recepteurs appellent la balle et où il n’y a plus d’intelligence sur le dispatcheur. En effet, les règles stipulent de l’on ne peut pas faire de réutilisation partielle d’implémentation. Nous finissons par trouver le contournement !

Ce jeu a pour but de mettre le doigt sur des pratiques de Craftsmanship. En cela il est tout à fait original ! Il nous permet de reflechir à la réutilisation, au moment adéquat pour changer de stratégie et c’est franchement pas mal. Par contre il est frustrant sur le peu de libertés qu’il nous laisse pour faire des choix de cinématiques de circulation de balle. Je pense aussi qu’il devrait permettre la réutilisation partielle. En synthèse, voici le résultat du débrief.

image

Bref, j’ai bien envie de l’essayer, mais en hackant légèrement les règles !

La balle supersonique

Petite originalité de cette édition : un jeu frugal durant le buffet de fin ! Nous avons pu expérimenter une balle supersonique. Enfin, l’ayant déjà joué à Agile Game France, j’ai passé mon tour !

image

Mention spéciale à Julien qui l’a animé en n’ayant expérimenté la chose qu’une seule fois à Agile France. Il a d’ailleurs un peu hacké les règles en permettant de tenir la balle pendant qu’elle circule ! Je pense ne pas le suivre dans cette voie. Mais il bon d’essayer des choses. Voici de que cela donne

See you later

Toutes les bonnes choses ont une fin. Je coupe court à l’un de mes moments préférés : le buffet et la discussion qui terminent la soirée. Rendez-vous le mois prochain !

image

Agile Playground #15

Un conflit d’agenda m’a fait raté le 14ème rendez-vous, c’était donc une bonne surprise de voir un Agile Playground programmé en cette première quinzaine de Juillet, alors que je croyais nos rendez-vous interrompus jusqu’en Septembre !

image

Au programme de cette soirée, un ice-breaker sans prétention mais amusant proposé par Frank Beulé et une traditionnelle expérimentation de jeu.

Change agent

On est là pour expérimenter et Christophe Keromen a bravement défendu cette tradition avec une création vraiment difficile, je dois dire : le « change agent » inspiré du How To Change the World de Jurgen Appelo.

image

Le principe :

  • 4 équipes devant s’approprier 4 des modèles décrits dans le livre de Jurgen Appelo : Dnce with the system (PDCA), ADKAR, la courbe d’adoption de Moore et les 4 « I ».
  • 2 tours de batailles (demi-finales et finales)
  • Un storytelling à monter pour chaque équipe à chaque tour. D’abord un exemple d’échec puis un exemple de succès.
  • A chaque tour, chaque équipe change de modèle.

En plus du modèle, nous disposions de cartes pense-bête dont il fallait montrer l’utilisation au fur et à mesure de l’histoire. Bien entendu, le tout était time-boxé, ce qui rendait l’exercice particulièrement difficile !

image

Entre les 2 tours, nous avons fait une rétrospective éclair pour améliorer le fonctionnement. Ca a marché ! N’occultons cependant pas le principal : c’est mon équipe qui a gagné 😉

image

Ce que j’en ai pensé

Je dois l’avouer : je ne me suis pas amusé durant ce jeu. Est-ce grave, docyeur ? Pas vraiment : l’agile playground est là pour expérimenter et Christophe a fait la tentative la plus audacieuse à laquelle j’ai assisté. Et cela doit être salué !
Nous avons donné (beaucoup) d’éléments à Christophe. Voici de nouveau les miens plus une ou deux choses dont j’ai discuté avec Xavier Galleri :

  • Double difficulté de l’exercice : trouver une histoire et comprendre assez bien le modèle pour l’appliquer à l’histoire. Quand on ajoute la contrainte du temps… Il faudrait proposer des trames d’histoire prêtes à être utilisées.
  • Le setup de la salle : la disposition des tables nous collait contre le mur, ce qui crée un style un peu guindé et une certaine pression psychologique.
  • Durant le story-telling, les autres équipes sont trop passives. On pourrait utiliser les cartes pour les faire participer. Un peu comme un loto…

N’oublions pas le plus important : le story-telling, ça marche ! C’est quand même l’ingrédient principal qu’a voulu utiliser Christophe et les remarques que nous avons faite ne doive pas occulté qu’il a réussi sur ce plan !

Jouez en Kanban, re-tentez votre chance !

A mon grand dam, j’ai raté pas moins de 3 rendez-vous du FKUG, j’étais donc heureux de me rendre à celui-ci. D’autant plus heureux qu’il me permettait de m’essayer à l’un des jeux proposé lors d’un meetup précédent. J’avais d’ailleurs arrêté mon choix sur Kanbanzine que je souhaitais comparer au getKanban que je connais bien.

Dans les starting blocks

Nous étions accueillis chez Soat, dans leurs nouveaux locaux du 13ème arrondissement, à deux pas de chez moi ! Beaucoup de place pour s’ébattre, mais nettement moins de participants que prévus : j’imaginais 50 participants sur les 80 inscrits, nous étions un peu moins de 30 au final. Le foot d’un côté et les problèmes de transport de l’autre ont probablement eu raison de la pugnacité des uns et des autres !

On est agile, on s’organise, ou plutôt Gwenael nous aide à nous organiser.

image

Tout d’abord, les jeux proposés pour cette soirée :

  • Le getKanban, nous est proposé par Renaud Chevalier
  • Le Lean Lego Game va être animé par un Yannick Quenec’hdu remonté à bloc.
  • Un Kaizen game, créé par Olivier Le Lan et quelques uns de ses collègues sera orchestré par lui-même.
  • Le Kanbanzine est prévu pour se dérouler sous la houlette de Sebastien Ménétrier
  • Enfin, le Beer Game nous est proposé par Emmanuel Sciara

Pas sûr que nos effectifs nous permettent de mettre en oeuvre tout ce qui est proposé : un rapide vote le confirme. Damnation : c’est justement le Kanbanzine qui est sur la sellette. Je me rabat sur le Beer Game. Mais ce sera sans le regretter !

Le Beer Distribution Game

Ce jeu n’est pas vraiment un truc tout neuf, car il a été créé au MIT dans les années 60 ! Emmanuel, qui va être notre meneur de jeu va utiliser la version commerciale de la System Dynamics Society.

image

Le principe

Le but est d’imiter une chaine de distribution en 4 étapes, allant de la fabrication à la distribution de bières. Chaque maillon de la chaine reçoit des commandes, passe des ordres de rapprovisionnement en fonction du stock (ou du backlog) et des commandes reçues, mais n’a pas de visibilité sur ce qui se passe chez ses voisins. En fait, on n’a même pas le droit de se parler entre nous.

On fait de nombreux tours de jeux, 40 dans notre cas. Et nous voyons nos stock varier et même passer dans le négatif en tentant d’ajuster ces fluctuations à l’aide de volumes d’ordres que nous pensons adaptés.
Le meneur compte les coût de stock (0,50 € par item en stock) ou les demandes en souffrance (1 € par commande non satisfaites).

La dynamique du jeu, surtout vue de l’extérieur, est assez curieuse. Nous ressemblons à des sortes de galériens silencieux qui n’ont pas tellement l’air de s’amuser ! Parfait !

Ce qui se passe

Assez rapidement, on a l’impression de ne plus avoir la situation sous contrôle : les stocks varient et les arrivages ne sont pas du tout en ligne avec la compensation de ces variations, alors on tente de sur-compenser cela par des ordres adaptés. Mais cela semble vain.

image

En fait, nos stratégies sont effectivement vaines. Elles sont même contre-productives : chaque tentative de correction se trouve amplifiée par l’élément suivant de la chaine, accroissant le niveau de chaos des arrivages !

On se sent à la fois aigris et pour le moins dépité par « ce que nous font subir » nos voisins. C’est une sensation vraiment curieuse !

Les enseignements

Si la situation semble se stabiliser vers les tours 30 ou 40, on arrive vite à la conclusion qu’il n’y a pas de corrélation directe et simple entre nos ordres et les arrivages. Les comptes nous montrent même que mes tentatives pour « apaiser » le système ont de manière paradoxale fait de moi le maillon le plus coûteux de la chaine : incroyable !

Cet effet est connu dans les milieux autorisés sous le doux nom de Bullwhip effect.

Les facteurs favorisant cet effet sont :

  • Le manque de communication entre les maillons de la chaine, ce qui ne nous permet pas de donner un bon feedback, d’éclairer nos intentions et favorise l’interprétation erronée.
  • Le manque de vision global sur l’état du système.

On voit donc que ce que nous mettons en avant dans nos principes agiles (transparence, communication) sont une vrai réponse à un problème démontrable plutôt ancien !

Emmanuel a par ailleurs publié un post sur ce jeu.

Lego Game

Pendant que nous nous livrions à nos activités avec une austérité digne des plus grandes heures de l’Union Soviétique, il n’en allait pas de même chez nos camarades Legoistes justes à côté !

C’est un Yannick visiblement sous l’emprise de substances illicites qui animait avec dynamisme un session que je serait bien en peine de décrire, émaillée non seulement de sautillements de l’animateur, mais aussi de grands brassages de Lego…

image

On trie les l’égo, on les renverse par terre, puis bien sûr on les ramasse. Finalement, ce n’est pas si mal comme spectacle pour égayer notre boulot de galérien !

image

Kaisen Game

Olivier Le Lan avait déjà animé ce jeu lors de la journée Open-Space du ScrumDay. Déjà je l’avais raté à ce moment là (mais il s’agissait d’une version 40 minutes, pas vraiment satisfaisante aux dires d’Olivier).

image

Hélas, ce n’est pas encore ce soir que je pourrais l’expérimenter. Il fallait bien faire des choix !

getKanban

C’est un grand classique pour l’apprentissage du Kanban. S’il manque le côté décalé d’un Kanbanzine ou d’un Pizza Kanban, c’est un jeu très complet sur tous les aspects du Kanban dont le fonctionnement a été très bien mis au point. Il mérite un post à lui tout seul.

image

Renaud avait disposé 2 plateaux de jeux « fait maison ». Il est vrai que le jeu officiel est preque hors de prix !

Pizzas time !

Les activités qui étaient planifiées occupaient chacune un peu plus de 90 minutes. C’est donc pratiquement à 22 heures que nous avons pu calmer nos appétits avant de regagner nos pénates.

image

En ce qui me concerne : une soirée réellement instructive, en plus d’être une bonne détente. Un grand merci à Emmanuel pour avoir si brillamment animé ce jeu.