Point de vue

by dbeck on Comprendre, Point de vue

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/

 
by dbeck on Comprendre, Point de vue

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/

 
by dbeck on Comprendre, Point de vue

Eviter le principal échec du product owner

Les Temps Modernes – Charlie Chaplin

Vous construisez une application, vous êtes dans les temps (mettez ce que vous voulez derrière cette expression), en Scrum (mettez aussi ce que vous voulez derrière ça) et vous vous apprêtez à mettre en production votre première version.

Et là vous, vos clients, vos utilisateurs, votre marché, n’accrochent pas, sont déçus, bref il y a de forte chance pour que vous ayez oublié une ou deux choses importantes en route et que votre produit se dirige clairement vers la case fiasco.

Quel est le problème ?

Peut-être connaissez-vous ce dessin de Henrik Kniberg qui montre l’opposition entre une démarche d’accumulation de fonctionnalités et une démarche de choix, parmi toutes les potentielles fonctionnalités, de celles qui apportent une rélle valeur.

Maximize Value, not output – Henrik Kniberg

C’est une première amélioration dans le chemin d’un responsable produit, pourtant ce n’est pas celle qui est capital.

Avant même l’apport de valeur, il est encore plus important de porter votre attention à votre réélle connaissance des problèmes de vos utilisateurs. Vous pouvez construire un produit avec beaucoup de valeur mais qui ne répond pas vraiment aux problèmes de vos utilisateurs.

Vos utilisateurs ne veulent pas une app, ils veulent résoudre leurs problèmes

Savez-vous pourquoi vous construisez ce produit ?
Quels sont les problèmes rencontrés par vos utilisateurs cherchez-vous à résoudre ?
Quels sont les résultats que vous cherchez à obtenir avec ce produit ?
Comment savez-vous que ce que vous avez construit va permettre d’atteindre ces résultats ?

Si vous galerez à répondre à ces questions, il est temps de step up votre ranking en product ownership avec un outil que j’ai découvert chez Melissa Perri : le product Kata.

Démarche scientifique du produit

Vous avez oublié pendant que vous vous efforciez de construire votre produit de confirmer ou infirmer toutes vos hypothèses et vos biais de perception (exemple : ce qui me parait être bon pour moi, l’est pour mes clients / ce que je vois est la réalité absolue et c’est donc la réalité de mes clients / etc. ) par des expérimentations.
Ca tombe bien la science nous a donné une démarche d’expérimentation qui fonctionne depuis des siècles 🙂 , nous allons voir comment Melissa Perri utilise cette démarche pour le produit.

Melissa Perri a d’abord piqué l’idée générale de Toyota Kata, mélange d’un kata d’amélioration et d’un kata de coaching.

Kata d’amélioration – Toyota Kata

Elle a aussi repris l’idée de Mike Rother qui a adapté le kata à Kanban.

Dans tous ces katas, on retrouve les principaux ingrédients d’une démarche scientique : Observation, Hypothèse, Expérience, Résultat, Interprétation, Conclusion, qui coupe court à nos biais cognitifs 🙂

Cette combinaison de kata aboutit au Product Kata qui va chercher à améliorer le produit en continu et réduire l’incertitude autour de celui-ci par l’expérimentation et l’apprentissage.

Le Product Kata

Melissa Perri part aussi du postulat que de répondre à un problème utilisateur n’est pas simple et qu’au début nous ne savons absolument rien ni du problème, ni de comment y répondre, ni de la bonne façon d’y répondre.

Product Kata – Melissa Perri

C’est en itérant avec ce kata que nous pourrons lever les incertitudes et produire le bon produit.

Ce kata est une succession de 4 étapes que vous repetez à l’infini jusqu’à atteindre l’objectif final. A chaque fois que vous démarrez une action en lien avec votre produit, utilisez ces 4 étapes :

  • Comprendre la direction que l’on prend. Quelle est la stratégie de l’entreprise, quels sont les grands objectifs business, etc.
  • Analyser la situation actuelle. Où en sommes-nous en ce moment de nos connaissances et de notre produit en comparaison de la vision ?
  • Décomposer et déterminer quel est le prochain objectif à atteindre.
  • Choisir l’étape approprié dans le process produit (exploration du problème, exploration des solutions, optimisation de la solution)

En utilisant ce kata, on s’aperçoit aussi que le rôle du responsable produit ne démarre pas le jour où l’on démarre la réalisation du celui-ci mais bien en amont avec l’étape de découverte et d’exploration (Discovery).

Enfin si vous faites parti des Product Owner bloqué dans le delivery par un management ou un client directif et omniscient, cette démarche pourrait aussi vous servir 🙂 Quoi de mieux pour casser des idées reçues ou des demandes iréalistes que de demander à ce que ce soit basé sur des faits ?
Peut-être même qu’il vous remerciera d’avoir redresser la barre juste à temps.

 
by dbeck on Point de vue

Nous sommes tous agiles par nature

Ce point de vue, écrit en 2018 devait servir dans une communication d’entreprise. Je l’ai repris et un peu adapté pour être publié ici.
Il est toujours d’actualité.

Au cours de notre vie, nous ne cessons de nous adapter à un environnement extrêmement changeant et inconnu. Sans nous en rendre compte, nous faisons preuve d’agilité à chaque instant.

L’agilité c’est la vie

Imaginez, vous vous rendez chez vos amis ce soir. Vous prenez votre véhicule pour vous y rendre. Vous connaissez le chemin et comptez réaliser le chemin en 34 minutes. C’est le temps que vous mettez d’habitude.

Et là, pas de chance vous tombez en plein bouchon : un accident à 300m, la route est bouchée, vous roulez au pas.

Vous vous rendez compte qu’il y a des rues adjacentes, elles ont l’air moins chargées ouf ! bonne décision vous limitez votre retard chez vos amis.

A quelques encablures, vous sentez que quelque chose n’est pas normal. Vous avez oubliez chez vous le bouquet de fleurs que vous vouliez offrir à vos amis !!
Plusieurs possibilités s’offrent à vous : retourner chez vous (gloups les bouchons), ou trouver un fleuriste ouvert dans le coin. Un coup de recherche géolocalisée et hop un fleuriste pas trop loin qui ne vous fait pas perdre trop de temps.

Finalement vous arrivez chez vos amis avec votre présent, vous remarquez le retard que vous n’aviez pas prévu. Vous vous dites que les prochaines fois vous partirez un peu plus tôt afin de prendre en compte ces aléas.

Autre exemple – un objectif à bien plus long terme – celui d’élever un enfant. Évidemment les enfants ne sont jamais livrés avec un mode d’emploi : qui peut dire qu’il savait à l’avance comment élever son enfant et ce qu’il va devenir à l’âge de 20 ans ?

En tant que parents nous nous efforçons de fournir le meilleur cadre possible, faire les meilleurs choix possibles et nous savons aussi que nous faisons des erreurs. C’est inévitable.

Nous ne pouvons pas prédire l’avenir, alors nous expérimentons.

Nous faisons des hypothèses, nous prenons des décisions et avançons à petits pas, en réajustant en permanence nos comportements pour atteindre nos objectifs de vie. Nous apprenons de façon empirique.

Par nature, nous sommes tous agiles.

A l’origine, pour le développement logiciel

C’est cela l’agilité : expérimenter, apprendre en continu, s’adapter.

D’ailleurs, le Manifeste agile et les mouvements plus récents comme Heart of Agile, Agnostic Agile ou Modern Agile ne disent pas autre chose.

Rédigé Outre-Atlantique en 2001, par un collectif de 17 experts des systèmes informatiques, le Manifeste Agile explique que ses auteurs ont découvert que certaines choses marchaient mieux que d’autres en observant comment ils développaient et comment ils aident les autres à développer : empirisme, collaboration, pragmatisme avant tout.

Lorsqu’il est appliqué au développement logiciel, l’agilité s’associe fortement à la satisfaction des utilisateurs et clients des logiciels, à la notion d’apport de valeur, à la collaboration au-delà des silos des entreprises et à la qualité logiciel.

En conséquence de cela, l’agilité nous force à une compréhension différente d’un développement logiciel :

  • Nous cherchons à obtenir un bénéfice que l’on peut mesurer plutôt que d’obtenir un ensemble de fonctionnalités.
  • Nous acceptons que les seules personnes qui peuvent savoir si le logiciel est adapté sont ceux qui l’utilisent. Nous acceptons qu’il nous faut obtenir ce feedback régulièrement via des périodes de temps courtes, des itérations.
  • Nous comprenons aussi qu’à partir d’un objectif clairement défini, les meilleures personnes pour prendre des décisions pour construire un logiciel sont ceux qui le font.
  • Et enfin nous comprenons qu’il est illusoire de prévoir ce qui se passera dans le futur au-delà d’un ou deux mois : ce sera faux, acceptons-le.

Ces quatre points peuvent facilement être calqués à d’autres domaines que le logiciel vous ne trouvez pas ?

Et l’agilité en entreprise alors ?

L’agilité, c’est avant tout un état d’esprit qui autorise plutôt qu’il n’interdit, qui va ensuite s’associer à un ensemble de pratiques qui vont permettre d’avancer et de progresser sur des bases solides.

Et si nous sommes agiles au quotidien, une fois que nous sommes au bureau, étrangement, nous oublions d’être agiles. Ou plutôt, nous étouffons cet instinct, pour nous conformer aux process imposés par l’entreprise. Nous acceptons des contraintes très importantes, en termes d’organisation notamment, qui vont à l’encontre de ce que nous dit la vie.

Les entreprises sont figées ; et bien sûr, elles ne se sclérosent pas par plaisir, mais par crainte, par prudence, pour tenter de réduire des risques.

On bloque les process qui fonctionnent à peu près, pour se rassurer ; et pourtant le monde est de plus en plus réactif, connecté, incertain. Nous, en tant qu’espèce humaine, sommes toujours vivants grâce à notre capacité d’adaptation. Si l’entreprise ne s’adapte pas mieux, et plus vite, elle mourra en essayant de se protéger.

Vers des organisations vivantes

A tous les niveaux, la vie c’est l’adaptation, le mouvement et aussi l’acceptation d’une fragilité.

Notre corps est constitué d’un amas de cellules qui ont décidé aux cours des millénaires que l’organisation adaptée à aujourd’hui est celle que nous connaissons. Chacune d’elles a besoin des autres cellules pour survivre à son écosystème et elles s’entre-aident dans ce but. Certaines meurent, certaines vivent, certaines s’adaptent dans un seul but : la survie du corps sans quoi toutes les cellules meurent.

Les entreprises ne sont pas différentes : ce sont des organisations qui cherche à survivre à leur écosystème. Actuellement nous pensons que la meilleure organisation est hiérarchique, avec un processus de décisions top-down.

Et ça ne marche plus.

Il est temps de voir les organisations comme des choses vivantes, dont les décisions sont prises au niveau le plus opérationnelle possible et qui participent à un but commun et connu de tous.

Ces nouvelles organisations qui sont nativement de cette nature sont déjà en train de pousser et de grandir.

Elles vous concurrenceront bientôt, puis feront mourir votre propre organisation.

Posez-vous ces questions : quel est le but de votre organisation ? Est-il connu et partagé de tous ? Est-ce que les décisions que vous prenez ou que vos managers prennent sont intentionnellement orientées pour atteindre ce but ?

 
by dbeck on Point de vue

Confondre vitesse et précipitation

« L’équipe est à combien de vélocité ? »
« Pourquoi vous faites pas monter votre vélocité ? »
« Pour qu’on soit dans les temps, je vous demande de multiplier par 2 votre vélocité »

Ces quelques exemples reéls montrent qu’il arrive souvent que la vélocité soit prise par les personnes extérieures aux équipes Scrum, mais parfois aussi par le Product Owner ou le Scrum Master, comme une mesure de productivité d’une équipe.

Déjà. De quoi parle-t-on.

Définissons la vélocité d’une équipe. Il faut savoir qu’il n’est nullement question de vélocité dans le Scrum Guide. C’est un outil qui s’est constitué pour les équipes afin de prévoir (et non pas prédire) la quantité de d’elements qu’une équipe est capable de délivrer pour la prochaine itération. Elle se calcule en faisant la somme des points de complexité des éléments TERMINES durant la précédente itération. On peut lisser cette vélocité en prenant les valeurs des 3 derniers sprints pour obtenir une valeur plus stable. Cette valeur aide l’équipe à définir le contenu d’un sprint « à peu près ». Et c’est suffisant en terme de planification.

Définissons aussi ce que l’on appelle la productivité.
Si je m’en réfère à wikipedia : la productivité du travail est définie comme la production (quantité de biens ou de services produits) obtenue pour chaque unité du facteur de production (comprendre ressource) « travail » utilisé.
Dans le cas d’une équipe Scrum, la quantité de biens produits pourrait être le nombre de User Stories produites, ou la somme des points de complexité des user stories produites, ou le nombre de ligne de codes pour réaliser les user stories produites et l’unité du facteur de production utilisé pourrait être une équipe Scrum durant une itération.

La productivité d’une équipe serait donc le nombre de User Stories produites durant une itération, ce serait la vélocité de l’équipe ?

Non.

Et n’est pas non plus une mesure de la vitesse à laquelle une équipe ponds des stories.

La vélocité, une mesure quand même ?

On va se le redire tout de suite : oui c’est une mesure, nous l’avons vu plus haut. Non ça ne mesure pas la productivité d’une équipe.

Soyons honnête : on parle de métiers intellectuels, de recherche de solution à des problèmes pas d’une usine d’assemblage de pièces, toutes identiques les unes les autres. Ce n’est pas possible de calculer une productivité qui veuille dire quelquechose.
Un logiciel informatique est un ensemble de composants tous différents, du code spécifique à chaque problème à résoudre. Il n’est donc pas possible de dire « aujourd’hui j’ai fait 10 lignes de code, demain je dois faire pareil » ou « ma productivité est de 1 story par semaine ». NON.

La vélocité est un outil de planification, pas une mesure de productivité et de contrôle.

Elle sert à une équipe à jauger de sa capacité à pouvoir terminer des choses dans un temps donné. Point.
Cette mesure est dépendante de chaque équipe, de chaque produit et du niveau de collaboration entre tout les membre de l’équipe. A la poubelle les modèles, abaques, comparaison de vélocité entre équipe.

J’aime bien utiliser la comparaison avec tetris : L’objectif d’une itération pourrait correspondre à compléter 4 lignes de tetris. Pour faire ces 4 lignes, l’équipe définit la taille des blocs que lui présente le Product Owner puis les pose 1 à 1. Lorsque l’équipe pense avoir rempli les 4 lignes, l’équipe s’arrête de remplir : objectif atteint !

Lors des premières itérations, l’équipe se rendra compte qu’elle ne sait pas remplir 4 lignes mais 3.5 ou au contraire est capable de remplir 5 lignes. C’est cette mesure de la somme des tailles de blocs que l’équipe est capable de réaliser au cours d’une itération qui corresponds à sa vélocité.

Et elle n’est pas fixe. Parfois on se rate est on fait moins de blocs, parfois l’équipe atteint un niveau de collaboration idéal et en état de Flow, elle remplit 6 ou 7 lignes : c’est une estimation qui permet de se fixer un objectif atteignable et potentiellement reproductible.

Ce qui marche avec des blocs de tetris marche aussi avec le développement logiciel : on cherche à estimer ce que l’on est capable de faire et non à chiffrer dans le détail. Pas la peine de passer 2 jours à chiffrer le moindre traitement : le niveau de précision de ce que l’on sera capable de faire ne sera pas meilleure que de passer 2 heures à définir cette capacité en story points, en taille de t-shirt ou en patates.

La mesure d’avancement doit être un logiciel qui fonctionne, pas le nombre d’heure qu’un dev passe à coder un algo python.

Okay et on fait quoi alors si je veux utiliser la vélocité autrement ?

Déjà se creuser la tête pour identifier ce que l’on souhaite réellement : planifier ? organiser le travail ? Communiquer ? Selon l’objectif visé, la stratégie pour l’atteindre sera différent.

Si on s’en tient à l’usage correct de la vélocité : utilisez cette mesure pour identifier un problème dans l’équipe, pour jauger de la capacité de l’équipe, pour estimer l’atterrissage dans le temps d’une version de logiciel.
Et cela ne marche qu’avec une équipe stable et des éléments à réaliser de taille comparable, livrés régulièrement. Il faut donc être TRES prudent lorsque l’on utilise cette mesure.

Et si vous voulez faire autre chose avec la vélocité, de toute évidence ce n’est pas bon signe. Interrogez-vous. Quel est votre intention en manipulant ainsi la vélocité ? N’êtes-vous pas en train, doucement, de glisser vers un bon vieux système command & control ? Et si vous exprimiez votre inquiétude à cette équipe pour travailler ensemble à trouver la meilleure solution ?

Et si vous abandonniez carrément l’usage de la vélocité et testiez l’usage du #noEstimates ?



 
by dbeck on Point de vue

Rétrospective 2018

Il s’agit ci-dessous de mes réflexions sur l’année professionnelle 2018 compte tenue de ma tendance à oublier des éléments qui parfois peuvent être importants 😀

darkomilic91

2018 aura été une année multiple. Éprouvante, enrichissante, inattendue.

J’ai passé cette année à faire quasi exclusivement des choses que je n’avais jamais faites. Et je vous assure que passer une année entière en dehors de sa zone de confort c’est éprouvant.

Dans les grandes lignes et sans ordre d’importance, je suis passé de Shu à Ri (j’y suis pas totalement) sur Scrum, appréhender le rôle de manager dans un environnement complexe, donner l’exemple d’un autre modèle de management auquel je crois, j’ai coconstruit et animé une communauté nationale de pratique Agilité, recruté des agilistes convaincus et qui me poussent à ne pas me contenter du simple nécessaire, j’ai vécu des départs déchirants, des projets agiles catastrophiques, j’ai vu des équipes merveilleuses, soudées et motivées, j’ai eu des jours où je me suis dit que la vie est géniale et d’autres où j’ai eu envie de tout lâcher (parfois dans la même journée), j’ai partagé des émotions intenses.

Objectifs 2018 ?

Dans la lignée de mes objectifs annuels précédents, aucun des objectifs que je m’étais fixé début 2018 n’a été atteint.
A vrai dire, c’est en rédigeant cette rétrospective que je me suis rappelé en avoir définis plusieurs. J’ai du cherché où je les avait noté. On peut dire que je ne risquais pas de les atteindre

J’en avais d’autres cependant. Eux n’étaient pas écrits mais étaient dans ma tête. Ceux-ci sont ambitieux :

  • Faire naitre une vraie agilité chez Open
  • Aider à changer la culture de l’entreprise par le partage et la transmission de nos connaissances et nos passions
  • Rassembler autour de la première des valeurs qui comptent : l’humain.

Nous n’avons qu’une seule vie, faisons en sorte de faire les bonnes choses de toutes ces journées.

Mes réussites cette année

  • Avoir repris le rôle de leader de la communauté de practice Agilité et faire en sorte qu’elle avance. Pas à pas.
  • Avoir aidé à changer des pratiques du recrutement
  • Appliquer des pratiques du management 3.0
  • Accompagner des équipes Scrum vers le succès

Mes échecs / mes apprentissages

  • Équilibre vie pro/vie perso. Ce fut une catastrophe cette année. Par passion certes mais la passion ne fait pas tout. J’avais de grosses ambitions cette année et j’avais envie que tout avance de front. Globalement ce fut un succès du point de vue pro mais j’ai été un fantôme pour ma famille. Lorsque l’on parle d’agilité, on parle souvent de focus sur la valeur que l’on apporte au temps que l’on donne, j’ai oublié une part importante cette année et on me l’a rappelé fortement en fin d’année. Le travail peut attendre, pas la famille ni les amis.
  • On ne peut pas forcer les gens à changer. 2018 a été une année où j’ai beaucoup animé de formations à l’agilité. Expliquer le manifeste, les valeurs, les principes, Scrum, Kanban, l’état d’esprit avant tout autre chose.
    J’avais dans l’idée (naïve) que l’on comprendrait qu’il s’agit d’un changement attitude, d’un moyen pour mieux travailler, mieux collaborer, mieux communiquer.
    J’ai constaté que pour beaucoup, l’agilité est surtout un élément pour sortir du lot, pour être mieux payé, trouver un autre job ou faire du business.
    J’ai constaté aussi que les personnes qui sont rééllement interressées n’ont pas besoin qu’on les force. Ces personnes viennent d’elles-même poser des questions sur des problèmes qu’elles rencontrent pour trouver comment faire autrement.
    Si on veut faire progresser l’agilité dans une organisation, il faut inviter les personnes qui en ont envie : on ne peut pas forcer les gens à changer.
  • La gestion de mes émotions et de mes besoins. S’il y a bien un espace où j’ai pris une claque c’est bien celui-là. Jusqu’à cette année j’ai vécu en control freak de mes émotions par peur de ne pas savoir les maitriser. Finalement cela m’handicapait plus que cela ne me sauvait car j’étais en grande difficulté à identifier ce que je voulais et à l’exprimer. Plusieurs personnes avec qui j’ai travaillé cette année m’ont aidé à lâcher, à écouter et comprendre mes émotions et donc mes besoins. De façon empirique ou de manière méthodique par la CNV par exemple. Je suis loin de me connaitre réellement mais au moins maintenant j’en ai conscience. Merci à eux <3

Et 2019 ?

Je reboucle sur le début de cet article : j’oublie mes objectifs que je me fixe en début d’année. L’un des principes qu’il faut s’appliquer à soi c’est d’accepter de ne pas être parfait, d’avoir raté quelque chose et de reprendre là où on s’est arrêter.
Pour qu’un objectif tienne il faut qu’il soit grand, ambitieux, qui donne envie de le suivre mais il doit aussi s’adapter avec le temps car on ne sait pas prévoir ce qui va se passer dans les prochaines semaines/mois.
Et c’est une de mes managés qui a trouvé ce qu’il me fallait, une pratique qu’elle utilise depuis des années : les OKR (Objectif Key Result) accompagnés d’une démarche agile : inspection et adaptation :

Plutôt que de définir des résolutions qu’on ne respectera pas, définissons 1 grand objectif pour le prochain trimestre et 3 résultats clés mesurés que l’on attends par cet objectif. Et ENSUITE définissons semaine après semaine les actions qui nous permettent d’atteindre cet objectif.

Rendez-vous fin 2019 pour le debrief 🙂

 
by dbeck on Point de vue

Warm up

S’exprimer ? Ne pas s’exprimer ?

… S’exprimer.

Ici est donc mon espace d’expression qui complète mon (mes?) compte Twitter.

Je le vois comme un endroit pour poser mes questions, réflexions, résultats sur les sujets qui me tiennent à cœur.

  • Le web, tout ce qui touche aux systèmes d’informations et le secteur public.
  • L’entreprise et le milieu professionnel (cet univers impitoya-a-ble)
  • Mes projets personnels

Tout ça s’ajoutera petit à petit ^^