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 venu 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 Qarah 🙂 , 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 https://fr.wikipedia.org/wiki/Carte_de_contr%C3%B4le 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/

 

FlowCon 2022 – Jour 1

Quelle plaisir et quelle frustration en même temps !

La semaine dernière je participais à FlowCon France, une conférence dédiée au Lean et à l’Agile. Ma conférence préférée car c’est celle qui est la moins conventionnelle, ne cherche pas le consensus et à surfer sur les trends du moment. 
Dans ces évènements il faut choisir ce que l’on suit et accepter de ne pas suivre ce qui se passe dans d’autres salles au même moment. Et la qualité était folle partout, d’où la frustration.

Le manifeste qui dirige leurs décisions et leurs actions est forcément centré sur l’agilité, le flux et les individus 🙂

Les produits PLUTÔT QUE les projets
L’équipe PLUTÔT QUE l’individu
La valeur PLUTÔT QUE l’effort
En continu PLUTÔT QUE les lots

Je vous propose une rapide synthèse des talks/ateliers auxquels j’ai assisté lors de la première journée avec quelques liens qui vont vous permettre de creuser par vous-même si le sujet vous intéresse.

Il sera suivi par un second post avec la seconde journée 🙂

You Build it, You run IT

Steve Smith accompagne des organisations à la mise en place de la pratique de livraison continue et est venu nous parler du fameux « you build it, you run it » et des freins que les organisations trouvent pour démontrer qu’elles sont différentes des autres et ne peuvent pas appliquer ce principe chez elles. (spoil : en vrai si, mais elles ne veulent pas)

Steve met à disposition un playbook (qui était aussi son support de talk) sur le sujet qui est accessible à tout le monde ici https://www.equalexperts.com/our-services/deliver/you-build-it-you-run-it/

Ce qu’il entends par « you build it, you run it », c’est un modèle d’organisation dans lequel les équipes développent, déploient, maintiennent et font le support de leur produit.

Il évoque différents modèles d’organisation qui dépendent de la criticité du service et indique les « murs de la confusion » qui existeront à chaque passage de témoin à une ou plusieurs autres équipes ( change, support, ops, etc.)

 Il propose aussi plusieurs actions pour passer outre les freins qu’on lui oppose à chaque fois : 

  • Developpers won’t want to do it 
  • Noboby would be accountable
  • Developpers would be firefighters
  • It won’t scale
  • There’d be no incident management
  • We can’t hire a DBA for every team

Vous pouvez aussi le voir lors d’une présentation à Agile India 2022 ici https://www.youtube.com/watch?v=Sf7LSNQcNBg

Le compte Linkedin de Steve : https://www.linkedin.com/in/stevesmithtech/

Entrainer les  Avengers, Oubliez tout ce que vous savez sur le management tech

Regis Medina est un ancien de la tech on va dire 🙂 et qui a plongé la tête la première dans le Lean (le vrai, pas celui des cabinets de conseils en management).

Partant de la maison du Lean, Régis nous propose de nous rappeler que la valeur apportée dans un process de réalisation est fonction de qualité apportée par les réalisations et du cout global des réalisation.

Il pointe aussi du doigt que ces 2 composantes sont fortement liées à la compétences des personnes : qu’attends-t-on pour faire en sorte que les personnes soient les plus compétentes possible et comment y arriver ? 

Pour cela, il nous explique que les personnes doivent pratiquer et refaire les mêmes gestes pour les améliorer, les corriger. La pratique ne suffit pas, on doit être dans la pratique délibérée.

Qu’est-ce que ça signifie ? 

  • Produire : réaliser les gestes pour de vrai, pas juste en théorie
  • Utiliser les standards : respecter les exigences de qualité demandé
  • Répéter de manière consciente : cela signifie être conscient de chaque geste que nous faisons
  • Accueillir les feedback du coach (le coach au sens lean)

De cette manière toute personne passera par 4 étapes : 

  • Incompétente inconscient : il ne se rends pas compte qu’il est incompétent, mais il l’est
  • Incoméptent conscient : il se rends compte qu’il est incompétent
  • Compétent inconscient  : il est compétent mais ne s’en rends pas encore compte
  • Coméptent conscient : il est compétent et s’en rends compte

A la pratique délibéré il ajoutera finalement un ingrédient supplémentaire en bonus 🙂 : L’ENVIE D’APPRENDRE

Comme prétexté à cela, il propose de revoir l’usage des code review pour qu’elles arrêtent de servir de gatekeeping du code et d’orienter son usage à une intention de faire apprendre quelque chose aux membres de l’équipe sous forme de pair review, voire de mob review et que ce soit planifié et – je le rappelle – INTENTIONNEL :

  • Identifier le problème identifié 
  • Rechercher la cause 
  • Quelle est la contre-mesure
  • Pour obtenir quel résultat

Hélas je n’ai pas trouvé le support de cette présentation très inspirante pour toute personne en situation de lead dans une équipe.

Vous pouvez suivre l’activité de Régis sur son LinkedIn https://www.linkedin.com/in/regismedina/

Il a aussi écrit plusieurs livres sur le sujet du Lean, je vous laisse les rechercher 🙂

Comment construire une équipe produit efficace et adaptée à vos défis !

Christopher Parola est Chief Product Officer chez Yousign, il nous propose un retour d’expérience sur la stratégie d’organisation produit qu’il a expérimenté.

Des squads ( on en reparlera avec le jour 2 et le talk de Rachel Dubois sur ce qu’il fallait retenir du modèle spotidy, spoil : pas les squads :p ) incluant PM, engineering manager, devs font et back, QA , Expert et product designer.

Les squads ont une spécificité parmi 3 : 

  • Platform team pour les projets tech au long terme 
  • Feature team pour les besoins de focalisation sur une fonctionnalité 
  • Impact team lorsqu’il faut se focaliser sur un objectif sans savoir à l’avoir quoi faire

Ces squads sont regroupés par domaines cohérents.

Pour ce qui est des métiers Produit il est rentré un peu dans la sujet de l’évolution de carrière en expliquant un modèle de compétences (CORE) demandées selon le niveau. Il en parle plus longuement dans son article de blog ici https://blog.yousign.io/posts/parcours-carriere-product-manager-chez-yousign

En terme d’animation d’équipe il planifie :

  • des moments hebdomadaires : l’un uniquement avec son équipe proche qu’il appelle ‘Product Sync’ d’une heure où il bloque 10mn d’infos top down et 2x20mn où son équipe apporte des sujets à partager, l’autre avec l’ensemble des équipes qui sert à aligner tout le monde
  • des moment non-hebdomadaire : des séminaires d’équipes et l’animation d’une guilde (encore à la spotify)

Le linkedin de Christopher : https://www.linkedin.com/in/christopherparola/ 

Andon et flux, juste-à-temps et confiance mutuelle

Cette fois c’est Marie-Pia Ignace, une passionnée du Lean depuis 2005 et qui a monté son entreprise en conseil Lean.

Son intention est de nous parler d’un tout petit bout de la maison du Lean : l’Andon par la porte de la qualité. 

Pour celles et ceux qui, comme moi, ne le savent, l’Andon est un outil et une pratique qui consiste à arrêter l’ensemble de la chaine de travail dès lors que quelqu’un repère une anomalie.

C’est très utilisé dans le mon industriel mais, étonament, très peu dans le domaine de l’IT alors que pourtant ça peut s’appliquer de la même manière.

Marie-Pia évoque des exemples : la création de File Systems, d’environnements, le cryptage de bases de données.

Plus proche d’une équipe de developpement informatique : lorsque le build de votre application tombe en erreur, c’est rendu visible à l’ensemble de l’équipe qui décident collectivement d’arreter tout ce qu’ils font pour réparer le build.

Marie-Pia donne 2 cas d’usage récurent de l’Andon:

  • Obtenir une aide ponctuelle lorsque, par exemple, un développeur butte sur la résolution d’un problème. Il s’agit là plutôt d’un problème de rythme dans la chaine que d’un défaut en tant que tel mais on peut le traiter de la même manière, par pair programming par exemple.
  • Un gros problème est découvert qui nécessite, en équipe, d’une part de protéger le client (un des principes fondamental du Lean) en réparant au plus tôt ce qui ne va pas, puis ensuite en prenant le temps de comprendre d’où vient le problème et comment s’en débarrasser définitivement. On peut utiliser la technique du PDCA pour poser le problème, identifier la cause, trouver des actions correctrices, les mettre en oeuvre et vérifier que ça corrige effectivement le problème (ne pas oublier cette dernière étape)

Elle fait également le lien contre intuitif entre le fait de tirer l’andon (c’est ce qu’on dit dans l’industrie) et donc d’arrêter la chaine et le temps moyen du cycle time (temps nécessaire pour terminé un élément) : 

  • Lorsqu’on tire plus souvent l’andon, en conséquence le cycle time diminue
  • Lorsqu’on arrête de tirer l’andon, le cycle time augmente

Le point clé de cela est la sécurité psychologique de l’équipe à accepter de tirer l’andon, et donc de perturber le flow de l’ensemble de l’équipe au profit de l’ensemble du système. Sans cette sécurité psychologique, les personnes n’osent pas tirer l’andon par peur du jugement et des remarques.

Idem je n’ai pas trouvé de support dispo, mais vous pouvez contacter Marie-Pia via linkedin https://www.linkedin.com/in/mariepiaignace/