Ce mois-ci, nous allons partir à la découverte du travail de Coach Technique dans le milieu du développement logiciel. Nous avons rencontré Jean-Louis Rigau, Technical Agile Coach, qui nous en dit davantage sur les missions lors d’un Coaching Technique, qui lui sont confiées ainsi que son quotidien en immersion au sein des équipes. Agilité, Software Craftsmanship, DevOps, nous abordons tous ces sujets ensemble.

Bonjour Jean-Louis ! Tout d’abord, peux-tu te présenter en quelques mots et nous en dire davantage sur ton parcours ?

Je m’appelle Jean-Louis Rigau, j’ai 37 ans et je suis Technical Agile Coach. J’ai 15 ans d’expérience dans le conseil en développement logiciel que ce soit en tant que développeur ou coach.
J’ai une solide expertise dans le développement backend au sein de l’écosystème Java avec une forte appétence pour la qualité et tout ce qui touche au Craft, puis je me suis intéressé au Continuous Delivery, et à tout ce qui gravite autour des conteneurs et de l’environnement Cloud Native, à la fois du côté plateforme et applicatif.
Dans ma carrière, j’ai eu la chance de côtoyer des mentors techniques qui m’ont fait grandir et aujourd’hui avec ma démarche de coaching, je souhaite à mon tour transmettre le savoir que j’ai acquis à travers mon expérience. 
Que ce soit en tant que développeur ou en tant que coach aujourd’hui, j’ai toujours eu à cœur de grandir et de faire grandir les autres à la fois humainement et techniquement.

En quoi consiste ton métier de Technical Agile Coach ?

Au-delà d’un métier, il s’agit davantage d’une mission dans laquelle je m’attache à accompagner des équipes agiles et orientées produit dans leur maîtrise de leur code et de leur pipeline afin de fiabiliser leur delivery.
Au quotidien, mon rôle de Technical Agile Coach consiste à être en immersion dans les équipes et de développer avec elles les fonctionnalités du backlog directement sur leur base de code. Mon objectif est de faire monter en compétences l’équipe sur ses pratiques afin de la faire gagner en autonomie, mais également d’accompagner le changement, ce qui nécessite parfois de commencer par désapprendre avant de réapprendre.
Ma démarche consiste à transmettre les bonnes pratiques ainsi que le bon usage des outils et la bonne culture afin de redonner de la maîtrise aux équipes avec pour but d’améliorer sa capacité à délivrer et donc in fine sa performance.

Quels sont les besoins formulés par le client et les objectifs qui te sont fixés ?

Avant de pouvoir formuler leurs besoins, les clients que nous rencontrons font tout d’abord face à des problèmes auxquels ils ne savent pas répondre.
Les premières difficultés exprimées sont la perte de contrôle sur leur delivery (de plus en plus de bugs et de support qui complexifient les livraisons en Production). Ces clients sont soit en pleine transformation Agile ou l’ont déjà terminé, et pourtant ils n’arrivent pas à livrer plus souvent et avec une meilleure qualité. Ils prennent conscience de la nécessité de remettre le focus sur les pratiques de travail plutôt que sur l’organisation du travail.
Les secondes difficultés sont liées aux équipes elles-mêmes à qui l’on demande d’être responsables sur l’ensemble de la chaîne de delivery (Dev to Prod) et qui par un manque de compétence et parfois d’appétence rencontrent des difficultés pour y parvenir. Le besoin exprimé par les clients est alors de recréer de l’engagement dans les équipes, de redonner de la passion et de retenir les talents.
Les objectifs qui me sont fixés sont en général d’accompagner une première équipe afin de lui redonner à la fois de la maîtrise sur son code et son delivery et de l’intérêt pour ce qu’elle fait, puis dans un second temps, de déployer le dispositif à plus grande échelle.

En termes de mise en œuvre, comment se déroulent tes missions ?

Il y a 2 grandes phases dans les missions que je mène :

1. Une première phase d’observation va me permettre de rencontrer un maximum de personnes au sein des équipes et donc de m’imprégner de leur quotidien et de comprendre les problèmes qu’ils rencontrent. L’enjeu est de construire une relation de confiance avec les équipes et d’établir un état des lieux en termes de pratique, culture et outillage. C’est également l’occasion d’identifier comment la performance des équipes est mesurée. A l’issue de cette phase, je réalise un kick off où je fais mon rapport d’étonnement et je présente la démarche de coaching. 
2. La seconde phase est consacrée au coaching en immersion au sein des équipes. Je peux être amené à accompagner jusqu’à 4 équipes en parallèle sur des périodes de 3 à 4 semaines (en fonction du rythme des sprints des équipes) qui vont se ponctuer par des périodes “off” afin de laisser l’équipe expérimenter par elle-même.

Comment se passe une journée-type au sein des équipes ?

Une fois la phase d’observation terminée, une journée type consiste donc à être en immersion dans une équipe et de faire avec elle.
Elle s’articule généralement autour de sessions de Mob Programming avec toute ou partie de l’équipe au cours desquelles nous réalisons une fonctionnalité du backlog en mettant le focus sur les bonnes pratiques de développement.
Entre les sessions de Mob Programming, je suis amené à faire du Pair Programming avec les différents membres de l’équipe pour résoudre les problèmes rencontrés lors des sessions de Mob ou pour approfondir certaines pratiques en coaching individuel.
Je ne réalise jamais de tache de delivery seul.

Si l’on prend les principes du Test-Driven Development par exemple, comment amènes-tu une équipe à se les approprier et à les intégrer dans ses méthodes de développement ?

Concrètement, je vais introduire les pratiques de développement progressivement et sans forcément les nommer au début. Je veux avant tout montrer les choses de façon différente (en live coding), avec l’objectif d’aller aiguiser la curiosité et susciter l’intérêt des membres de l’équipe en leur montrant la valeur apportée par les pratiques mises en œuvre.
Une fois l’intérêt suscité, ensemble nous allons approfondir la pratique (en la nommant cette fois) puis chercher à la maîtriser. Pendant cette étape, je vais favoriser l’expérimentation par les membres de l’équipe et je vais me positionner davantage en support (méthode Shu-Ha-Ri).
L’enjeu est de réussir à intégrer durablement ces pratiques dans le quotidien de l’équipe. Pour cela il est nécessaire de mettre en œuvre les pratiques et de mesurer factuellement leur impact sur les capacités de delivery afin d’en percevoir la valeur.

Dans ton parcours de développeur, à quel moment tu t’es orienté vers cette activité de coaching ? Et pourquoi ?

Au début de ma carrière, j’ai eu la chance de travailler avec des développeurs plus seniors qui ont été de véritables mentors techniques pour moi et m’ont initié aux bonnes pratiques de développement. Ils m’ont fait découvrir les bon livres : Clean Code de Robert C. Martin (Uncle Bob), Working Effectively with Legacy Code de Michael C. Feathers, etc. Ils ont également pris le temps de faire avec moi en Pair Programming dans une démarche Extreme Programming (XP).
Depuis, j’ai toujours été dans une recherche de qualité et d’excellence à travers mes pratiques de développement. Cette recherche d’excellence m’a poussé à sans cesse m’améliorer pour gagner en maîtrise et être plus performant.
À un tournant de ma carrière, j’ai eu l’envie à mon tour de transmettre cette passion pour faire grandir les autres et c’est la raison pour laquelle je me suis orienté vers le coaching.

Quelles sont les qualités techniques et humaines nécessaires pour les missions que tu exerces ?

Avant tout, ce qui est essentiel, c’est d’avoir la passion pour la technique et l’envie de transmettre.
Nécessairement, il faut avoir une forte expertise technique autour du Craft et du Continuous Delivery quelque soit les langages ou domaines techniques (Dev, Infra, Data, etc.). L’expérience doit être significative et davantage orientée sur les pratiques que sur les outils. 

Que conseillerais-tu à une personne qui souhaite devenir Technical Agile Coach ?

De croire en elle et surtout de ne pas délaisser la technique même si celle-ci est encore peu appréciée à sa juste valeur : aujourd’hui il est possible de faire carrière dans la technique.
Bien entendu, il est important de ne pas transiger sur les pratiques de développement et la qualité sur ses projets. Pourtant, il est souvent difficile de mettre en place une nouvelle pratique au sein d’une équipe, car la valeur apportée n’est pas suffisamment visible, ce qui pousse malheureusement à l’abandonner avant d’en avoir les bénéfices.
Pour changer cela, je conseille de mesurer factuellement et systématiquement l’impact des pratiques de développement sur la capacité de delivery de l’équipe et de s’appuyer notamment pour cela sur les 4 key metrics (Cf. Livre Accelerate).

Est-il nécessaire de maîtriser certains langages/frameworks pour accompagner une équipe ? Par exemple, si je n’ai jamais fait de Python, suis-je pertinent pour coacher techniquement une équipe sur un projet codé en Python ?

De mon point de vue, c’est davantage une expérience solide sur les pratiques de développement qui est essentielle, car le coach pourra s’appuyer dessus pour s’adapter au contexte de chaque équipe.
La maîtrise d’un langage ou d’un framework n’est donc pas le plus important même si c’est un plus pour accompagner des équipes qui utilisent ce même langage ou framework.

Pratiquer des missions de Technical Agile Coach requiert-il selon toi un certain niveau d’expérience nécessaire ? Si oui, lequel ?

Oui elles requièrent nécessairement une expérience significative en tant que développeur mais pas obligatoirement en tant que coach bien qu’une forte appétence pour la transmission soit indispensable.
Pour être Technical Agile Coach, il faut bien entendu avoir une forte expertise sur les pratiques Craft et le Continuous Delivery, mais sans pour autant être un expert sur tous les outils, car comme dit précédemment, c’est avant tout l’expérience sur les pratiques qui compte.

Quelles sont les difficultés auxquelles tu es confronté lorsque tu rejoins une équipe ?

Pour moi, le plus grand challenge auquel je suis confronté est de nouer une relation de confiance avec l’équipe. Elle est essentielle pour être en capacité de me concentrer pleinement sur la montée en compétence de l’équipe lorsque je réalise le coaching en immersion.
Pour gagner cette confiance, il faut avant tout démontrer pour, à la fois, faire ses preuves et susciter de l’intérêt. Ensuite, la curiosité fait le reste. Dans une équipe, il y aura toujours une personne qui aura de l’appétence pour les pratiques introduites et sur laquelle je vais pouvoir m’appuyer pour acquérir l’adhésion du reste de l’équipe.

Quel accueil te réserve l’équipe que tu accompagnes ? Et comment évoluent vos relations avec le temps ?

C’est très variable car il peut y avoir quelques appréhensions de l’équipe sur mon rôle et sur ce que je peux apporter à l’équipe. D’où l’importance du travail réalisé en phase d’observation qui permet de poser les bases d’une relation de confiance avec les équipes.
Une fois la relation posée, la collaboration se fait naturellement et je fais partie intégrante de l’équipe. Cette dernière a compris que mon objectif est de l’accompagner et non pas de la surveiller.
Le plus souvent, le déclic se fait quand l’équipe prend conscience de la valeur directe qu’apportent les pratiques introduites dans son quotidien. Elle va alors gagner en maîtrise et progressivement s’installer dans un cercle vertueux d’amélioration continue.
L’équipe gagne en autonomie et va pouvoir rayonner au sein de l’organisation. C’est à ce moment que je deviens dispensable.

Faire du Mob Programming ou de la revue collective, lorsqu’une équipe n’a pas l’habitude d’échanger de manière ouverte sur son code, doit j’imagine générer de la crainte ou de l’inconfort au début.

Comment arrives-tu à mettre à l’aise tout le monde ? 

Lorsque j’introduis les sessions de Mob Programming, c’est surtout moi qui fais au début, ce qui peut s’apparenter à du live coding. Une fois l’intérêt suscité, certains membres de l’équipe vont peu à peu prendre la main et engager le reste de l’équipe.
Il ne faut pas hésiter à donner la parole à tout le monde y compris celles qui se mettent naturellement en retrait afin d’avoir l’avis de tous.

Avec ton expérience et ton recul, quelles sont les erreurs courantes à éviter lorsqu’on fait du Coaching Technique ?

Pour moi, la 1ère erreur est de se disperser soit en voulant coacher trop d’équipes à la fois, soit en voulant adresser en même temps les problèmes d’organisation et la montée en compétences de l’équipe. On peut vite se retrouver à papillonner d’une équipe à une autre, ce qui réduit le champ d’impact.
La 2ème erreur fréquente est de penser que faire de la sensibilisation et réaliser des Katas suffit pour que l’équipe s’approprie de nouvelles pratiques. Il est essentiel de s’immerger dans le quotidien de l’équipe en faisant avec elle afin de lui permettre d’implémenter les pratiques directement dans son quotidien.
Enfin, la dernière erreur la plus courante lorsque l’on est en immersion dans l’équipe est de se retrouver à faire des tâches de delivery seul et donc de perdre l’objectif initial de faire monter en compétences l’équipe. Il est donc indispensable que le Technical Agile Coach ne réalise jamais des tâches de delivery seul. L’enjeu est de faire avec l’équipe et non pas faire à sa place.

À l’inverse, quels sont les facteurs-clés de succès dans ce type de missions ?

Un facteur clé de succès est de pouvoir trouver les relais au sein de l’équipe. Sans relais, il sera quasiment impossible de gagner la confiance de l’équipe et de la faire progresser.
Un autre facteur clé de succès est de systématiquement partager ce qui aura été appris, à la fois au sein de l’équipe et de l’organisation, permettant ainsi de valoriser les techniques acquises, car il y a un vrai enjeu de pédagogie pour démontrer la valeur des pratiques mises en place.
Un dernier facteur clé est bien entendu de mesurer factuellement les gains apportés par la mise en place des nouvelles pratiques au sein de l’équipe sur sa capacité de delivery et in fine sur sa performance.

Certains de tes clients ont-ils par le passé éprouvé d’autres alternatives à du Coaching comme tu le mets en œuvre ? Si oui, peux-tu nous en dire davantage ?

Encore peu de clients ont déjà fait appel à du coaching technique car c’est quelque chose qui reste nouveau et le fait de le faire en immersion encore davantage.
J’ai des clients qui ont déjà fait appel à des coachs techniques et qui sont parfois déçus des résultats en raison des faibles retombées sur le quotidien des équipes ainsi que sur l’amélioration du delivery.
Dans ma démarche de coaching, je me concentre sur les équipes afin d’avoir une action visible et réelle sur leur maîtrise du code et leur capacité de delivery. Nous sommes dans une approche bottom up qui permet d’avoir des impacts systémiques sur l’organisation.
Aujourd’hui, les clients sont prêts à faire appel à du coaching technique mais avec de fortes attentes sur les résultats car ils souhaitent voir concrètement l’amélioration de la capacité de delivery de leurs équipes.

Si l’importance de maîtriser son code et de produire un code de qualité a toujours été un enjeu majeur, les investissements et les actions concrètes n’ont pas toujours été au rendez-vous.

Cela semble évoluer depuis quelques années, en tout cas c’est un constat que nous faisons chez Promyze.

Partages-tu cette analyse ?

Oui je partage complètement cette analyse. Il y a aujourd’hui une vraie prise de conscience des clients sur l’importance de maîtriser son code et de produire un code de qualité. En revanche, ils ont besoin d’être rassurés par des résultats concrets, ce qui explique qu’ils n’investissent pas encore pleinement sur le sujet.
Au-delà du manque de résultats, les clients rencontrent des difficultés pour trouver les moyens de faire monter en compétences leurs équipes sur leur maîtrise du code et la qualité du delivery, pour plusieurs raisons : parfois un manque de compétence, d’appétence ou de prise de recul.

J’imagine que tu es souvent challengé sur le ROI de ton intervention. Es-tu capable de fournir certains indicateurs d’amélioration ? Si oui, lesquels ?

Oui, je suis régulièrement challengé sur le ROI de mon intervention et indirectement sur les bénéfices des pratiques autour du Craft et du Continuous delivery. Cela s’explique par le fait que ces pratiques n’apportent pas de valeur immédiatement et que cette valeur est également difficile à mesurer.
Aujourd’hui, les indicateurs que nous mesurons portent essentiellement soit sur la qualité du code soit sur la maturité des équipes et ne reflètent pas vraiment la performance des équipes.
Dans ma démarche de coaching, je me recentre sur la mesure de la capacité des équipes à délivrer plutôt que sur la qualité du code ou la maturité de l’équipe. Je m’appuie notamment sur les 4 key metrics (The State of DevOps / Accelerate) qui sont des indicateurs plus pertinents pour mesurer la valeur apportée par la maîtrise du code et du delivery de l’équipe sur sa performance.

Comment vois-tu l’évolution de ton métier ces prochaines années ? Penses-tu qu’il va avoir tendance à se démocratiser ?

Je vois déjà de l’appétence pour le coaching technique chez de plus en plus de clients et ce qui est intéressant, c’est qu’il est perçu à sa juste valeur de par ses enjeux et les résultats attendus.
Pour moi, il est clair que le besoin des équipes à maîtriser leur code et leur delivery existe, et que la demande en coaching va se développer en conséquence. Il y a donc une vraie nécessité à démocratiser le coaching technique pour y répondre.

Tu as récemment découvert Promyze, notre outil d’aide à la définition et à la diffusion des bonnes pratiques. De notre point de vue, Promyze accompagne le travail des Coachs qui ont pour mission d’aligner les pratiques au sein d’une équipe et de capitaliser là-dessus entre différentes équipes. Quel est ton point de vue là-dessus ?

J’ai découvert l’outil par hasard en faisant une recherche sur le coaching technique et j’ai tout de suite voulu l’essayer.
En tant que Coach Technique, quand j’arrive dans une équipe, j’ai besoin de démontrer rapidement la mise en place de pratiques notamment autour du Clean Code et ce que j’ai trouvé génial avec Promyze, c’est qu’il me permet d’avoir à portée de main des bouts de code que je vais pouvoir montrer à l’équipe et qui vont également pouvoir me permettre de bootstrapper un environnement plus rapidement.
C’est à la fois un outil de capitalisation de la connaissance et surtout de partage avec les équipes et entre les coachs. Les intégrations récentes aux IDEs permettent d’en faire un véritable compagnon du coach en s’insérant dans son quotidien.

Quels sont tes projets à court terme ?

Dans une échelle de 3 à 6 mois, mon ambition est de :

• Communiquer à la fois autour de ce nouveau rôle de Technical Agile Coach et sur la démarche de coaching en immersion afin de les démocratiser.
• Accroître le nombre de clients qui nous font confiance et que nous accompagnons 
• Et bien sûr, recruter !

 

Retrouvez Jean-Louis Rigau sur :

• Twitter : https://twitter.com/jlrigau
• Linkedin : https://www.linkedin.com/in/jlrigau

 
Comme Jean-Louis, vous faites du Coaching Technique et vous souhaitez découvrir comment Promyze peut vous accompagner pendant vos missions ? 
Vous êtes séduit par l’idée d’améliorer en équipe vos pratiques de développement ? Vous souhaitez gagner en excellence et en maîtrise technique ? 
Parlez-nous de votre projet ! 😉