Philippe Bourgau nous invite dans son quotidien de Coach Agile Technique

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

Bonjour Cédric! Je suis coach agile technique. Je travaille actuellement à Murex. J’aide les équipes à atteindre un rythme plus productif et plus durable. J’ai fait une école d’aéronautique, mais j’ai tout de suite commencé à travailler dans le développement par passion. J’ai été développeur pendant 16 ans, intégrant toujours plus de coaching dans mon travail. Nous sommes début 2022 et cela fait maintenant 4 ans que je suis officiellement coach.

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

Je reprendrais le “pourquoi” de Kent Beck: “Permettre aux développeurs de se sentir en sécurité dans ce monde”, en y ajoutant mon grain de sel: “Montrer une autre manière, plus soutenable”. Pour résumer, je suis coach technique pour “Faire découvrir aux développeurs une manière plus efficace, calme, et durable de travailler dans ce monde”.

En pratique, j’interviens auprès d’équipes de développements pour les guider sur les techniques de développements agile, comme bien sûr le TDD (Test-Driven Development), mais aussi le pair et mob programming, la collaboration, le design par incrément, les conventions d’équipes…

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

Un coach a souvent deux clients. Le premier est le client qui finance la mission, ou l’entreprise qui embauche directement le coach. Les seconds sont les membres des équipes qui seront concrètement coachées.

Les premiers attendent souvent plus de productivité, moins de bugs, ou encore l’amélioration d’autres mesures visibles à court terme de la performance de l’équipe.

Les seconds ont des objectifs beaucoup plus variés, personnels, et parfois cachés. Le coach les découvre lorsqu’il commence sa mission. La plupart du temps, il est impératif d’avancer sur les objectifs des seconds pour atteindre durablement les objectifs des premiers.

Une organisation (une équipe ou une entreprise) étant un système, il est très difficile de poser des objectifs de résultats précis. Je préfère utiliser des objectifs d’experimentation, basés sur une hypothèse, en voici un exemple:

Hypothèse : Nous pensons qu’accompagner l’équipe sur les techniques de développement par incrément sur leur propre code 

L’objectif suivant: livrer plus tôt tout en réduisant le nombre de bugs en production

Nous pourrons valider notre hypothèse lorsque le taux de bugs diminuera

Nous évaluerons notre progrès sur cette experimentation par le nombre de sessions effectuées avec l’équipe et leurs évaluations des sessions

J’ai écrit plus en détail sur ce sujet sur mon blog.

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

Le métier de coach agile technique est à la croisée de nombreuses disciplines: développement, architecture, agilité, conduite du changement, coaching… C’est un des aspects que j’aime le plus dans ce métier. Voici par exemple les principales compétences que j’ai eu l’occasion d’utiliser:

• Développement agile: TDD, pairing, mobbing, refactoring, design incrémental, legacy code…
• Architecture: principes d’architecture et de design, DDD (Domain-Driven Design), testing…
• Agilité: facilitation, amélioration continue, servant leadership…
• Conduite du changement: intraprenariat, construction de workshops, gamification…
• Coaching: écoute, identification des bonnes questions, résolution de conflits…

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

Dans mon passé de coach intégré à l’équipe, j’étais 100% du temps avec l’équipe. C’est une position intéressante puisqu’on reste au centre de l’action, et qu’on peut avoir un impact certes local, mais fort et sur le long terme. Dans ce cas, la journée type est celle d’un développeur, en passant la plupart de son temps à pair-programmer.

Maintenant que je suis officiellement coach, je ne suis plus 100% de mon temps avec les équipes. J’anime des code katas avec certaines d’entre elles, des sessions de mobs avec d’autres, ou encore des workshops spécialisés. Dans mon poste actuel, à Murex, nous avons créé une équipe de coaches techniques à temps partiels, qui sont des développeurs qui nous assistent pour coacher les autres équipes. Nous passons une journée par semaine avec eux pour les former à accompagner. En plus de ces activités, je consacre également du temps à imaginer comment étendre nos pratiques à d’autres équipes de l’organisation, ou à créer des nouveaux ateliers pour répondre aux derniers problèmes remontés par les équipes. Donc non, je n’ai pas vraiment de journée type, si ce n’est un mélange de toutes ces activités.

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

Le changement est un problème complexe, et par définition, il n’y a pas de recette garantie de succès! Il faut experimenter et s’adapter. J’ai cependant repéré quelques paramètres qui facilitent ou bloquent grandement mon style de coaching:

• Il faut que les membres de l’équipe aient envie et soient volontaires. Infliger de l’aide est contre-productif, braque les personnes, et rend le changement encore plus difficile.
• Il faut que les leaders techniques qui ont de l’influence soient de notre côté. Il y en a dans toutes les organisations. Ce ne sont pas forcement celles qui ont un grade élevé. Si ils soutiennent le coaching, alors la moitié du travail est fait!
• Il faut aider les gens à régler leurs problèmes plutôt que de chercher à appliquer un framework ou une méthode.

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

Je pioche mon inspiration de diverses sources. Comme je l’ai dit plus haut, je m’appuie beaucoup sur l’experimentation et l’adaptation.

• Dans ce sens, j’essaye de propager des pratiques comme on le fait pour une innovation. A la manière d’une startup.
• Cela nous amène a faire du marketing et de la vente 😲! Mes collègues et moi conduisons des interviews des membres des équipes pour comprendre leur problèmes et ensuite identifier ce que nous pourrions leur apporter. Cela nous permet de faire un ‘pitch’ pour gagner leur adhésion. Ceci nous permet de commencer le coaching avec un thème précis, un objectif sur mesure et de l’envie.
• Enfin, nous avons de nombreuses sources d’inspiration pour la pédagogie: sport et pratique délibérée, “Training from the back of the Room”, pédagogie Montessori, gamification…

Avez-vous un exemple de mise en pratique de gamification dans ce contexte de coaching agile technique ?

Voici plusieurs exemples concrets:

• animer le workshop eXtreme Carpaccio (https://github.com/dlresende/extreme-carpaccio) ;
• animer une compétition de correction d’erreurs Sonar sur plusieurs jours ou semaines, avec un petit lot à la clef (https://youtu.be/L9YV7sb0aGE) ;
• Certains développeurs C++ de Murex on également organisé une compétition similaire pour corriger les warnings qui empêchaient de migrer à la dernière version de C++ ;
• Le “built-in quality game” est un jeu de plateau qui permet de jouer avec les pratiques de développement agiles et de voir comment investir dans la qualité augmente la productivité. J’aimerais faire une version en ligne!
• J’ai eu par le passé réussi a introduire l’exploratory testing en transformant l’activité en compétition. C’était très efficace pour transformer les programmeurs en testeurs extrêmes.

Mes collègues coaches à Murex et moi avons également quelques prototypes en cours d’experimentation:

• le TCR (test && commit || revert) a par nature un aspect ‘poker’ ou on parie sur son code. Nous pensons qu’on peut pousser cela plus loin en comptant des points en fonction du nombre de petits pas, du nombre de fois ou un test échoue… (https://github.com/daviddenton/refactoring-golf) ;
• Nous avons pour projet d’experimenter un dashboard Sonar (ou autre) pour afficher le niveau de qualité du code des différents binômes de programmeur lors d’une session de kata ;
• Alex Bunardzic, un autre coach technique m’a parlé d’une pratique de “Mutant-killing mob session”. L’idée est de lancer le mutation testing sur une partie du code, et de faire une session de mob ou le jeu est de tuer tous les mutants!

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

Tout a fait. Voici ce que mon équipe et moi faisons actuellement à Murex:

• Nous commençons par des Katas de Code. Nous varions les formats (en pair, en mob)
• Nous faisons ensuite des mobs d’application. Par exemple, si nous avons pratiqué le Strangler Pattern dans un kata, nous allons pratiquer le strangler avec toute l’équipe, en mob, sur une de leur partie du code ;
• Nous utilisons également des workshops que nous construisons spécifiquement pour régler des problèmes liés à toute l’équipe. L’idée est d’intégrer tous les profils, de s’appuyer sur l’intelligence collective pour trouver des solutions. Par exemple, nous faisons souvent un workshop “Stratégie de tests” qui a pour but d’aligner toute l’équipe sur la gestion et l’évolution de leur manière de tester ;
• Depuis quelques temps, nous expérimentons de plus en plus du coaching self-service. L’idée est de permettre aux équipes qui n’ont pas forcement envie de voir un coach de commencer à changer en toute autonomie. Cela nous permettrait également de nous dégager du temps pour intervenir là où nous avons le plus de valeur ajoutée. Voici quelques exemples de nos expérimentations:
  • Nous utilisons TCR (test && commit || revert) comme un outil pour rendre les katas plus amusants et pour encourager les participants à découper la programmation en étape encore plus petites ;
  • Nous essayons la gamification autant que possible (ex Extreme Carpaccio kata, TCR encore, mais nous avons également en tête d’ajouter des scoreboards dans les katas…) ;
  • Enfin, nous essayons de rendre nos workshops réutilisables via Miro, de manière à ce que tout le monde puisse les effectuer, sans forcement que nous soyons présents.

Vous avez notamment écrit un article sur la méthode Samman, issue du livre d’Emily Bache. Pouvez-vous nous résumer l’idée globale de cette méthode ?

Ce livre est une très bonne présentation du métier de coach agile technique. Le livre contient un guide à l’usage du développeur ou du coach qui voudrait devenir coach indépendant. Mais la grande majorité du livre présente la méthode Samman. Celle-ci consiste en quelques éléments clefs:

• Des sessions de mob programming avec toute l’équipe, de manière assez concentrée sur 3 semaines. Cela permet au coach de faire passer beaucoup de messages, feedbacks, et pratiques à l’équipe ;
• Ces 3 semaines sont suivies de 3 semaines de ‘pause’. Cela permet au coach de respirer et à l’équipe d’avoir le temps d’appliquer ce qu’elle a appris. A la suite des ces 3 semaines, le coach peut rejoindre l’équipe à nouveau ;
• Dans le cadre de la méthode Samman, le coach anime également des sessions quotidiennes d’une heure, ouvertes à tous : les “Learning hours”. Ce sont des minis cours qui utilisent le format “Training from the back of the room” et ciblent un sujet technique bien précis.

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à ?

J’ai déjà évoqué ce point dans les conditions pour qu’une mission de coaching réussisse.

• Nous ne travaillons qu’avec des équipes volontaires! Sinon, c’est peine perdue ;
• Nous effectuons des entretiens avec les membres de l’équipe afin de bien comprendre leurs problèmes et leurs craintes éventuelles ;
• Nous préparons et présentons une proposition pour répondre à leurs problèmes et pour obtenir l’adhésion de toute l’équipe. Démarche typique du consultant… qui fonctionne!

Il arrive cependant que nous nous rendions compte après le début du coaching que certaines personnes sont particulièrement réticentes. Si c’est une seule personne et qu’elle n’a pas trop d’influence, le problème se règle souvent de lui même lorsqu’elle voit les améliorations que le coaching apporte. C’est plus compliqué si elles sont plusieurs ou si elle a de l’influence. Dans ce cas là, j’ai appris qu’il fallait rapidement discuter avec la ou les personnes en tête à tête pour essayer de comprendre leurs besoins et voir comment collaborer de manière constructive. Il peut arriver qu’on en arrive à arrêter un coaching sans espoir plutôt que de s’épuiser et générer de la frustration des deux côtés.

Il faut admettre, puisque le changement est un problème complexe, que nous ne maitrisons pas tous les paramètres, et que parfois, cela ne fonctionne pas!

J’ai d’ailleurs écrit à ce sujet sur mon blog.

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

Trois difficultés majeurs me viennent tout de suite à l’esprit:

1. Les développeurs sont tous trop occupés! Dans le monde moderne, l’heure.homme d’un développeur vaut son pesant d’or, et il est donc très difficile d’obtenir du temps pour que les développeurs puissent apprendre à travailler autrement.
2. En 25 ans, agile est passé de eXtreme Programming à SAFe. C’est à dire d’une pratique subversive qui a émergée de la communauté des développeurs, à une discipline poussée par les entreprises et les product managers. En cours de route, on a perdu les développeurs. Nous rencontrons souvent de la résistance de la part des développeurs qui ne voient pas tous l’agilité d’un bon oeil.
3. Enfin, il reste très difficile de mesurer notre impact en tant que coach. Tellement d’autres paramètres entrent en compte (ex: nouvelle deadline, turnover, legacy code, bugs legacy…) qu’il est impossible de différencier ce qui résulte de notre travail de ce qui vient d’autre facteurs.

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

Très bonne transition! Malgré la difficulté, nous utilisons plusieurs techniques:

• Nous définissons des objectifs de coaching avec les équipes et nous leur demandons leur feedback au long du coaching pour vérifier que cela répond à leurs attentes.
• Je m’applique à moi même le format d’objectif que j’ai présenté plus haut. Il permet de séparer mon hypothèse sur le système de mon action. Cela permet de clarifier les choses auprès de tous dès le début et d’ajuster si je vois que je fais fausse route.
• Comme je l’ai dit plus tot, nous ne travaillons qu’avec des équipes volontaires. Elles nous payent avec leur temps! Si elle ne perçoivent pas la valeur de notre coaching, elles peuvent arrêter à tout moment. Le fait qu’elles continuent, en redemande, ou nous recommande à d’autres équipes est un indicateur fort de la valeur de notre intervention.

Enfin, il faut admettre que mesurer notre impact est quasi impossible. Henrik Kniberg le décrit dans Confession of a Change Agent. Il mesure son impact en fonction des sourires qu’il reçoit quand il entre dans l’open space de l’équipe.

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 ?

Nous n’avons pas de durée type. En général, il faut compter un minimum de trois mois pour commencer à voir les effets.

Les interventions coachings n’ont d’ailleurs pas toutes la même intensité. Nous essayons de nous adapter au rythme des équipes. Certaines préfèrent ne nous voir que quelques heures par sprints. D’autres voudraient nous voir tous les jours!

Il est également bon d’avoir des pauses, de laisser les équipes assimiler seules, pour laisser le changement se faire.

Après un certain temps, les équipes deviennent des ‘alliées’ de transformation plutôt que des clients, et la relation s’inverse! Ce sont alors elles qui nous aident à construire des nouveaux outils et à nous promouvoir auprès des autres équipes.

Comme nous n’intervenons pas à 100% dans une équipe, il y a peu de risque de dépendance.

En revanche, il faut savoir sortir d’un coaching qui devient improductif. Malgré nos précautions, il arrive qu’on se retrouve dans une situation où notre action est devenue inutile. Il faut savoir dire stop à ce moment là. Cela sous-entend, que si on est un coach indépendant, il faut nourrir son réseau pour pouvoir s’extraire d’une mission, en trouver une autres, et pourquoi pas peut être trouver un autre coach qui sera peut-être plus compatible avec l’équipe.

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

C’est très variable. Ça dépend beaucoup d’où part l’équipe: état du code, technologie, pratiques en place, état d’esprit. Voici quelques éléments de réponse:

• L’impact est exponentiel. Il est lent au début, mais accélère par la suite ;
• Les effets les plus rapides sont sur la collaboration et le moral de l’équipe. 3 semaines peuvent suffire ;
• Dans un contexte difficile, avec beaucoup de legacy code et peu de couverture de test, il faut parfois 6 mois pour commencer à pouvoir observer des gains sur la performance de l’équipe ;
• En revanche, sur le long terme, en 3 ans, j’ai vu des équipes passer de situations très compliquées, à des exemples de performance et de bien-être!

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

Pour résumer, je dirais que l’écueil principal est de ne pas accepter la nature complexe de la conduite du changement. En pratique, cela ce traduit par les 3 erreurs suivantes, dans lesquelles je retombe malheureusement plus souvent que je ne le souhaiterais :

1. Se donner des objectifs hors de notre contrôle. Ex:
   • Vouloir transformer l’organisation ou l’équipe ;
   • Vouloir de rendre les collaborateurs heureux
2. S’entêter dans notre plan initial et ne pas en changer alors que cela ne fonctionne pas ;
3. Ne pas arrêter suffisamment tôt lorsque le coaching est improductif.

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

Je crois réellement en ce que je fais. Je suis tombé dans eXtreme Programming au tout début de ma carrière, et ça changé ma vie de dev:

• J’ai fait très peu d’heures supplémentaires en 16 ans en tant que développeur à temps plein, alors même que j’ai travaillé en salle de marché. J’ai donc très tôt expérimenté les avantages de gain de temps et de qualité de vie générés par cette pratique ;
• Je me souviens avoir mis en prod des nouveaux connecteurs à des interfaces de marché (finance) sans bugs!
• J’ai pu aller au cinéma sans stress les soirs de mises en prod, à une époque où les mises en prods se faisaient le week end et étaient suivi d’une phase prévue de “post-release” (e.g. fire-fighting) ;
• J’ai pu accueillir les changements de specs de dernière minutes sans blamer les responsables produits!
• J’ai vu des juniors apprendre plus en 3 ans dans une équipe XP que d’autres en 10 ailleurs.

D’autres développeurs qui sont passés par XP m’ont fait le même témoignage. Une fois qu’on y a gouté, c’est très difficile de revenir en arrière. Ça ne veut pas dire que ce soit facile, XP met du temps à maitriser, et il faut dépasser beaucoup de blocages mentaux. Mais cela enlève 80% du stress du métier de développeur.

C’est un métier qui me permet de “Montrer une autre manière de travailler au développeurs, plus soutenable et plus sure”. Comme je l’ai dit plus haut, c’est un métier qui associe beaucoup de sujet intéressants. Enfin, lorsque l’on est développeur, les utilisateurs sont souvent éloignés, tandis que le coaching technique me permet d’être à leur contact tous les jours!

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 ?

La plus grande différence que j’ai pu observer vient des contraintes de sécurités. Les exigences des clients poussent les entreprises à agir en amont sur la qualité.

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?

Malheureusement, je n’ai pas observé de différence flagrante. On enseigne toujours la technique de ‘Faire parfaitement du premier coup’ pendant les études. Les entreprises recrutent maintenant sur un tableau blanc, sans test, sans possibilité de faire du développement par incrément, et sans droit à l’erreur. Enfin, le nombre de développeurs juniors augmentant exponentiellement, les bonnes pratiques ne sont malheureusement que rarement enseignées aux nouveaux entrants.

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 pense que ce sont des synonymes pour beaucoup de personnes.

Personnellement, je n’aime pas trop le terme de Coach Craft. Le terme “Crafter” est galvaudé, il semble qu’il soit devenu un synonyme de développeur.

Je comprends l’intention derrière le Software Craftsmanship, mais je trouve que cela sépare le développement des autres aspects de l’équipe. XP intègre toute cette diversité dans un tout cohérent.

Selon moi le coaching agile technique, c’est coacher les équipes à devenir plus agiles en intégrant les prérequis techniques (au découpage en stories par exemple), alors que coach craft ne m’évoque que du coaching de pratiques de dev, sans contexte. D’autre part, il est possible de coacher les développeurs aux principes agile par l’intermédiaire des katas! Le coaching agile technique, c’est du coaching agile via les techniques de dev, et pas du coaching aux techniques de dev agiles!

Qu’est-ce que vous recommanderiez en terme de ressources sur le sujet ?

Si je ne devais en recommander qu’un seul, ça serait The Art of Agile Development de James Shore. C’est une référence complète qui fait un tour d’horizon du sujet et dans lequel je me replonge régulièrement.

Sinon, voici une courte sélection:

• La première édition de XP Embrace Change de Kent Beck. Elle est sans filtre, pas toujours politiquement correcte, et c’est pour moi la plus pure expression de ce qu’est l’agilité ;
• Refactoring de Martin Fowler, contient tout ce qu’il faut savoir pour pouvoir faire du design incrémental. Je vois souvent ce livre dans les listes des livres à lire, mais finalement, peu de gens l’ont lu ;
• Mob Programming de Woody Zuill. Une lecture indispensable pour ce qui est pour moi la plus importante mise a jour de XP depuis 20 ans ;
• Les livres d’Emily Bache Coding Dojo Handbook et Samman Technical Coaching sont des bonnes des très bon livres pour quelqu’un qui voudrait se mettre au coding dojos ou au coaching technique.

Après, la liste est trop longue! Le coaching agile technique est suffisamment divers pour qu’on puisse s’inspirer de presque tous les domaines.

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

Oui, je blog régulièrement à propos du coaching agile technique sur https://philippe.bourgau.net . Que vous soyez coach technique ou développeur souhaitant amener du changement, ça devrait vous intéresser.