FlowCon 2022 - Jour 1
FlowCon, conférence Lean et Agile
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 moments non-hebdomadaires : 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/