Disclaimer
Bonjour les agilistes ! Veuillez pardonner le côté vaniteux de l’introduction à venir. Je me dois de caricaturer en quelques lignes le cheminement ayant abouti à ce blog. Dans la réalité, les choses étaient plus subtiles. Veuillez pardonner aussi le ton volontairement taquin (et qui ne me ressemble pas) de cet article et du talk en devenir. Je pense que ce n’est que de cette manière que le message que j’essaie de faire passer sera, un peu, entendu 😉
Clarifions mon intention
Lorsque j’ai lancé coach-agile.com, que j’aime décrire plus comme un outil que comme un blog, mon intention, simple et bête, était de lutter contre la rareté artificielle qui commençait à se mettre en place dans mon métier.
J’entends par là que je croisais de nombreux consultants et coachs agile qui ne souhaitaient pas transmettre leur savoir. Par exemple, le fait de garder secret certaines techniques d’animation d’atelier pourtant simple à transmettre (Personae, story mapping, …) permettait de conserver une impression d’expertise et donc, entre autres, de se vendre à des tarifs élevés. À l’époque, faire venir un “expert” pour faciliter un speed boat était encore courant.
À la manière de Dave Snowden qui aime à se décrire lui-même comme un irritant constructif, mon intention avait été de diffuser massivement ces techniques d’animation pour faire avancer un peu les choses en empêchant ces pratiques que je jugeais, finalement, dévalorisantes pour la profession. Pour ce faire, l’idée était de diffuser et transmettre gratuitement l’intégralité de mes supports et de mes outils via ce site ! Mon espoir était de pousser certains “exploiteurs de tout fait” à se poser de bonnes questions et à se réinventer.
Finalement, mes tentatives d’automatiser un coach agile suivent la même intention : En ce moment, j’ai l’impression de croiser de plus en plus de consultants et coachs agile ne cherchant pas à creuser ou comprendre le sens profond des choses mais simplement à “faire appliquer” ou “mettre en place” telles ou tellse pratiques ou tel ou tel framework. Bienvenue dans l’ère du cargo cult !
Loin de moi l’idée de ternir l’image du métier de coach agile. L’idée est d’automatiser ce qui est automatisable pour recentrer nos interventions là où nous pouvons apporter de la valeur.
Pourquoi automatiser le métier de coach agile ?
Je discutais récemment avec un co-signataire du manifeste agile travaillant sur les systèmes embarqués de certains satellites.
Il jugeait lui-même sa manière d’accompagner sur le chemin de l’agilité les équipes auprès desquelles il intervenait simple et efficace, mais en décalage avec l’extrême complexité des logiciels développés par ces mêmes équipes. À l’heure du machine learning et de l’intelligence artificielle, faire émerger des équipes de meilleures manières de travailler à base de post-its lui semblait un brin obsolète. Voir archaïque. Quand je lui ai soumis l’idée de ce talk, il m’a simplement répondu “just do it“. Il n’en fallait pas plus pour me donner envie de me lancer dans cette tâche et tenter d’automatiser un coach agile !
Car oui, vous lecteur, n’avez-vous jamais effectué deux fois la même action dans deux contextes différents ?
Et d’ailleurs, arrêtons de répondre “cela dépend du contexte” : pouvons-nous assumer que le fameux “contexte” peut se décomposer en une somme de variables identifiées et mesurables (humeur des équipes, pratiques, …) ?? Nous y reviendrons plus tard…
Ensuite, c’est tout simplement le sens de l’histoire. Aujourd’hui, des plus en plus de métiers sont automatisés : Des métiers apparemment simples comme caissier et d’autres, apparemment plus complexes comme le métier de manager, avocat, Psy médecin… ou même développeur ! Certes, cette automatisation provoque systématiquement une légère dégradation de la qualité de service. Mais elle permet aussi de transmettre à moindre cout des compétences, de rendre une expertise plus accessible, d’étendre des pratiques. Voir un restaurateur faire appel à un coach agile automatisé (Et oui, un restaurant bien géré, finalement c’est du Kanban) ce serait top non ? Le ferait-il s’il fallait faire appel à un expert se vendant à 1500€/jour ?
Pour résumer, j’aime beaucoup la métaphore du copilote sur la route de l’agilité. Je compare le coach agile de 2022 à un copilote qui guide son client (le pilote au volant de la voiture) avec ses outils, cartes, boussole, etc.
Je propose de passer au GPS. Est-ce possible ? Techniquement ? Ethiquement ?
Discutons-en !
Automatisation ne signifie pas machinisation
Alors pour tout de suite me contredire… ou plutôt apporter un peu de subtilité, disons le tout de suite : Automatisation ne signifie pas forcément machinisation. Je décrirais plutôt l’automatisation comme la formalisation consciente d’un ensemble d’automatismes inconscients que nous développons au cours du temps. Pour schématiser, je me définissais comme cela :
“Je suis un humain talentueux, et je n’agis pas selon un set fini d’automatismes appris selon des comportements que j’ai imité ou été contraint d’inventer…”.
Vous le devinez mais ceci est malheureusement faux !
Mon objectif est d’identifier ce qui est générique afin d’assumer et de conscientiser que j’ai développé certains automatismes pour pouvoir les dépasser. Car c’est en identifiants et dépassant ses automatismes par cette conscience qu’on devient capable de les coder en partie dans divers dispositifs. Ensuite, il faut garder en tête qu’une automatisation est un processus qui se déroule étape par étape : la part de contribution humaine du coach se réduirait donc au fur et à mesure via des dispositifs (Serious Game, outils, …) de plus en plus puissants.
Par exemple, si vous considérez le burn down chart, n’est ce pas un outil simple micro-distribuant les compétences d’un bon agiliste à l’ensemble d’une équipe ? Si ? Alors cet outil pourrait être identifié comme un pas de plus sur le chemin de l’automatisation du coach agile. (merci Jean-Pierre pour l’exemple !) Ou encore… qui diffuse des vidéos de Scrum Life au sein de ses formations ?
Tout cela fait partie d’un processus d’automatisation du coaching agile !
Je parle de divers dispositif car… même si la miniature de cet article reprend, encore une fois pour taquiner (cf le disclaimer), un Terminator, vous l’avez compris, automatiser ne signifie pas forcément machiniser. Il s’agit plus de décomposer son expertise, d’identifier ses propres automatises et de produire des outils utilisables par d’autres afin de dé-rarifier ses compétences.
Pour reprendre les mots de Steeve Evers, futur retraité :
“Je ne sais pas si automatiser est un bon terme en effet. Cependant, comme pour des thérapeutes, il est tout à fait possible et même souhaitable d’être capable de mettre en oeuvre et donc de reproduire (quitte à les amender) des protocoles, c’est à dire, mettre en œuvre une suite d’activités dont il est vraisemblable d’attendre un résultat (parce que le protocole est suffisamment éprouvé et sur). Par exemple, je suis face à un accompagné qui est confronté à un problème, je peux utiliser un protocole (script de questions par exemple) pour l’aider à trouver une solution.”
En fait, comme nous allons le voir, le processus d’automatisation de notre métier est déjà en marche. En exemple, prenons la facilitation :
Cela a déjà commencé
Exemple avec la facilitation
Lorsque j’ai débuté le métier de Scrum Master, un peu avant 2010, il existait de la documentation non structurée accessible sur net, notamment sur le blog de Claude et au travers de lectures.
Au fil des années ces données se sont structurées. J’entends par la qu’elles se sont classées, catégorisées, uniformisées pour être plus facilement exploitables. Pour résumé, nous sommes passés d’article décrivant “comment animer un atelier agile” à du contenu variabilisé (dans l’exemple : nombre de participants, durée, objectif, …).
Depuis 2021, j’observe même l’émergence de moteur de recherche intelligent permettant d’entrer les objectifs que nous souhaitons atteindre, ce que nous souhaitons accomplir. Comme la malle à atelier de Bloculus !
Encore plus récemment, début 2022, l’émergence de générateur d’atelier sur mesure comme par exemple l’Open Serious Game workshop design cards.
Du point de vue d’une personne extérieure, nous sommes donc passés du contenu descendant (et inspirant) à des outils permettant à chacun de produire eux-mêmes leurs ateliers en fonction des objectifs fixés.
L’automatisation du métier de facilitateur avance donc à grands pas… Mais être coach agile va bien au delà de la facilitation non ?
Et au delà de la facilitation ?
Le sujet de cet article n’est pas de définir le métier de coach agile. Lyssa Adkins, Christophe Keromen ou encore Martial Segura l’ont fait bien mieux que moi :
Un coach est un acteur de la transformation qui va aider une personne (la « coachée ») ou une équipe à trouver elle-même les réponses dont elle a besoin pour lui permettre d’atteindre le résultat (ou l’objectif) qu’elle s’est fixé.
Pour cet article, je me suis cependant intéressé au métier de coach agile non pas vu par les agilistes mais plutôt vue par nos clients.
A cet effet j’ai sollicité une grande partie des clients avec qui j’ai été amené à travailler en leur soumettant un sondage ouvert sur les outcomes attendu d’un coach agile.
Les résultats de ce sondage (un peu plus de 900 participants à date) correspondent plutôt bien à Agile Coaching Wheel que je vous partage ci-dessous. Pour simplifier, et avant d’entrer de nouveau dans le processus d’automatisation, je me base volontairement sur cette catégorisation, certes pleine de choses à (re)dire :
Nos clients attendent d’un coach agile qu’il soit :
un formateur, car la formation fait partie intégrante de notre activité pour transmettre de nouvelles manières de travailler, plus collaboratives plus efficace ou pour simplement apprendre à remettre en question les manières de faire.
un coach professionnel qui crée un cadre propice au changement et sécurisant pour les personnes. Il écoute, il questionne et accompagne une personne, une équipe ou une organisation dans son parcours. il agit en « position basse », dans une posture de questionnement de l’autre.
un mentor qui partage ses connaissances, ses compétences, ses points de vue et qui encourage le développement personnel et professionnel de l’autre.
un facilitateur qui aide un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions, obtenir une décision commune en créant l’espace propice pour l’émergence d’idées, d’innovations, de discussion entre les collaborateurs.
un consultant agile car il est nécessaire parfois/souvent d’agir en position haute et de conseiller ou orienter pour déclencher un mouvement et obtenir des résultats.
Exemple avec le métier de consultant agile
Comme nous l’avons vu précédemment, la casquette de “facilitateur” du coach agile est sur le chemin de l’automatisation. Pour pousser plus loin mon raisonnement, je me propose d’illustrer l’automatisation possible d’un consultant agile.
Vous rappelez-vous de l’ Open Serious Game “Agile Smells Bad” ? Non, alors je vous invite à jeter un œil à cet article. Cet outil permet d’identifier certains anti-patterns dans les pratiques d’une équipe.
En l’utilisant en mission, j’arrive à rapidement déceler certains points de douleur grâce à ce serious game et j’aime co-construire avec les équipes de nouvelles manières de travailler pour gommer ou déplacer ces points de douleurs. Pour être simple, je propose des “bons patterns organisationnels” à expérimenter. Ensuite, nous attendons et observons les résultats sur l’équipe et nous ajustons.
Cette mécanique, certes caricaturale et caricaturée ici, est le raisonnement que nous appliquons lorsque nous endossons la casquette de consultant agile. Ainsi va voir le jour bientôt (oui je spoil) la suite de Agile Smells Bad. Un tout nouvel Open Serious Game nommé Agile Smells GOOD !
Agile Smells GOOD permettra de proposer des expérimentations à mener en face des douleurs décelées avec le premier jeu. Pour mieux comprendre, vous trouverez quelques exemples illustrés ci-dessous :
[new_royalslider id=”36″]
Voyez-vous émerger l’automatisation du consultant agile ? Un robot, comme Siri ou Cortana effectuant une analyse de phrases prononcées pourrait donc identifier des anti patterns définis et points de douleur ressortant d’un discours en l’alimentant avec suffisamment de données structurées. Puis, en identifiant le contexte de l’interlocuteur (rappelez vous, notre fameux “contexte” n’est qu’une somme de variables observables et mesurables !) pourra proposer des expérimentations ou solutions. Pour information, ce “robot” est en version alpha en cliquant sur le bouton vert en bas à droite de ce site (à date j’utilise un bot whatapp web). Dites m’en des nouvelles !
Peut-on le faire ?
Lorsque j’ai soumis le sujet de ce talk à mes amis agilistes, j’ai rencontré une levée de boucliers (et c’est tout à fait normal ! ). Je reste néanmoins persuadé qu’il est possible d’automatiser un coach agile (et même que cela arrivera). Je vais néanmoins rapidement (et non intelligemment) répondre à quelques contre argument qu’on m’a amené !
Limites techniques
C’est impossible d’automatiser dans le domaine du complexe !
Automatiser dans un monde complexe est impossible ? Alors jetez votre ordinateur et votre téléphone portable ! Dans notre monde VUCA, nous nous créons des outils nous facilitant le quotidien, … automatisant des tâches que nous faisions manuellement (je ne vais pas tout citer mais cela va de l’application “liste de courses” à la domotique).
Autre sujet intéressant, Dave Snowden lui-même, le père de Cynefin, devrait amener quelques informations cette années (2022) sur le fait qu’il est possible de tendre vers l’automatisation dans le monde du complexe.
Limite éthique
Est-ce bien éthique que de transformer une partie de l’accompagnement du coach en quelque chose d’automatique/ sans intervention d’un humain ?
Sans répondre à un argument tel que celui ci par une punch line bien sentie (du genre, l’humain au centre ne signifie pas forcément le coach agile au centre) la question de l’éthique se pose. Pour reprendre les mots de mon bon ami Alexandre Quach :
J’ai discuté avec une coach agile ce matin. Elle m’a fait prendre conscience de variables et de types de décisions qu’on ne peut pas déléguer simplement à la machine, ou du moins sans pré-parametrage. Pour simplifier et résumer, l’utilisateur doit pouvoir choisir les biais qu’il souhaite appliquer. Par exemple veut-il un système egalitariste ou élitiste ? Concrètement, un facilitateur pour vouloir rééquilibrer le temps de parole pour certains segments de populations.
Doit-on le faire ?
N’oublions pas que le rôle du coach agile et d’accompagner les équipes vers un fonctionnement agile afin d’améliorer leur manière de travailler, il y parvient en faisant faire réfléchir l’équipe par elle même et en la rendant responsable et engagée sur le fonctionnement qu’elle met en place.
« C’est la personne coachée qui dispose de toutes les ressources nécessaires pour atteindre son résultat attendu ».
Pour revenir à la question posée dans le chapitre précédent et à ma métaphore du GPS : vous êtes libre de penser par vous-même et d’adapter les réponses proposées par votre outil. En d’autres mots, un coach agile automatisé ne doit pas vous empêcher de réfléchir !
Pour plaisanter : Première tentative d’automatisation d’un coach pro
Comme je l’évoquais en guise d’introduction de cet article, des applications remplacent votre psy… un certain temps.
IL semble donc possible d’automatiser un coach pro. Voici quelques grands principes que nous pourrions mettre en place au sein d’un algorithme :
- Ne presque jamais interrompre un silence : Une interruption ne doit jamais porter sur le contenu du dialogue, et ne doit jamais couper un silence…
- Néanmoins, le coach a droit à des ponctuations verbales positives : Bravo ! Yes ! Clair !
- Le coach a le droit à la répétition du dernier mot ou d’un mot-clé qui doit être positif pour faire avancer un conversation qui stagne.
- Demande la permission avant d’interrompre :
- “Est-ce que je peux me permettre de t’interrompre ?”
- Fait une synthèse courte au besoin
- J’aimerais faire une synthèse courte si tu veux bien. Il me semble que [tu connais bien ton sujet], [tu as plusieurs options]…
- Exprime sa position basse :
- “Je me trompe peut-être, je ne suis pas sûr…”
Tiré des enseignements suivants :
- Ne jamais interrompre le silence. C’est pendant les silences que le client travaille.
- Les meilleurs coaches sont minimalistes. Un robot est minimaliste 🙂
- Ne pas être trop dans la bienveillance. Savoir interrompre de manière respectueuse et ferme.
- Le coaching est disruptif : l’interruption est la clé.
print(‘A quel résultat veux-tu aboutir au bout de notre échange ?’);
try {
if(lowposture== valuable)
{
listen;
print(‘ Si tu avais une baguette magique qui t’amène directement au résultat que tu veux, peux-tu le décrire ? ‘);
listen;
print(‘Que peux-tu faire aujourd’hui pour en arriver là ?’);
}
if(highposture==requested)
{
print(‘Humm … let’s have a look to the Scrum Guide !’);
}
} catch (error) {
print(‘Why?’);
}
et ponctuer de : “je suis pas sûr de comprendre” / “j’aimerais réagir sur ça” / “si je peux me permettre d’être franc” / “Pour être totalement honnête”
Ce qui n’est pas automatisable… facilement :
- Le coaching n’est pas politiquement correct. On peut soupirer de lassitude, plaisanter, avoir des émotions.
- Le coaching est le contraire de l’apport de solution. Si je coache un tennisman pro, je ne vais pas lui apprendre à jouer au tennis. Il faut respecter l’intelligence du client.
- La peur du silence, c’est la peur de l’intimité. Hors être silencieux devant une machine me parait moins efficace que face à un humain.
Encore quelques mots
L’automatisation du coaching agile pourrait-être à rattacher à l’évolution globale des organisations. En effet, il me semble que nous sommes entrés dans l’accompagnement des organisations retardataires (du point de vue de l’agilité) ce qui implique sans doute une autre manière de mener nos accompagnement. Automatiser les parties non-intéressantes du coaching agile permettrait de nous focaliser de nouveau sur les activités impactantes de nos interventions. Surpasser l’effet waouh pour le transformer en effet durable ? Consolidons ce qui est utile et abandonnons ce qui ne l’est pas. Continuons à innover !
Mentions
- Alexandre Quach qui est une source d’inspiration tout en me rendant maladivement jaloux. Merci pour ton amitié et nos conversations. Les phrases interpellantes de cet article sont de lui !
- Remi Saraillon pour les illustrations ! Sans lui, pas de talk !
- William Bartlett pour les échanges riches et variés ! Moi aussi j’aime le débat !
- Les communautés cynefin, serious scrum et scrum life pour les échanges riches autour de ce sujet !
[new_royalslider id=”37″]
Depuis quelques mois j’avance sur un A.I capable d’endosser une posture haute et, tout en tenant compte d’un contexte donné, de proposer des idées / expérimentations / conseils à son interlocuteur.
Pour cela j’utilise GPT-3 de OpenAI que vous pouvez directement tester ici : https://beta.openai.com/playground.
Nous présentons ces résultats avec Scrum Life le 29/09/2022 !
J’avoue que le titre m’a surpris et j’ai adore le contenu!
Merci pour ce moment de lecture 🙂