Etant en pleine formation de coaching professionnel je rédige cet article pour plusieurs raisons.
La première est que par cette formation mon esprit s’attache plus facilement aux discussions qui ont lieu sur internet et qui ont pour sujet le coaching et je vois beaucoup d’incompréhension sur la définition même de cette activité qui amène à, soit la considérer comme du bullshit, soit carrément comme du charlatanisme et de la manipulation.
La seconde est que pour les besoins de cette formation, et au delà de celle-ci pour clarifier cette activité auprès de mes clients, j’ai besoin d’avoir une définition avec laquelle je me sens à l’aise et à laquelle je pourrai me référer si j’en ai besoin.
TL/DR
En quelque mots le coaching est un accompagnement, une relation d’aide qui prend une forme particulière. Elle prend la forme d’une série d’entretiens individuels généralement d’une heure, entre une personne souhaitant se faire coacher et un coach.
L’objectif est d’aider la personne à atteindre son ou ses objectifs en trouvant elle-même ses propres solutions. Le coach n’apporte donc aucune solution.
Généralement on a recours au coaching pour répondre à 4 grandes familles de problèmes :
Le développement de la personne, les problèmes situationnels
Les relations inter-personnels
Les relations au sein d’un groupe
Les responsabilités en tant que dirigeant
C’est non
J’ai donné 4 grandes catégories mais le contexte dans lequel entrent ses catégories peut être large CEPENDANT ce qui ne changera pas c’est la posture que de coach tiendra : il apporte sa personne pour servir de miroir au coaché et l’aider à naviguer dans ses réflexions pour qu’il y trouve ses solutions pas pour lui expliquer ce qu’il ou elle n’a pas compris et lui donner la manière dont il ou elle doit s’y prendre pour solutionner son problème.
Autrement dit, les coachs en maquillage, les coachs en jeux vidéos, les coachs en amour, etc. ne rentrent pas dans cette catégorie.
Généralement leur activité s’apparente plutôt à du conseil, pour les plus sérieux. Et ce sont ces catégories, qui utilisent abusivement le terme de coach qui ternissent et abiment l’image du coaching.
Le succès d’un coaching
Le coaching n’a rien de magique, pour obtenir des résultats il faut que vous ayez l’intention de vouloir travailler. Le coach vous accompagne dans votre cheminement vers la résolution de votre problème et sera totalement orienté vers cela, il attendra de votre part la volonté d’avancer, que ce soit pendant les séances de coaching ou en dehors.
Cela présuppose avoir l’idée d’un objectif à atteindre, qui soit réalisable, dans un temps relativement court. Un coaching se déroulant sur une période de six mois à un an en général.
Un autre critère important sera le fit avec le coach. Chaque coach a une personnalité et donc une pate que lui est propre, soit elle convient, soit non. Dans le dernier cas il vaut mieux changer de coach plutôt que de rester avec une personne avec laquelle la confiance ne s’instaure pas. C’est valable pour le coaché comme pour le coach 🙂
Trouver un coach
J’ai repris les critères de François Délivré qui met la barre assez haute.
Un coach professionnel :
a reçu une formation générale de coach et, si possible, dispose d’une expérience dans le métier.
dispose d’une déontologie, l’affiche et la respecte
a fait un important travail thérapeutique afin de connaitre ses zones d’ombre et empêcher qu’elles ne viennent perturber le travail avec ses clients
a recours régulièrement à un superviseur pour traiter les difficultés personnelles auxquelles pourrait le renvoyer son travail avec des clients, et pour accroître son professionnalisme
sait poser un diagnostic sur de client et, si nécessaire, sur son entreprise. Pour cela le coach maitrise au moins une approche de base en psychologie et dispose de référents théoriques pour analyser les groupes et les entreprises
dispose d’une culture générale du métier de coach : connaissance du monde de l’entrepris, lecture d’ouvrages spécialisés, ouverture à d’autres référents que le sien, etc.
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.
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 🙂
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.
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 🙂
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.
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)
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 :
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.
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)
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.
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.
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.
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.
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’ilest 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ésolutionde 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é ^^
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
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.
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 ?
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Durée
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
