Bonjour Alexandre! Tout d’abord, pouvez-vous vous présenter en quelques mots et nous en dire davantage sur votre parcours ?

Bonjour, je suis un coach organisationnel et Agile Technique, j’aide les organisations à diminuer leur complexité interne en passant sur une structure simple qui soit facilement mise à l’échelle. Je travaille avec les équipes IT pour qu’elles adoptent des pratiques modernes de développement, mais également une pensée orientée sur la collaboration et la responsabilité commune.
J’ai un long parcours de plus de 25 ans d’expérience, du développeur par passion, au développeur professionnel, j’ai commencé mon apprentissage de la programmation à l’âge de 12 ans, avec le Basic, l’assembleur et le Pascal. J’ai obtenu ma première certification de programmation à l’âge de 15 ans, et depuis j’ai pratiqué différents langages, comme le Perl, Fortran, Modula 2, Java, C#, Kotlin, Python, Elixir, Elm et Typescript. J’ai été architecte, évangéliste XP (Extreme Programming), formateur, Scrum Master, Product Owner, CTO, CEO et aujourd’hui Coach Organisationnel et Coach Agile Technique (ce que l’on nommait anciennement évangéliste XP).

Rentrons dans le sujet. Pour vous, en quoi consiste le Technical Agile Coaching ?

Le Technical Agile Coaching est la capacité de guider des équipes sur des pratiques modernes de développement, mais pas uniquement. Il faut être capable de transformer ces personnes en une équipe qui collabore avec des objectifs communs et qui soient en capacité de s’améliorer en continu. Pour ça, il ne faut pas seulement avoir une solide expérience technique, mais également un bagage de métier dans la facilitation, le coaching professionnel, le mentoring et la formation. J’aime dire qu’il ne faut pas amener les pratiques sur un plateau doré, mais il faut que ces personnes comprennent d’elles-mêmes le pourquoi et le comment. Sinon cela passera d’une oreille à une autre et quand le coach part, tout tombe.

Quelles sont les problématiques initiales des clients, et les objectifs qui vous sont fixés ?

Cela dépend de qui est votre interlocuteur, mais il y a bien souvent le même problème racine.
Si je parle avec une personne qui a un poste de direction d’entreprise, elle voudrait que ses équipes puissent produire plus vite, mais tout va de plus en plus lentement. Malgré l’adoption d’une pratique Agile, Scrum par exemple. La définition de la “Business Agility est la capacité d’une organisation à s’adapter au contexte du marché rapidement.” Néanmoins, la vitesse réelle est celle de l’unité la plus lente, et souvent on retrouve des applications avec une dette technique qui n’est plus maîtrisable.
Si je parle avec les architectes et CTO, ils ont un objectif d’amélioration de la qualité, une meilleure maitrise des applications par de bonnes pratiques. Mais voilà, même si ces personnes adhérent progressivement à des valeurs comme le Craft (Artisanat Logiciel), elles n’ont ni le temps ni le savoir nécessaire pour transformer leurs équipes.
Pour ces deux types d’interlocuteurs, l’objectif ultime est déjà l’amélioration des retours clients, un client content, cela rend les équipes dirigeantes et de développement heureuses, et cette satisfaction nous aide dans notre productivité.

Selon vous, y’a-t-il des skills (soft et hard) nécessaires pour exercer ces missions ?

Oui, comme j’en ai parlé ci-dessus, il est important que le ou la coach agile technique n’ait pas seulement une expérience technique, mais bien plus que ça :

• Pratique et connaissance des différents TDD, BDD, Pair programming, Mob programming, architecture hexagonale…
• Connaissance des différentes pratiques de compréhension du besoin, comme l’Impact Mapping, le Story Mapping, l’Event Storming, Domain Storytelling, DDD, Specification by Example
• Pratique et connaissance de l’intégration continue, du continuous delivery, devOps
• Pratique dans la facilitation, le mentoring, la formation type “From behind the classroom”
• Avoir au moins commencé une formation de coaching professionnel; dans mon cas, j’ai commencé à suivre le coaching systémique “ORSC”, que j’espère pouvoir la continuer dès que les formations en présentiel seront à nouveau possible.
• Etre capable de communiquer autant avec les équipes, qu’avec le management, voire la direction. Vous avez besoin d’être crédible à tous les niveaux.
• Comprendre et appliquer la pensée systèmique, et le fonctionnement d’une équipe, par exemple je me réfère souvent du livre “The 5 Dysfunctions of a Team” de Patrick Lencioni.

Concrètement, êtes-vous à 100% du temps avec une équipe ? Y’a-t-il une journée type ?

Oui quasiment, j’interviens par demi-journée par équipe. Pour la plupart des équipes que je suis, la session se déroule de la façon suivante :

• Retrospective sur ce qu’on a observé, entendu ou appris lors de la session précédente
• 30 min max de theorie
• Reste de la session au format Mob Programming:
  • Kata
  • Code de production
  • Atelier
• Petite retrospective sur ce que l’équipe a pu ressentir et observer

Quelles sont les conditions à réunir pour que la mission de coaching soit une réussite ?

Il faut forcément l’appui du management, qui va accepter que son équipe fasse autre chose que seulement produire du code ou des documents. Dans mon cas, je ne demande qu’une demi-journée par semaine !
Et évidemment, il ne faut pas d’équipes composées uniquement de personnes réfractaires.
Dans le Coaching Agile Technique, comme son nom le porte, il y a du coaching seulement si les personnes concernées sont d’accord d’être coachées.

Est-ce que vous vous appuyez (ou vous vous inspirez) de certaines méthodes de coaching existantes ?

Oui bien sûr, comme je l’ai dit au dessus, je me forme actuellement au “Organisation Relation and Systemic Coaching”, et j’utilise aussi des lectures de livres comme par exemple ceux de Alain Cardon et Kathy Anderson sur le Polarity Coaching.
Après j’utilise également mes connaissances en facilitation d’événement et la méthode “Training from back of the room”.

Pouvez-vous nous dire en quelques mots en quoi consiste “Organisation Relation and Systemic Coaching” ?

Le mieux est que je vous donne la description que l’on trouve sur leur site:
“Le programme ORSC propose un changement de paradigme dans la façon dont nous pensons et ressentons, agissons et réagissons dans différentes circonstances et dynamiques relationnelles : en entreprise, en famille, dans les milieux éducatifs et plus généralement dans les communautés du monde entier. Elle s’appuie sur 7 méthodologies – Pensée Systémique, Process Work, Théorie du Développement Organisationnel (TDO), Thérapie Familiale, Résolution Alternative des Conflits, Physique Quantique et Coaching Co-Actif – les programmes ORSC prônent le changement au travers de l’engagement conscient et responsable des personnes et de leurs relations.”

Avez-vous des pratiques ou des formats d’ateliers que vous privilégiez dans le cadre de vos coachings ?

Actuellement je privilégie le format que partagent Marco Consolaro et Alessandro di Goia d’Alcor.Academy, que j’ai rejoint en novembre 2021. Il est basé sur le format “Training from the back of the room”. L’essentiel est que les participants découvrent par la pratique les bonnes habitudes. La session est un mélange de formation, facilitation et mentoring. C’est un format que j’aime beaucoup, j’ai actuellement de bien meilleurs résultats que dans d’autres approches que j’ai pu mettre en oeuvre dans le passé.

On imagine parfois que certaines personnes dans les équipes peuvent être réticentes au changement et à faire évoluer leurs pratiques. Comment gérez-vous ces cas-là ?

La règle dans chaque gestion du changement, c’est de ne pas forcer les personnes tant qu’elles ne sont pas des éléments dérangeants pour les autres. On va utiliser le pouvoir des modèles de décision. Quand vous voyez que vos collègues commencent à adhérer, à en parler de façon positive aux autres, tôt ou tard, vous allez mettre votre égo dans la poche et commencer à vous intéresser. Il ne faut surtout pas perdre votre temps à essayer de changer quelqu’un qui ne veut pas changer.
Maintenant, il m’est arrivé que je donne à une personne un problème complexe à faire sans appliquer le TDD, puis je l’ai laissé réaliser à sa façon et enfin je lui montre comment je l’aurais fait avec du TDD. Il y a pas photo, je suis plus rapide.

Quelles sont les autres difficultés quotidiennes auxquelles vous êtes confronté ?

Quand l’organisation n’est pas prête à donner un peu de temps aux équipes pour s’améliorer, on a systématiquement des développeurs et développeuses sur des incidents ou autres demandes pendant la session de coaching. Pourtant ce sont des sessions que nous avons planifié à l’avance, il y aurait la possibilité de trouver d’autres personnes pour résoudre le problème.

Est-ce possible de mesurer l’impact de votre accompagnement ? Grâce à quelles méthodes ?

Directement non, mais indirectement oui, comme pour chaque mission de coaching, on travaille sur les individus et l’équipe. Cela ne peut se mesurer directement. On va plutôt mesurer le niveau de satisfaction, le nombre de features livrées sur une période moyenne, etc.

Y’a-t-il une durée type de l’accompagnement ? Est-ce qu’il y a un moment où l’on ressent que le coaching doit prendre fin ?

Il n’y a pas vraiment de durée type d’un accompagnement, on travaille avec des humains, pas des machines. Par exemple pour le programme TDD, l’apprentissage se fait en 3 modules de 6 demi-journées. Le module DDD que j’avais donné l’an passé a été aussi de 6 demi-journées.
Après ces modules, je propose souvent un accompagnement pour s’assurer que ce qu’ils ont appris reste et perdure dans le temps.
Donc je pense, qu’il faut entre 6 et 12 mois, sachant que je ne suis jamais à plein temps avec une équipe.
Et oui, on le sent quand une équipe peux s’envoler sans le coach, c’est pour moi très gratifiant et c’est le moment de partir.

Avez-vous observé un temps moyen de coaching à partir duquel vous commencez à percevoir un impact ?

Selon le sujet, par exemple de l’Event Storming, après 2-3 jours l’équipe est autonome. Pour du TDD, sujet beaucoup plus complexe, je dirais qu’il me faut au moins 12 demi-journées.

Quelles sont les erreurs fréquentes ou les écueils à éviter lorsqu’on exerce du Coaching Agile Technique ?

N’ayez pas peur de dire quand vous ne maitrisez pas un sujet, vous êtes un humain et vous travaillez avec des humains. Tôt ou tard, on va le voir si vous parlez de chose que vous ne maitrisez pas. Quand vous expliquez quelque chose, c’est votre opinion, pas un fait, sinon il faut montrer vos sources.

Qu’est-ce qui vous a donné envie, dans votre carrière, de commencer cette d’activité ?

Très tôt dans ma carrière, j’ai toujours aimé partagé mes connaissances avec les autres en donnant des formations techniques, en étant Evangéliste XP (ancien terme du début 2000). Je suis également orateur dans les conférences internationales depuis plus de 10 ans et j’ai co-fondé plusieurs communautés Agile et de Software Crafts.

Est-ce que vous observez depuis ces dernières années une évolution dans l’attention que portent les entreprises sur la qualité de leurs développements ? Si oui, comment l’expliquez-vous ?

Nous observons beaucoup d’entreprises qui ont comme objectif stratégique d’embrasser le monde digital et d’être plus compétitif dans ce monde VUCA (Volatile, Incertain, Complexe et Ambigu). On promet à ces responsables d’entreprise une accélération de leur capacité a répondre rapidement à ces changements de contexte. Certes vrai sur le papier, mais en réalité, la vitesse réelle de l’organisation est celle la plus lente de son système. Imaginez un “*Aigle avec un plomb au pied*”, il a beau être un oiseau rapide, mais avec un plomb on n’avance pas plus vite. Ce plomb, c’est souvent le service Informatique et tout son historique logiciel.
Du coup vous avez d’un côté la direction qui ne comprend pas pourquoi on ne va pas aussi vite que souhaité et de l’autre un service informatique en mode burnout, qui ne sait plus quoi faire pour s’en sortir, faute de moyen. Certes l’adoption de l’agilité et/ou du DevOps aide, mais ce n’est souvent pas suffisant, car on a rarement adressé le coeur du problème. On a juste préparé l’après, mais ce qui existe reste.
Beaucoup de responsables informatique sont justement des personnes qui ont comme mission de mettre en place des pratiques modernes de développement. Mais que beaucoup d’entre elles n’ont pas le temps ou la patience de le faire. C’est dans ce moment-là que l’on fait appel à des personnes comme moi pour solliciter leur expérience.

Avez-vous observé une évolution dans les profils des nouveaux développeurs et nouvelles développeuses qui débutent dans ce métier, par rapport à 10 ans en arrière par exemple?

Je commence à rencontrer des jeunes développeurs et développeuses qui connaissent les pratiques modernes de développement, ce qui était très rare encore il y a 10 ans. Il y a beaucoup plus de monde qui vient aux événements communautaires sur le même sujet.

Le terme “Coach Craft” revient souvent, est-ce que pour vous cela fait référence au coaching agile technique? Est-ce que ce terme vous convient?

Je ne suis pas surpris qu’on viennent avec le terme Coach Crafts, mais je le trouve déjà dépassé, depuis 2020, on parle de modernisation logiciel, c’est bien plus que seulement du Software Crafts. On parle également de Culture d’entreprise, d’équipe, de crafts, de DevOps, Agile, de compréhension du besoin. C’est par exemple la voie qu’une partie de la communauté Crafts a décidé de suivre. Quand je lis les post francophones sur le Crafts, cela se limite souvent seulement à des sujets technique.
Je pense qu’on veut limiter à une communauté et c’est déjà contraire à la philosophie derrière le Software Crafts.

Avez-vous un blog, meetup ou autre où l’on peut suivre votre activité ?

On peut me suivre sur mon site https//www.socraagile.ch ou me suivre sur mon compte linkedin qui est beaucoup plus actif.