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/

 

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.

 

Changements et résolution de problèmes

« Tout va bien » – Rachel Marks

Imaginons une équipe, une poignée d’équipes, une organisation.

Imaginons les personnes qui les composent, les managers qui les accompagnent et les dirigent.

Tous sont mus par la volonté de bien faire leur métier et les décisions qu’ils prennent se basent sur leurs expériences, leurs croyances, leurs peurs, leur moteur interne. Bref la vraie vie.

Intéressons-nous uniquement à une de ces équipes qui rencontre un problème.

Problème et symptôme

Lorsque cette équipe rencontre un problème, elle s’intéresse généralement à un symptôme de ce problème c’est à dire ce qui se voit et ce qui, concrètement, est un soucis, une épine dans le pied.

Prenons quelques exemples IT qui serviront d’illustrations au fil de cet article : en fin de développement, il y a des bugs qui empêchent de livrer dans les temps, une personne se braque dès qu’elle entre en conflit avec un collègue ou son chef, les applications développées engendrent des coûts de maintenance de plus en plus importants alors qu’elles ont été livrées voilà un an ou deux.

Pour qu’il y ai moins de bug, une solution souvent employée c’est de tester plus, plus longtemps et de formaliser mieux (comprendre plus) l’expression du besoin et la solution.
Pour que la personne « braquée » parle, son manager va la forcer à parler, la provoquer ou tenter de la convaincre que c’est pour son bien si elle parle.
Enfin on décide de lancer une « refonte » pour supprimer l’ancienne application qui coute cher en maintenance.

Les problèmes qui ont bénéficié d’une correction sont en réalité des symptômes. Tester plus longtemps ne fera pas disparaitre la production de bug, obtenir une réponse après avoir « coincé » un collaborateur ne fait pas de ce collaborateur quelqu’un qui s’exprime facilement face au conflit, et enfin les refontes nous le savons tous s’enchainent les une derrière les autres et ne s’arrêtent jamais.

On a traité un symptôme, mais le problème de fond persiste.
Le résultat, quelle que soit la solution qui a été tentée, reste invariant : le problème est toujours là et un symptôme réapparaitra sous une forme ou une autre.

Un problème, plusieurs effets. Ce que l’on perçoit est partiel.

La raison principale de ce constat est simple : nous cherchons à résoudre des problèmes complexes dans un monde complexe et systémique par des solutions qui ne sont pas adaptées.

Parfois ça marche quand même …

Bien évidemment on peut tenter des solutions d’ajustement et trouvé que cela est suffisant pour résoudre notre problème, c’est ce qu’on fait tous généralement et tout le temps ( « mon pc plante, je vais voir la cellule IT », »le covid-19 infectent beaucoup trop de personnes et les gens meurent, je confine tout le monde » ) cependant ce sont souvent des simplifications du vrai problème qui est plus large, qui a plusieurs causes qui nous dépassent et provoquent des conséquences que nous ne comprenons pas. Pour une raison simple : le monde est un système géant dans de multiples systèmes tous interconnectés les uns aux autres et nous ne sommes pas capables d’appréhender l’ensemble comme un tout.
Ces changements / simplifications sont agréables et rassurantes car elles sont économiques : une fois ces solutions trouvées nous pouvons les répéter tant que le problème réapparait.

Il faut cependant être attentif à remettre en cause régulièrement ces solutions si l’on comprends que les circonstances évoluent sans cesse en dehors de ces simplifications ce qui fera qu’un jours les solutions trouvées ne seront plus du tout adaptées.

Ensembles finies des solutions pour traiter un problème dans un cadre de simplification

Et quand ça ne marche plus ?

Watzlawick, dans son ouvrage « changements », décrit les exemples précédents comme des changements de type 1. Ce sont des changements qui sont opérés dans un cadre et qui ne remettent pas en cause ce cadre : on conserve le système simplifié tel qu’il est et on change l’agencement des éléments qui le compose pour tenter de l’optimiser.

Lorsque les tentatives de solutions de type 1 ne fonctionnent pas ou plus, cela signifie que c’est le cadre qu’il faut remettre en cause et non plus son contenu. Watzlawick parle alors de changement de type 2.
On pourrait dire qu’un changement de type 2 est un changement que l’on opère sur l’abstraction du système plutôt qu’un changement dans le système. Il y a une rupture.

Changement type 1, changement type 2

Pour illustrer encore plus simplement, Watzlawick utilise le symbole du moteur et de la boite de vitesses d’une voiture : lorsque l’on veut aller plus vite, nous allons appuyer sur la pédale de l’accélérateur et effectivement la vitesse de la voiture augmente : l’appui sur la pédale correspond au changement de type 1. Lorsque l’on arrive à une certaine vitesse, l’appui sur la pédale accélérateur ne donne plus le résultat demandé et nous arrivons au bout des solutions possibles dans ce cadre : pour aller plus vite il faut utiliser le levier de boite de vitesse qui va changer le système et nous permettre d’accélérer de nouveau. Le changement de la boite de vitesses correspond au changement de type 2.

Okay sur la théorie, changement de type 2 = changer l’abstraction du cadre. Dans la vraie vie ça signifie quoi ?

Dans ces cas, il devient inutile d’utiliser les techniques traditionnelles de résolution de problème qui s’attardent sur les causes du problème (les techniques de causalités, des 5 pourquoi etc.). Chercher des solutions de cette manière, c’est exactement comme chercher toujours aux mêmes endroits les clés qu’on a perdu : il est temps de chercher là où on n’a pas l’habitude de chercher 🙂

Pour cela, nous allons nous pencher précisément sur la situation elle-même, le quoi : que se passe-t-il EXACTEMENT, puis de tenter de percevoir cette situation de manières différentes. C’est le résultat que l’on cherche à produire avec la technique du recadrage.

Le recadrage

Pour pouvoir parler du recadrage nous devons nous mettre d’accord sur certaines définitions que j’emprunte à Watzlawick. Qu’est-ce que le réel, qu’est-ce qu’une opinion.

Ici nous admettons que le réel est ce qu’un nombre suffisamment grand de personnes ont convenu d’appeler réel. (exemple : de nos jours nous sommes une majorité de personnes à considérer comme réel le fait que la terre soit ronde et qu’elle tourne autour du soleil même si une minorité pense autrement).
Une opinion est le sens et la valeur que quelqu’un attribue à un objet, une situation, un fait. (exemple : un couteau peut être vu comme une arme ou un ustensile de cuisine, je peux dire que la terre est plate, que manger avec ses doigts plutôt qu’avec une fourchette et couteau c’est degueu, tout cela sont des opinions).

En conséquence, le réel est une construction de l’esprit basée sur une ou un ensemble de croyances/d’opinions sur ce que nous vivons et qui est partagé par un nombre suffisamment grand de gens et qui nous permet de vivre.
N’hésitez pas à relire plusieurs fois la phrase pour être certain de bien la comprendre.

Si l’on admet ces définitions, il y a donc autant de réalités à une situation qu’il y a d’opinions concernant cette situation.

Le recadrage consiste à permettre à une personne, un groupe ou une organisation de percevoir une autre réalité que celle qu’il ou elle à l’habitude de percevoir.
Soyons clairs : il s’agit pourtant des mêmes faits, choses, situations. Cependant la manière dont le réel est perçu sera différente, les limites seront donc différentes et les possibilités et les solutions seront différentes.

Principe de recadrage

C’est à ce moment que l’on peut utiliser les modèles de représentation du monde que nous avons à notre disposition en tant que coach pour permettre aux personnes, équipes ou organisations de prendre la représentation qui lui permet de trouver les solutions à son ou ses problèmes, débarrassé des limites de la représentation à laquelle ils s’attachaient jusqu’à présent.

Si l’on reprends nos cas du début (attention ce sont des interprétations, pas des vérités) :

« il y a trop de bugs pour livrer » : peut-être que l’équipe considère comme la réalité le fait qu’un logiciel se doit d’être parfait, sans aucun bug. Un recadrage pourrait être de montrer qu’un bug n’est pas un échec de développement punissable, qu’il peut s’agir d’une opportunité à traiter une incompréhension entre l’expression d’un besoin et la solution proposée et que tous les logiciels possèdent des bugs plus ou moins graves qu’il conviendra de traiter ou non.

« le collaborateur qui se renferme au conflit » : On considère que c’est le manager qui cherche à améliorer la situation. On ne cherche donc pas à faire changer le collaborateur. Un recadrage pourrait être de montrer une autre réalité au manager qui veut traiter les choses immédiatement quand elles se produisent, cette autre réalité peut être que le conflit reste présent après les faits et qu’il pourrait le traiter par d’autres manière que sa réalité : par écrit plutôt que l’oral, ou en reprenant la discussion « à froid » ou en comprenant que tout le monde ne réagit pas de la même manière aux situations qui demande une relation interpersonnelle (process com) ou à prendre conscience de la posture qu’il prend lors de conflits (on peut utiliser l’analyse transactionnelle par exemple).

Accompagner le changement

Ne reste plus ensuite qu’à accompagner les changements, Watzlawick propose ces 4 étapes :

  • Définir clairement le problème en termes concrets, que se passe-t-il devant nous ?
  • Examiner les solutions déjà essayées
  • Définir clairement le changement auquel on veut aboutir ( spécifique, concret, réalisable et avec une limite temporelle du changement)
  • Formuler et mettre en œuvre un projet pour effectuer ce changement

Nous vivons dans le monde que nous croyons tel qu’il est alors qu’il n’est pas plus que le monde tel que nous le croyons.

j’avais noté cette citation et évidemment j’ai oublié de noter la référence, que je compléterais donc dès que je l’aurais retrouvé ^^


Référence du livre « Changements » de Watzlawick : https://www.leslibraires.fr/livre/58425-changements-paradoxes-et-psychothrapie-para–paul-watzlawick-john-h-weakland-richard-fisch-points

 

Dans quel monde vivez-vous ?

Lena Bùi
Thresholds of motion I: Chaos to Order

Quelques exemples pour commencer :

  • Vous vivez en France, vous roulez à droite ou à gauche ?
  • Votre disjoncteur saute dès que vous lancez une machine de linge et que vous démarrez votre four, que faites-vous pour régler le problème ?
  • Vous êtes dans un kayak sur une rivière inconnue, quel est votre plan pour arriver en bas du parcours le plus vite possible et, évidemment, indemne.
  • Vous abandonnez toutes les règles, les contraintes habituelles. Les guides et les manuels habituelles ne fonctionnent plus. Il n’y a aucun lien entre les causes et les effets. Le 11 Septembre 2001. La situation des premières semaines vécues à l’arrivée du covid-19. Comment gérer ces situations ?

Ces quatres exemples nécessitent une prise de décision et vous vous rendez compte que la manière de prendre une décision est différente dans tous les cas, pourquoi ? Parceque dans chacun des cas, nous nous trouvons dans un système avec des propriétés différentes et nécessite une réaction adaptée.

C’est là qu’entre en jeu le framework Cynefin.

Prise de décision plutôt que catégorisation

Le framework Cynefin propose d’identifier la situation dans laquelle nous nous trouvons pour en déterminer un mode de prise de décision adaptée.

Dave Snowden, son créateur, précise que le framework n’est pas une matrice 2×2 classique de catégorisation comme celle d’Heisenower , SWOT, etc.

Pour justifier cette différenciation, il explique que les matrices traditionnelles sont très bien adaptées à des situations connues et donc à l’exploitation rapide de données, il suffit de mettre des données dans les cases pour décider : le framework précède les données.

Cynefin est adapté à l’exploration de données et aux changements de situation : le framework émerge des données.

Comment fonctionne le framework ?

Le framework est construit en partant du principe qu’il existe trois types de système : les systèmes ordonnés, complexes et chaotiques.

Les systèmes ordonnés sont eux aussi divisés en deux : les systèmes évidents/ simples et les compliqués. Dans ces systèmes les causes et les effets sont connus ou peuvent être découverts.

Il existe une dernière zone, centrale, appelée désordre.

Il n’y a pas de bonne case dans ce framework. Chaque zone possède ses contraintes, ses propriétés et son mode de prise de décision qu’il faut comprendre pour que le framework soit utilisable.

Système évident

Le système simple/évident est un système ordonné et contraint. Ce qui signifie que toute les causes connues aboutissent aux mêmes effets connues. Tout est prédictible, tout est évident.

Dans ce système, le mode de prise de décision est Sentir – Catégoriser – Répondre. Nous sommes dans le mode des Best Practices, de la bureaucratie, des processus, des standards. Tout le monde agit de la même manière.

Système compliqué

Dans les systèmes compliqué, le lien entre la cause et l’effet existe mais il n’est pas évident. Il y aura donc plusieurs chemins possibles et chacun de ces chemin peut être correct.

Nous sommes dans le domaine des experts, du rationnel et de l’analytique. Il faut avoir toute la connaissance et la maitriser pour obtenir la bonne décision. Ce sont les bonnes pratiques qui gagnent et le mode de prise de décision est Sentir – Analyser – Répondre : rechercher les faits, analyser les données et appliquer la bonne pratiques opérationnelles la plus adaptée.

Même si le lien entre cause et effet n’est pas évident, lorsque l’on apporte la même solution à au problème, nous obtiendrons le même résultat.

Les métiers qui se sentent bien dans ce contexte sont les ingénieurs, les chirurgiens, les analystes, les avocats, bref les experts 🙂

Système complexe

Dans les systèmes complexes, la relation de causalité n’est connue que rétrospectivement et n’est pas répétable : des petites choses peuvent provoquer des résultats radicalement différents. C’est pourquoi pour déterminer des pistes de compréhension en système complexe nous allons favoriser la prise d’initiatives et la multiplications des expérimentations safe-to-fail et laisser le temps à la solution d’émerger d’elle-même.

Les résultats sont émergents et imprévisibles. L’imposition de solutions ou de plan d’actions ne fonctionne pas. Le mode de prise de décision est Sonder – Sentir – Répondre. Le résultat est l’émergence de nouvelles pratiques ou d’une combinaison de pratiques existantes.

Un problème complexe se résout par l’essai, l’expérimentation et en observant le résultat : si l’expérience est concluante, nous l’amplifierons (on renforce les contraintes), si l’expérience est un échec, nous la réduirons (on réduit la contrainte) pour faire apparaitre d’autres patterns.

Système chaotique

Dans les systèmes chaotiques, il n’y a plus de contraintes, plus de liens de cause à effet car tout change constamment.

Dans ces conditions, il est inutile de réfléchir ou de chercher des modèles, il faut agir pour obtenir l’émergence de schéma et pouvoir rétablir un ordre, une opportunité. Il s’agit généralement des situations non-désirées : crises, cygnes noirs et parfois désirées : condition d’innovation.

Le mode de prise de décision est Agir – Sentir – Répondre. Agir rapidement pour stabiliser une situation. Le résultat sera forcément une pratique nouvelle, une solution innovante.

Désordre

Le framework Cynefin identifie une zone de désordre qui correspond à une situation où nous ne savons pas dire dans quel type de système nous sommes.

C’est généralement le cas le plus courant 🙂

Lorsque nous nous trouvons dans le désordre, nous avons tendance à utiliser notre propre mode de prise de décision préféré en pensant, à tort, qu’il est celui qui est le plus adapté à toutes les situations.

Tomber du simple au chaos

Enfin le framework possède une particularité : la délimitation entre zone simple et zone chaotique est une falaise (au sens métaphorique, évidemment :p ) rendant le passage de l’un à l’autre irrémédiable et le retour impossible.

Le passage d’une zone à l’autre du framework suit la logique de l’aiguille d’une montre. Nous passons d’une situation chaotique, à complexe, à compliqué puis potentiellement simple. L’inverse peut être vrai également dans le cas où une situation

Dernière explication du framework : il faut être très PRUDENT avec les systèmes simples. Ils ont tendance à nous garder dans nos croyances, à nous laisser penser que les choses sont immuables, connues et que l’on pourra résoudre tous les problèmes qui se présentent à nous. Être dans l’autosatisfaction. Ce sont des systèmes très vulnérables aux changements rapides.
Si nous n’y sommes pas attentifs, nous glissons doucement mais surement vers la falaise qui nous sépare de la zone du chaos. En dernier lieu, un petit évènement pourra nous faire basculer d’un système simple au chaos, à la crise, avec ses conséquences.

Snowden préconise qu’une organisation maintienne ses systèmes dans le domaine du compliqué et du complexe et de conserver une infime partie de ses systèmes dans le domaine du simple.

Cynefin et les organisations

Maintenant que l’on sait tout ça, reprenez les exemples donnés en début d’article. Dans quel système se trouve chaque exemple ?

Savoir quelle est la manière la plus efficace de réagir selon le contexte évite de perdre de l’énergie inutilement pour focaliser l’attention sur la manière de solutionner les problèmes de vos organisations.

Un autre point de vue intéressant avec ce framework concerne les initiatives de transformation des organisations. Se transformer c’est transformer les pratiques, les modèles internes à l’organisation. C’est donc abandonner les systèmes ordonnés (simples et compliqués) pour favoriser le fonctionnement en système complexes, voire chaotiques.
Partant de là, se transformer c’est donc enlever les contraintes du système existant, c’est laisser les personnes interagir pour expérimenter de manière sécurisée et découvrir de nouveaux modèles, des nouvelles pratiques, bref de la nouveauté adaptée à l’environnement dans lequel de système se trouve.

Est-ce de cette manière que votre transformation se déroule ? Comment favorisez-vous l’expérimentation ? Quelles sont les contraintes que vous enlevez et qui rigidifiait votre système ? Quelles sont les découvertes résultant de vos expérimentations ? Vos experts se sentent comment dans cette transformation ?

Ces quelques questions devraient vous aider à savoir si vous être vraiment dans une phase de transformation ou s’il s’agit d’un vernis appliqué à votre système compliqué et simple 🙂

Finissons avec cette magnifique video de Maxime Causeret et Max Cooper qui exprime parfaitement ce lien intime et parfois contradictoire entre l’ordre et le chaos

et voici quelques références sur le sujet :

 

Modèles de compétences du coaching agile

photo de coaches – flickr

Lors d’un atelier organisé par Guillaume Dutey sous la forme d’un open space, l’un des sujets proposés par les participants était de définir ce que recouvrait le coaching Agile.

Pas convaincu par le résultat final, ce dernier méritait une recherche un peu plus approfondie et j’avais besoin, moi aussi, de trouver un cadre dans lequel m’inscrire ce qui m’a poussé à regrouper les modèles existants.

Tous les modèles sont faux …

Spoil : ce n’est pas une liste exhaustive. J’ai regroupé les modèles qui me semblaient correspondre à ce que je cherchais.

Il ne faut pas oublier que tous les modèles, par nature, sont faux. C’est à dire qu’il sont la représentation conceptuelle et imparfaite de l’étude d’un problème réel. Inutile donc de chercher absolument à rentrer dans les cases, c’est n’est pas possible.

Bref, une fois ce disclaimer proclamé, voyons le contenu 🙂

Agile Coaching Competency Framework

Celui qui me parle le plus est celui qui est proposé par l’Agile Coaching Institute (ACI). Il semble faire référence dans le milieu du coaching Agile puisque je l’ai retrouvé dans de nombreuses présentations et dans plusieurs articles cherchant à définir le périmètre d’action des coaches Agile.

Ce modèle est simple à lire et découpe les compétences en 4 grands domaines :

  • Etre agile : l’application à soi de l’Agile et du Lean par ses pratiques et ses valeurs.
  • Le partage des connaissances de l’agilité. Ce sont des compétences qui attendent d’être en position haute – intervenir dans le processus et être à l’initiative. Ces compétences se partagent en 2 :
    • L’apprentissage aux individus des connaissances et de compétences particulières. J’interprète cela comme l’apprentissage en groupe.
    • Le mentorat. J’interprète cela comme une approche d’apprentissage au niveau de l’individu.
  • A l’opposé, nous allons trouver les compétences qui attendent d’être en position basse – laisser l’initiative à l’autre, être à l’écoute, suivre un processus et faire circuler la parole :
    • Le coaching professionnel. Accompagner les individus dans leur cheminement personnel et/ou professionnel.
    • La facilitation. Attitude et comportement pour aider un groupe au travers d’un processus à trouver des solutions ou à prendre des décisions.
  • Enfin les compétences en lien avec les domaines d’expértise
    • Maitrise technique. Les techniques et pratiques qui concernent la construction de logiciel (craft,CI/CD,TDD, etc.)
    • Maitrise business/métier. Toutes les techniques qui concernent le produit et la valeur produite. (product canvas, lean startup, etc.)
    • Maitrise organisationnelle. Tout ce qui a un rapport avec la transformation et/ou adaptation d’organisation (management 3.0, entreprise liberée, holacracie, spirale dynamique, entreprise opale, etc.)

L’ACI a eu la bonne idée de proposer un article sur ce modèle, et le bon plan c’est que chaque élément est associé à des liens pour creuser chaque sujet 🙂

Agile Coach Competency Matrix

Il existe cette matrice de compétences dont je n’ai pas trouvé la source qui donne un peu plus de détail avec quelques critères sur des niveaux pour chaque grand domaine.

  • Etre agile
    • Débutant
      • Connait les principes et des pratiques
      • A participé à un projet Agile
    • Pratiquant
      • Comprends les principes et des pratiques
      • Travaille actuellement à un projet Agile et améliore ses connaissances/compétences
    • Avancé
      • Sait mettre en place et suivre un projet Agile
      • A une expérience en tant que Itération Manager (?) / Scrum Master
    • Expert
      • Possède une compréhension profonde des principes et des pratiques et peut les adapter pour coller à l’environnement de projet
      • Possède de l’expérience sur des projets Agiles dans des environnements variés
    • Master
      • A animé plusieurs présentation lors de conférences ou a écrit un livre
  • Compétences techniques
    • Débutant
      • Travaille dans une équipe en utilisant des compétences « core » ( Business Analyst, Developpeur, Testeur, Gestion de projet)
    • Pratiquant
      • Est référent dans une discipline dans une équipe
      • Établit des standards de pratique et de qualité dans une équipe
    • Avancé
      • Se tient au courant des meilleures pratiques et des courants de l’industrie dans la discipline
      • Est au courant des standards des pratiques dans d’autres disciplines.
    • Expert
      • Crée de nouvelles techniques, pratiques ou outils dans la discipline
      • Est reconnu par ses pairs comme un expert dans la discipline
    • Master
      • Reconnu dans l’industrie
      • Crée et publie des nouvelles techniques
  • Compétences business
    • Débutant
      • Comprends clairement le business que je supporte, l’environnement et le marché
    • Pratiquant
      • Aisance à discuter des processus et des objectifs business
      • Comprends les facteurs qui influence le succès business
    • Avancé
      • Comprends les courants du marché et est capable de fournir des conseils sur la stratégie
      • Est recherché pour des conseils business et des analyses d’impact
    • Expert
      • Comprends les risques et les éléments stratégiques et financiers qui impactent le business
      • Possède une expérience dans la tenue d’une unité business
    • Master
      • A lancé un business avec succès
      • Est recherché pour ses conseils à lancer un business
  • Compétences en facilitation
    • Débutant
      • A l’aise à travailler en équipe et à porter une équipe
      • Connait la base de la facilitation des cérémonies Agiles d’équipe
    • Pratiquant
      • Possède de l’éxperience dans la facilitation de discussion de groupe pour des problèmes complexes
      • Mène la facilitation des cérémonies Agiles d’équipe
    • Avancé
      • Mène des workshops sur plusieurs jours et des session de planification pour de larges équipes ou pour de nouvelles équipes
    • Expert
      • Facilite des sessions impliquant des problèmes humains complexes
      • Facilite des sessions impliquant de multiples parties-prenantes et des priorités conflictuelles
    • Master
      • Facilite des session de direction senior et/ou de grands groupes de personnes
  • Compétences en formation
    • Débutant
      • Apprécie d’aider les autres à apprendre
      • Praticipe aux initiatives de formation
    • Pratiquant
      • Possède une expérience limité à former de petites équipes
    • Avancé
      • A l’aise à former des groupes plus grands
      • Participe à développer et mettre à jour les contenus de formation
    • Expert
      • Possède une expérience significative de formation avec des formes multiples
      • A conçu et animé plusieurs cours
      • A l’aise à piloter et delivrer de nouveaux contenus de cours
    • Master
      • Est reconnu et recherché comme formateur
      • A formé plusieurs formateur
  • Compétences de coaching
    • Débutant
      • Comprends le rôle et la différence entre coach, mentor et consultant
    • Pratiquant
      • Fournit actuellement du coaching dans l’équipe actuelle
    • Avancé
      • Est reconnu en tant que coach et est capable de suivre un modele de coaching simple pour aider des personnes à résoudre leurs propres problèmes
    • Expert
      • Adapte son style de coaching en fonction de la situation, de l’équipe ou du niveau de l’organisation
      • Est à l’aise pour coacher des « exec »
    • Master
      • Reconnu et recherché en tant que coach au delà de l’Agile, mais dans d’autres domaines professionnels ou personnels
      • Capable de coacher des « exec » en chef (Chief quelquechose, les dirigeants en somme)

Agile Coaching Growth Wheel

Si l’on exclue la forme, ce troisième modèle est finalement assez proche du cadre de compétence de l’ACI. On y retrouve les principaux domaines et les sous-catégories.

Je suis un peu mal à l’aise avec ce modèle qui ajoute le domaine du conseil aux compétences du coach Agile. Pour faire simple, j’observe qu’il est actuellement difficile pour l’écosystème et les clients de comprendre le rôle d’un coach et la différence avec un consultant. Ajouter le conseil dans la boite à outil du coach participe au flou dans ce métier. Personnellement je préfère séparer le conseil du coaching.

Pour chacun des 8 segments, le modèle décrit 5 niveaux de compétences : débutant, pratiquant, « journeyperson », « craftperson » et guide.

Le modèle complète les critères déjà donnés par le modèle de compétences en matrice que nous avons vu juste avant, ce qui est parfait pour jauger de où nous nous situons. Je ne les détaille pas ici car c’est très bien fait sur l’article d’origine 🙂

Coach / Consultant

Avec les 3 modèles précédents, il est beaucoup plus facile de savoir ce qu’est un coach Agile et ce qu’il n’est pas. Comme il est plus simple maintenant de savoir où vous vous situez dans votre Agile Journey et quel pan de vos compétences vous souhaitez développer demain.

Il reste une zone incertaine et récurrente quand on parle de coaching Agile, je l’ai relevé avec le modèle en forme de roue : le coach est-il aussi un consultant ? Est-ce plutôt que le coaching est une des nombreuses cordes à l’arc du consultant ? Coaching et conseil n’ont-ils rien en commun ?

Soyons clair sur une chose : ce sont 2 postures distinctes. Le consultant apporte des solutions qu’il a rencontré dans sa carrière. Le coach apporte sa personne pour aider les individus à trouver eux-mêmes leur propres solutions.

Si ce sont des postures, cela signifie que l’on peut adopter l’une, comme l’autre. La chose la plus importante sera alors de clarifier avec le client la posture que l’on adoptera.

En guise de poursuite, je vous laisse écouter ce podcast de l’interview de Michel Giffard, qui a créé l’école de coaching HEC, concernant l’apport du coaching au conseil.

 

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 ?

 

2 outils simples pour améliorer notre rapport aux autres et à soi

Il suffit d’avoir vécu quelques expériences au sein de projets pour s’apercevoir que l’un des facteurs majeurs de succès est le niveau de collaboration et la confiance entre les membres de l’équipe, et aussi à l’extérieur de l’équipe.

Chaque individu participe à élever ou abaisser le niveau de collaboration et de confiance de l’ensemble de l’équipe. Chacun est une partie de ce qui se passe et de ce qui pourrait mieux se passer. La difficulté généralement est de savoir par où commencer pour améliorer les choses.

Je vous propose 2 outils assez simples issus de l’Analyse Transactionnelle (en très simple, l’AT est une manière de comprendre l’individu, les relations avec les autres et la communication) qui permet à chaque personne qui en a la volonté, d’apporter sa part et faire changer la façon dont le monde fonctionne, à son niveau :

  • Les positions de vie
  • Le triangle dramatique

Le premier de ces outils est très puissant car il permet de vérifier dans quel état d’esprit nous sommes. Première étape avant d’interagir avec les autres 🙂

Le second nous fait prendre conscience que l’humain fonctionne majoritairement et de manière inconsciente par des jeux psychologiques lorsqu’il y a conflit. Et ce jeu-ci est simple à détecter.

Les positions de vie

Notre position de vie est la croyance que l’on se fait de notre propre valeur et de celle de l’autre.

Chacun de nous exprime ces croyances à tout moment. Elles peuvent changer durant la journée, la semaine , le mois ou parfois rester la même.
Cette croyance possède deux états :

  • positif : on le verbalise par « je suis ok »
  • négatif : on le verbalise par « je ne suis pas ok »

Il y a donc 4 positions de vie où nous pouvons nous trouver :

  • Je suis ok , vous êtes ok (+/+)
  • Je suis ok, vous n’êtes pas ok (+/-)
  • Je ne suis pas ok, vous êtes ok (-/+)
  • Je ne suis pas ok, vous n’êtes pas ok (-/-)

Maintenant, que signifie chaque position de vie ?

Position +/+ : C’est la position idéale dans laquelle se trouver, donc celle à rechercher. On pourrait la concrétiser comme ceci : « J’estime avoir de la valeur et j’ai conscience de la tienne, nous nous respectons mutuellement. J’écoute réellement ce que tu dis et comprends que tu peux avoir un avis différents du mien et je ne chercherais pas à tout prix de te convaincre que j’ai raison. Nos échanges sont collaboratifs. »

Position +/- : « Je pense que je vaut mieux que toi ». Cette position se traduit par deux comportements bien différents : soit l’autre nous fait pitié du genre « mon pauvre ça n’a pas l’air simple, laisse je vais m’en occuper », soit nous le méprisons « c’est toi qui a fait ça ? ok la prochaine fois tu laisseras faire les pros s’il te plait ». Dans ces deux cas, nous avons un sentiment de supériorité.

Position -/+ : « Je pense que je vaut beaucoup moins que toi ». Cette position traduit un sentiment d’infériorité et nous nous dévalorisons. Un exemple de cette position serait « Oh la la, je ne vais pas aller lui parler ! Sur quel sujet intelligent je vais m’entretenir avec lui, il va me prendre pour un gros nul » ou « les autres font toujours mieux que moi ».

Position -/- : « Je ne vaut rien et toi non plus ». Cette position est dangereuse car c’est celle du renoncement, lorsqu’on n’arrive plus à voir du positif. Cela peut mener à la dépression.

Naturellement nous prenons tous une de ces positions par défaut. En prendre conscience va vous permettre de décider si vous êtes dans la position où vous souhaitez être, ou d’en changer 🙂

Le triangle dramatique

Voici quelques situations de vie :

Vous rentrez chez vous et vous parlez à votre enfant qui n’a pas fait ses devoirs, vous vous fachez contre lui car vous trouvez que cela n’est pas responsable ni acceptable, et votre femme prends la défense de votre enfant et vous explique qu’il a fait de son mieux, qu’il est tard et qu’il est temps qu’il aille se coucher.

Vous êtes développeur dans une équipe. Votre chef remonte une insatisfaction importante en effet le logiciel que vous développez comporte beaucoup d’anomalies. Vous expliquez que vous avez travaillé très tard ces dernières semaines, que vous aviez aussi des problèmes personnels qui fait que vous aviez la tête ailleurs, qu’en gros vous n’y pouvez rien.

Ces exemples sont des illustrations du triangle dramatique de Karpman.

Karpman a mis en évidence un jeu psychologique que l’on présente sous forme de triangle car il met en scène 3 rôles liés.
Lorsqu’un personne décide de se mettre volontairement dans un de ces rôles lors d’un échange (souvent conflictuel), l’autre personne est poussée à prendre l’un des deux rôles complémentaires. Oui c’est de la manipulation.

Ces rôles sont :
La Victime : Il s’agit d’une personne qui va chercher à se montrer comme faible, impuissante, agressée afin de ne pas être tenue pour responsable, de ne pas avoir à exprimer des idées ou à prendre des décisions. Cette position va attirer les Sauveurs qui voudront la sauver à tout prix ou va forcer une personne à prendre le rôle du Persécuteur pour justifier sa position.

Le Sauveur : Les personnes prenant un rôle de Sauveur recherchent de la gratification pour l’aide qu’ils accordent à la Victime. La conséquence de l’apport de cette aide est que la Victime reste dans l’inaction. C’est aussi une manière pour le Sauveur d’orienter son attention sur les problèmes des autres plutôt que sur les siens.

Le Persécuteur : Il s’agit de la raison d’être de la Victime. Il juge, critique, blâme, questionne.

L’entrée dans un triangle dramatique se fait soit par la Victime soit par le Persécuteur car la cause de cela est une mécommunication entre ces 2 acteurs.
Mais que ce soit par la Victime ou par le Persécuteur, l’autre acteur a le choix d’entrer ou non dans le triangle. Et si c’est un choix ce n’est donc pas une fatalité.

De même que les positions de vie, connaitre le jeu psychologique du triangle de Karpman permet d’être conscient de ce qu’il se passe et de l’accepter, ou de le refuser 🙂

Auto exercice pratique

Pensez bien qu’aucun de ces 2 sujets ne résout des problèmes, ils mettent en évidence ce qui se passe entre des personnes ce qui est déjà énorme vous en conviendrez.

Après cette lecture, est-ce que tout cela vous parles ?
Quelle position de vie prenez vous naturellement ?
Et avez-vous identifié des situations personnelles où le triangle de Karpman se manifeste ?
Quel a été votre rôle ?
Maintenant que vous connaissez le « truc », comment allez vous en sortir ?

 

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 ?



 

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 😀

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 🙂