Je vais être bref, voici un debrief rapide des 2 jours que j’ai passé à FlowCon cette année.

L’ensemble des talks et sessions sont visibles sur ce site : https://flowcon.sojourner.rocks/all/

J’ai choisi de suivre ce parcours ci : Jeudi

Keynote : Product Management for Continuous Delivery de Elizabeth Ayer

Dynamique de groupes et structuration du temps de Laurène Vol-Monnot et Anne-Sophie Girault Le Mault

Agile Fluency c’est comme la gastronomie de Nils Lesieur et Laurence Wolff

From Scrum to flow de Yannick Grenzinger

L’architecture incertaine de Radwane Hassen

Vendredi

Learning at scale de Ben Linders

Stop giving feedback! de Jenni Jepsen

L’entreprise liberée, ça marche ? de Jean-François Zobrist

Clean Coaching de Sarah Scarratt

Lean starts with kanban de Michael Ballé

Keynote : Product Management for Continuous Delivery

Le sous-titre de la keynote de démarrage était : “closing the loop”. Dès le départ on sent que ça va parler boucle de feedback :) et pour démarrer Elisabeth nous parle de David Kirkaldy qui a été l’un des pionniers ingénieurs à tester les matériaux et les pièces utilisés pour la construction. Cela pour obtenir des faits plutôt que des opinions et ainsi à éviter des catastrophes dans la construction de ponts, de chemins de fer.

En démontrant des failles en quelques semaines plutôt qu’après quelques années de fonctionnement, il a abouti à délivrer plus vite, à plus bas coût de maintenance et à augmenter la sécurité.

La livraison continue partage le même objectif : délivrer plus vite, limiter les coûts de maintenance et augmenter la sécurité.

Pour cela on utilise des outils et un process rodé : une équipe qui fait le design, le dev, test et review et intègre le logiciel dans un outil de control de version, un autre pour l’intégration continu, un autre pour la gestion des release (perf, user test et preprod), puis enfin la prod.

A chaque étape uen boucle de feedback pour améliorer en continue.

Elisabeth nous parle de l’histoire de l’IT depuis les specifications à l’ancienne jusqu’à l’Agile en posant le doigt là où ça fait mal : l’agile Trou Noir :) et donne des signes de ces trous noirs :

“done” signifie dev+test+livraison … en oubliant de valider les hypothèses prises au départ

Les livraisons sont évènement au lieu de s’assurer du succès utilisateur

Toutes les fonctionnalités livrées sont des succès (on ne se pose pas la question de l’erreur)

La planification démarre avec les idées de fonctionnalités

Elisabeth pointe évidemment l’oubli de la plus importante des boucle de feedback : les utilisateurs et le résultat final. C’est pourtant simple puisque ça se passe en 3 étapes :

Décrire le résultats attendu

Livrer

Mesurer

Oups. Tout le monde oubli de mesurer pour savoir si on est dans le vrai ou pas. Pourtant les outils pour cela sont nombreux : OKR, 4DX, KPI, SMART, North Star, etc.

Elle explique que la mesure ne sert à rien car c’est la culture de l’entreprise qui va faire la différence.

Le premier conseil d’Elisabeth est simple : Aligner tout le monde au niveau de l’intention, vérifier et adapter.

Elle dit aussi que pour cela il faut une vraie culture DevOps qui allie la “Team Culture” à la culture de l’organisation SANS OUBLIER la culture produit !

Elle reprend certains points du livre de Edgar Schein “organizational culture and leadership” qui détaille les mecanismes d’une culture d’entreprise : L’attention, les réactions lors d’evènements importants, l’attribution des ressources et des récompenses et enfin la définition des rôles, la formation et le coaching.

Pour promouvoir une culture “close the loop” / fermer la boucle elle note 4 choses : Rendre les objectifs et les résultats visibles , définir comme la norme de travailler en petites livraisons, prendre le temps de collecter et d’analyser les résultats et agir à partir de ce que l’on a appris.

Le second conseil d’Elisabeth est d’émanciper (empower) les équipes pour éviter que les product managers ne deviennent des freins aux décisions produit.

Pour cela elle explique qu’il faut peu de choses : former les équipes au produit pour qu’elles soient compétentes : le scope, les priorités, les temporalités et les éléments business et pousser à la clarté de l’organisation.

Tout cela est peu de chose mais ce n’est pas facile, dit Elisabeth, et que ce sont des challenges qui en valent la peine :)

Dynamique de groupe et structuration du temps

Il faut savoir que la compréhension de l’humain, les interractions et la communication sont mes sujets favoris. Je suis tombé dans la Process Commuication et l’Analyse Transactionnelle il y a une petite année grâce à christopher et depuis j’y trouve enormément de benefice pour me comprendre, comprendre les autres et m’aider à naviguer dans le bordel que constitue les relations interpersonnelles :)

J’avais vu cette conférence sur youtube il y a quelques mois et j’avais trouvé qu’elle synthétisait à merveille ce que je suis en train d’apprendre petit à petit. Aussi lorsque j’ai vu qu’Anne Sophie et Charlène la rejouait à Flowcon je ne pouvait pas passer à coté !

Je ne vais pas m’aventurer à synthétiser leur session qui dure entre 2 et 3h mais plutôt vous renvoyer vers la vidéo youtube et le support.

Okay j’en dit quand même quelques mots (attention je simplifie vraiment) , L’analyse Transactionnelle est un outil inventé par Eric Berne pour modéliser le comportement d’une personne sous 3 composantes : le Parent, l’Adulte et l’Enfant. Le parent étant la composante en nous qui comporte les croyances, les préjugés, etc. , l’Adulte est notre composante reflechie qui sait faire la part des choses et prends des décisions eclairées et l’Enfant est la composante des injonctions t permissions que nous ont données nos parents et également la zone des émotions.

Lorsque nous échangeons avec nos semblables, nous réalisons des transactions où, sans nous en rendre compte, une composante de nous va parler à une composante de l’autre. Ainsi on peut réaliser une transaction Parent <=> Enfant lorsqu’on engueule un collègue à qui l’on avait demandé un service qu’il n’a pas respecté et que ce dernier cherche des raisons pour se justifier.

Anne Sophie explique qu’on retrouve la même chose au niveau de l’entreprise. Le Parent va représenter la culture, le protocole et les habitude de la maison, l’Adulte c’est l’activité de l’entreprise, les outils, les technologies et l’Enfant la vie d’entreprise.

On pourra retrouver le principe d’une relation parent - enfant lorsque la direction décide des règles à appliquer pendant une période de grève et que l’employé décide de faire comme il veut en adoptant l’attitude de l’enfant rebelle.

Anne-Sophie et Marlène évoque ensuite une autre partie importante des travaux d’E. Berne qu’est la structuration du temps. On parle de mécanismes psychologique qui permettent aux individus de gérer les relations dans l’optique d’obtenir des signes de reconnaissances (notre drogue dure à tous), valider des croyances personnelles, etc.

E. Berne est liste 6 allant du retrait ( se renfermer pour ne pas être avec les autres), à l’intimité (on accepte de livrer les aspects potentiellement les plus blessants à l’autre car on a une confiance suffisante) en passant par les passe-temps ( ce degrès où l’on s’amuse à des jeux psychologiques comme le fameux triangle dramatique de Karpman hin hin hin)

Et évidemment on va retrouver ces mêmes phénomènes au niveau d’un groupe avec des degrès de structuration du temps différents :

L’observation du groupe : c’est quoi les règles, qui est qui , qui est le leader ?

Découverte du groupe : Où j’en suis dans le groupe, qui sont mes potes, c’est quoi les VRAIES règles (pas les règles officielles que personne ne respecte ^^). L’étape des passes-temps.

Tester le groupe : On test le chef pour vérifier où on se situe et si le leader est solide. On recherche des alliés. Développement de la cohésion au sein du groupe et partage des valeurs.

Collaborer au sein du groupe : On delaisse les inclinaisons personnelles pour le groupe. Il est accepté pour ce qu’il est dans le groupe. L’individu est orienté solution et résolution de problème.

Enfin dernier sujet évoqué : les dysfonctionnements d’une équipe selon les symptomes.

Pas de confiance. Cela arrive généralement par manque d’information sur l’activité globale et/ou par manque de transparence dans la communication de la hiérarchie.

Jeux psychologiques fréquents. Cela arrive lorsqu’une transformation de l’organisation a été trop rapide et ne laisse pas la place aux ajustements.

Des passes-temps excessifs. Cela arrive lorsqu’il y a des problèmes dans les fondements de l’organisation, dans al structure de l’organisation ou dans la culture de l’entreprise

Des retraits et rituels excessifs. Cela arrive en cas de problème de leadership

Agile Fluency c’est comme la gastronomie

Nils et Laurence ont présenté le modèle Agile Fluency autour d’un atelier.

Premier point : Agile Fluency est un modèle empirique (donc basé uniquement sur l’observation de ses auteurs) d’identification du niveau d’agilité d’un groupe ou d’une organisation. C’est un modèle assez simple avec 5 niveaux. Chacun de ces niveaux correspond à la recherche de quelquechose (impact), un chemin pour y arriver et un cout associé. Oui ce qui est bien dans ce modèle c’est de remettre l’agilité comme un moyen qui a un cout !

Le premier niveau est : Pas Agile. Pas de détail ici puisque c’est le niveau zéro, l’origine. Pour passer au niveau suivant, il faudra passer par un changement de culture des équipes.

2e niveau : Agile Fondamental. L’impact recherché est de la maximiser la valeur produite. Le chemin emprunté généralement est le cadre Scrum, ou Kanban. Le coût pour y arriver est le travail sur l’égo et le partage de + d’informations dans l’organsaition. 50% des équipes connues en sont là et il faut entre 2 et 6 mois pour y arriver. Aller au delà demandera un changement dans l’exigence technique et les compétences des équipes.

3e niveau : L’agile Durable. L’impact recherché est la qualité et la productivité. Le chemin emprunté généralement est eXtreme Programming et le mouvement DevOps, Craftsmanship, TDD. Le coût pour y arriver est l’investissement sur le developpement des compétences induisant une baisse temporaire de la productivité. 30% des équipes connues en sont là et il faut entre 3 mois à 2 ans pour y arriver. Aller au delà demandera un changement de la structure de l’organisation.

4e niveau : La promesse de l’Agile. L’impact recherché est la meilleure prise de décision produit et des livraisons de très haute valeur. L’utilisation du principe d’essais + mesure d’impact. Le chemin emprunté est l’intégration d’expert métier amenant à l’utilisation de pratique comme Lean Startup, Lean Canvas, Design Thinking, Beyond Budgeting. Le coût pour y arriver est le déplacement des équipes business dans les équipes produit. 10% des équipes connues en sont là et il faut de 1 à 5 ans pour y arriver. Aller au delà demandera un changement de culture de l’organisation.

5e niveau : Le futur de l’Agile. L’impact recherché est que les équipes oeuvrent pour l’intégralité de l’entreprise. Le chemin emprunté est l’invention de nouvelles formes d’organsiations et la compréhension des théories sur la complexité. Le coût pour y arriver est le temps et les risques de devleopper ces nouvelles approches. Maximum 1% des équipes connues en cont là et le temps pour y arriver est inconnu.

From Scrum to Flow

La session de Yannick sur le passage de Scrum au flow avait généré pleins d’attentes en moi car j’ai du mal à m’interresser au sujet du flux et à sa mise en pratique bien que j’en vois les bénéfices (optimisation de process, identification des blocages, mesures, etc.)

Et finalement j’ai été déçu. Non pas par la présentation, qui était claire et plein de bon sens. Je me suis rendu compte que j’en connaissais suffisamment théoriquement Kanban.

Dans les conseils que Yannick a donné pour passer de Scrum au flux c’est d’être dans une optique Livraison continue. Cela implique d’appliquer quelques pratiques ou concepts :

Infrastructure As a Service Infrastructure As Code (En parlant de Terraform par exemple) Capacité à livrer facilement n’importe quand. Une CI robuste et scalable Trunk Based Developpement (ou Octopus - je ne connaissais pas) Feature toogle / Feature branching Blue - Green Deployement Canary Release TDD Pair programming / Mob programming Contract testing (pour éviter les liens de dependance externes) DDD Living Documentation

Architecture incertaine

Fin de journée un peu technique, j’étais interressé car je cotoie plusieurs architectes qui ne démordent pas des architectures up-front alors même que le developpement est itératif et incrémental.

Bref belle introduction de Radwane avec une video qui illustre de manière inspirante que du chaos peut naitre de choses magnifiques et que la nature nait et vit par le chaos.

“Chaos is the law of nature - Order is the dream of men”

Radwane explique que la complexité d’un système est le résultat de l’évolution de multiples systèmes simples et que nos architectures logicielles doivent suivre les mêmes principes car la nature même de la complexité est de ne jamais suivre ce qui était prévu : cohésion (regrouper des concepts simples) et couplage (interaction entre les groupes).

Radwane soutient aussi l’idée que les décisions d’architecture devraient être prises avec les équipes et que les équipes qui travaillent ensemble doivent refleter leurs dépendances : s’il y a des dépendances fortes, les équipes doivent travailler fortement ensemble plutôt que d’être le reflet de l’organisation dont elles dépendent.

Pour terminer, Radwane propose une idée intéressante : employer le principe de l’UX avec l’architecture : chercher un résultat, trouver des idées, sélectionner des idées, les expérimenter.