FlowCon 2022 - Jour 2

FlowCon, conférence Lean et Agile

Pour faire suite à la synthèse du premier jour, voici la synthèse du 2ème jour de ma participation à FlowCon France 2022, une conférence dédiée au Lean et à l’Agile.

J’y ai ajouté l’atelier de Sarah Scarartt qui a eu lieu le premier jour.

Après une première journée studieuse et inspirante, j’ai favorisé les ateliers et la pratique pour avoir des choses concrètes à rapporter vers les équipes avec lesquelles je travaille et la communauté des agilistes à laquelle je participe chez ANEO.

Être à sa place ou devoir s’adapter : qu’est-ce qui se passe dans vos équipes

Deux personnes résolvent un problème.

J’avais déjà rencontré Sarah Scarartt lors d’une édition de School of PO et elle était venue nous montrer ce qu’était le clean coaching.

J’avais trouvé cela original, différent, difficile et avec une potentielle puissance dans les interactions que l’on développe avec les personnes avec lesquelles on travaille.

Bref c’est ce sentiment d’inconfort qui m’a incité à retenter l’expérience (oui c’est chelou je sais) et aussi le titre de cette session qui m’a intéressé : ça veux dire quoi être à sa place ? comment tu sais que tu es à ta place ? On cherche tous, plus ou moins, à répondre à cette question mais on ne pose jamais cette question, étrangement.

Et bien je n’ai toujours pas été déçu par Sarah 🙂 , c’était inconfortable (mais acceptable)

Sur la base de la question formulée par Sarah : C’est quoi être à sa place et y a t-il une différence avec le fait de devoir s’adapter. Nous avons expérimenté quelques questions de clean language qui utilise fortement les métaphores de la personne pour travailler le questionnement :

Quand on se sent à sa place pour nous, c’est comme quoi ?

Nous avons expérimenté un mode d’échange avec une cercle intérieur qui participe et un cercle extérieur qui observe activement.

Puis on échange les places et d’autres questions sont posées.

L’objectif était de voir qu’on peut tous exprimer quelque chose avec nos propres métaphores pour générer une discussion et du partage entre les personnes.

L’autre objectif c’est de ne pas imposer sa vision du monde lors d’un échange mais de chercher à accorder nos compréhensions à partir du langage de chacune des personnes via les métaphores. On cherche ici l’inclusivité et l’ouverture.

Bref c’était enthousiasmant, merci Sarah 🙂

Vous pouvez aller chercher des ressources pour comprendre ce qu’est le clean language ici https://cleanlanguage.fr et le compte linkedin de sarah pour lui poser plein de questions : https://www.linkedin.com/in/sarahscarratt2020/

Deep democracy – Démocratie profonde ou comment écouter toutes les voix du système

Des oiseaux alignés sur un fil électrique. Un des oiseaux est à l’envers par rapport aux autres

Deuxième atelier de la journée avec cette fois quelque chose qui tourne autour de comment faire en sorte que tout le monde puisse se faire entendre dans un système lorsque dans beaucoup de cas on laisse entendre qu’il s’agit de démocratie alors qu’en réalité c’est rarement le cas.

Dany Nassif et Vincent Taillandier proposent d’expérimenter certains aspects de la démocratie profonde : c’est à dire (encore une fois) de tendre vers plus d’inclusivité des populations marginales, qui sont les moins entendues lorsqu’il s’agit de prendre des décisions, élaborer des solutions, résoudre un conflit, etc.

L’expérience tournait autour de différents aspects de cadrage, le résultat était noté sur de large post-its :

• Comment définir à priori des règles de conduite d’un groupe pour éviter de tomber dans des situations conflictuelles en mode automatique de type triangle de Karpman
• Quelle est l’ambiance qu’on va décider de protéger ? Sur ce point c’était malin d’associer des mots qui reflète l’ambiance qu’on souhaite protéger et de demander aux participer de signer les post-il des mots pour lesquels on s’engage à en être les champions, à les défendre pendant l’atelier. Ca implique les participants activement à respecter les regles qu’ils ont eux-mêmes établis
• Quelles sont les attentes des participants
• Quelles sont les attentes des facilitateurs

Nous avons cherché un sujet sur lequel on voulait débattre et pour lesquels nous aurions différents avis (l’objectif c’est d’expérimenter la remontée de signaux faibles). Nous nous sommes mis d’accord sur un sujet, nous avons fait un premier tour de table pour trouver les premiers axes d’échanges, les facilitateurs indiquait sur des grands post-it ces axes de discussions et les posait sur le sol.

Ensuite pendant des périodes de 10 minutes environ, les membres du groupes se positionnait autour des cartons avec lesquels ils se sentaient le plus en accord puis prenait la parole pour clarifier le point de vue.

Puis par rebond, les autres voix du système (c’est comme ça que les facilitateurs appelaient les différents axes de discussion) complétaient en personnifiant le point de vue sur lequel ils se sont arrêté.

Rien n’empêchaient les participant de changer de « voix » (et donc de position dans la salle) s’ils sentaient le besoin de se rapprocher de l’une d’elle et de parler au nom de celle-ci.

Bref un moment d’échange avec une façon de faire différente.

J’ai regretté cependant que l’on n’arrive pas à la finalité de l’objectif initial : faire parler les signaux faibles. Est-ce que cela venait de notre relative entente sur le sujet ou pas nous ne le saurons pas.

Le point positif etait cependant que l’on se retrouve avec un outil d’échange large où tout le monde n’a pas besoin de prendre la parole tant que la « voix » représente bien son sujet.

Nous aurions pu créer de nouvelles voix pendant l’atelier, nous ne l’avons pas fait c’est peut être là que se font entendre les signaux faibles.

A retester peut être 🙂

Lies, damn lies, and teens who smokes

Photo d’une action de basketball avec 2 joueurs. Photo by Lachlan Cunningham/Getty Images

Etonnant j’avais également rencontré Daniel Vacanti lors d’une précédente conférence. Daniel est un spécialiste du Kanban, dans le genre on ne la lui fait pas, jamais, quand il s’agit de lire des control charts ou des cumulative flowcharts 🙂 .

Son nom de famille laisse supposer qu’il est italien (je n’ai pas cherché) et ça se ressent dans la forme de ses talks et sa gestuel que j’aime beaucoup 🙂

Bref parlons kanban, parlons control chart et parlons signal et bruit.

Daniel utilise l’histoire d’un joueur professionnel américain connu pour avoir le record national du nombre de points gagné lors d’un match de basketball alors que pour le reste de sa carrière, ce fut un joueur ‘normal’. Il y a eu des études faites sur ce phénomène pour essayer de trouver ce qui à provoquer ce record et toutes ces études se basaient sur cette sorte de carte de contrôle avec les score de ce joueur pour chaque match.

A partir de la carte de contrôle des points gagnés lors de chaque match, Daniel explique la différence entre signal et bruit.

Pour la majorité des gens, l’ensemble des points d’une carte de contrôle forme le signal, les informations qui ont un sens, partant de là la tendance des points forme une autre information que l’on va utiliser pour prendre des décisions.

Daniel explique que cette hypothèse est fausse (et que donc toutes les études sur ce joueur sont fausses, bullshit et rien n’est finalement scientifique) : l’ensemble des points de mesures n’est pas forcément le signal, cela peut aussi être tout simplement du bruit : ici l’ensemble des points de mesure des points gagnés au cours de la carrière de ce sportif est du bruit car nous n’avons pas déterminer le signal que l’on cherche à identifier et l’ensemble de ces points n’est absolument pas prédictif.

Pour cela il explique que sur un ensemble de points, il faut déterminer des seuil haut et bas dans lequel on s’attend à trouver le bruit => c’est ce qui est prédictible : on s’attend pas exemple à ce que tous les scores d’un joueur soit entre 0 et 80, on s’attend à ce qu’une story se développe entre 0 et 2 jours, etc.

Ensuite tout ce qui dépasse peut être considéré comme le signal car c’est ce qui n’est pas prédictible donc c’est ce qui nous intéresse.

On peut enfin mettre le focus plutôt sur ces éléments là qui ressortent du bruit et voir ce que l’on peut en apprendre et éventuellement dans la cas d’une équipe de dev prendre des actions correctrices pour éviter d’avoir à nouveau ce signal qui apparait.

Pour ce qui est de ce joueur, Daniel suppose (car il n’y a aucune manière d’être certain) que c’est un pur concours de circonstance, en tout cas en utilisant uniquement la carte des scores.

Bref il s’agit là d’une approche d’amélioration continue par l’analyse des exceptions à un système prédictif et j’ai trouvé la démonstration originale et instructive qui peut être utilisé comme outil en retrospective par exemple.

Le compte linkedin de Daniel Vacanti est ici : https://www.linkedin.com/in/danielvacanti/

The top 3 points you should have paid attention to in the ‘spotify model’ that aren’t squads, chapters, tribes and guilds

illustration de Herik Kniberg tenant une illustration du « spotify model » où il est écrit « spotify wasn’t intended to be a framework or model at all »

C’est rare d’avoir des personnes de chez spotify qui viennent nous parler de ce qui se passe réellement chez spotify. Et Rachel Dubois commence sa présentation en expliquant que c’est même la première fois en france (et en plus par une française).

Au delà du coté hype, que vient nous dire Rachel.

Qu’on s’est tous trompé :p

Comme le titre l’explique, une grosse partie des organisations qui ont voulu tenter la fameuuuse agilité à l’échelle se sont rué sur la fameuse vidéo de Hernik Kniberg qui, entre autre, parlait des non moins fameuse squads, tribes etc. mais pas que 🙂

Et, pas de chance, ce que ces organisations ont tenté de reproduire ( ca vous rappelle pas le principe du cargo cult ?), c’est ce qui ne servait pas à grand chose quand on chercher à monter une organisation produit à grande échelle.

Bref de quoi alors faut-il se nourrir pour faire du spotify à la maison ?

Rachel nous dit 3 choses :

• Les équipes doivent être autonomes certes, mais également alignées avec la stratégie de l’entreprise sans quoi on se retrouve avec des équipes qui partent dans ton les sens (mais de manière autonome :p ). Pour cela ils utilisent différents framework d’alignement, qui sont choisis par les équipes. On peut citer le DIBB par exemple.
• Trust at scale. La confiance à tout les étages: TOUS. Sans confiance à tous les étages, pas d’agilité à l’échelle. Ca veut dire éliminer le plus possible les jeux politiques, ca veux dire éliminer le plus possible la peur. Ca veut aussi dire qu’il y a un gros boulot qui est fait auprès des managers pour que chacun soit prennent ce rôle modèle avec les comportements associés, ça veut dire que l’entreprise récompenses les comportements respectueux mais aussi accepte de punir les comportements non respectueux (posez vous la question si dans votre orga on punit l’irrespect … ) Et enfin ça veut dire partager et communiquer les belles histoires et les moins belles ce que que l’entreprise souhaite et ce qu’elle en souhaite pas.
• Découplage. Etonnamment (non), lorsqu’on parle d’agilité à l’échelle chez Spotify on va surtout parler de rendre le plus possible les équipes indépendante : de les découpler les unes des autres car on sait tous que ce qui fait la réactivité d’une équipe c’est son indépendance face à l’inertie de l’ensemble (coucou Team Topologies). Rachel nous explique cependant que toutes les équipes ne sont pas 100% indépendantes, cela dépends de leur niveau de maturité car il faut que certaines partie du produit évolue vite alors que d’autre au contraire doivent rester stables. Bref le one size fits all n’est pas chez Spotify 🙂

Pour parler de Spotify avec Rachel c’est sur son compte linkedin ici https://www.linkedin.com/in/duboisrachel/

Qualité radicale, de toyota à la tech

le mot « quality » écrit avec des lettre de Scrabble

Dernier talk et celui-ci parlait de qualité en commençant par rappeler une des découverte faite par l’étude Accelerate autour du DevOps est qu’une des clés de la rapidité et de la performance d’une équipe est l’attention à la qualité, en faisant également le pont avec le Lean tel qu’il est décrit chez Toyota.

C’est Woody Rousseau et Flavian Hautbois, tous les deux CTO qui en parlent via des retours d’expériences sur des pratiques mises en place dans leur organisation respective.

Ils rappellent que chez Toyota, un défaut qui est constaté, est analysé, la cause identifiée, des contre mesures appliquées le jour même et les standards de production et la formation associée est appliquée le jour suivant.

Gloups, en IT on est loin de cette réactivité et cette attachement à la qualité mais on peut s’en inspirer.

Cela peut déjà se faire en classifiant les défaut en 4 catégories :

• A : Défaut identifié sur le poste de travail , le build ,etc.
• B : Défaut identifié lors de la vérification ( les tests QA)
• C : Défaut constaté par des utilisateurs internes qui testent le produit
• D : Défaut constaté par des clients

Puis en utilisant la démarche Lean de correction des défauts :

• Identifier le défaut
• Analyser la sévérité
• Prioriser la correction
• Corriger le défaut
• Ecrire un postmortem
• Renforcer l’inspection

Pour les défauts de type A et B, Woody et Flavian ne vont pas jusqu’au bout de la démarche et s’arrêtent à la correction des défauts, c’est généralement déjà ce que toute équipe fait (right ?)

Pour les C et D par contre ils renforcent les choses en organisant très régulièrement des sessions de QRQC ( Quick Response Quality Check) en équipe. Il s’agit de prendre le temps de documenter la description du problème rencontré puis de décrire la solution à apporter et ceux de manière TRES précise : ils vont jusqu’à décrire le process de réflexion utilisée pour mener l’analyse et également la proposition de la solution afin d’aider l’ensemble de l’équipe à suivre le chemin intellectuel parcouru la personne.

J’avais déjà regardé du coté de QRQC pour l’amélioration d’une équipe que j’accompagnait mais je ne savais pas trop par quel bout le prendre et ce talk me donne des pistes à partager avec les lead dev notamment.

Vous pouvez retrouver Woody ici : https://www.linkedin.com/in/woodyrousseau/ et Flavian ici : https://www.linkedin.com/in/flavianhautbois/