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

Je m’appelle Yoan Thirion, j’ai 34 ans et suis coach agile technique indépendant sur Luxembourg. J’ai une quinzaine d’années d’expérience dans le développement logiciel.
Mes différentes expériences en startup, chez un petit éditeur ou dans le service m’ont amené à développer sur un éventail assez large de plate-formes / technologies et langages : développement d’app mobiles sur les ancêtres de nos “smartphones”(J2ME, RIM, Windows Mobile, …), Stack .NET (C#, F#, C++), PHP, Stack Java (Java, Kotlin, Scala), SPA (Angular principalement).
Je me suis tourné vers le coaching il y a environ 5 ans lorsque j’ai compris que ce que j’aimais le plus au quotidien c’était aider les autres développeurs et apprendre au quotidien.
Je suis un passionné qui a toujours envie d’apprendre et partager avec les autres (#sharingiscaring).

Rentrons dans le sujet. Pour vous nous dire avec vos mots, en quoi consiste le Technical Agile Coaching ?

En quelques mots je le résumerais par l’accompagnement d’équipes “agiles” qui n’ont pas forcément tous les éléments afin d’être en mesure de délivrer de manière itérative et incrémentale. En gros :

• Avec le coaching Agile : on met en place un cadre permettant de “construire le bon produit” dans les meilleures conditions possibles (”Build the right thing”) ;

• Avec le coaching Agile Technique : on se focalise sur la mise en place des pratiques d’ingénierie et l’acquisition de connaissances qui permettent de délivrer des produits de qualité en continu (”Build the thing right”).

Voici quelques exemples d’outils que je “pousse” au sein des équipes que j’accompagne : Clean Code, Test Driven Development, Pair/Mob Programming, Méthodes de refactoring de code legacy (Mikad, Approval, …), Code Reviews, Domain Driven Design, Rétrospectives techniques…
Mon objectif au quotidien :

• Aider les individus à grandir / acquérir de nouvelles compétences techniques, agiles et humaines permettant de délivrer du logiciel de haute qualité et de la façon la plus efficiente possible ;

• Cela passe par les rendre autonomes sur leurs pratiques et leur apprentissage (développer la capacité d’adaptation).

Quelles sont les problématiques initiales des clients ?

Ce sont souvent les mêmes problématiques ou axes d’amélioration qui ressortent :

• Des initiatives agiles ou DevOps qui peinent à prendre ou échouent ;

• Des équipes qui doivent fournir des produits et du code de haute qualité mais qui sont tout le temps sous pression et n’ont pas la moindre seconde pour investir dans cette qualité, d’où l’augmentation incontrôlable de leur dette technique ;

• Des développeurs qui doivent mettre en œuvre et utiliser des bonnes pratiques qui ne sont pas définies ou partagées ;

• Des équipes autonomes mais non alignées techniquement ;

• Pas d’espace pour l’apprentissage continu et donc potentiellement pour l’amélioration continue.

Quels sont les objectifs qui vous sont fixés ?

Les objectifs à moyen terme (quelques mois) du point de vue des sponsors sont de réussir à aider les équipes accompagnées à aller vers du “mieux”.
Ce mieux se traduit souvent par une augmentation de la qualité produite par l’équipe qu’on peut facilement mesurer via la baisse du nombre de defects en production (ou sur les environnements inférieurs).
Pour amener les équipes vers du mieux je commence toujours par créer un alignement sur leur situation actuelle. Pour ce faire j’utilise un modèle d’auto-évaluation contenant une douzaine de catégories / cartes. Je fais en sorte que chaque membre de l’équipe puisse s’exprimer sur chaque carte :

• Décrire la situation actuelle

• Identifier les axes d’amélioration

• Présenter leurs idées d’action / expérimentation

Une fois cet exercice réalisé et une première analyse (mini exploration de leur code source et de leur architecture) :

• J’ai une première idée des actions pouvant amener du mieux

• Je les propose à l’équipe

• On se crée un backlog d’actions à réaliser dans les prochaines semaine. Ex : matérialiser nos guidelines, faire 1 atelier Clean Testing afin de comprendre comment écrire de meilleurs tests, effectuer 1 code review en mob programming afin d’augmenter notre alignement sur le code et éviter les code reviews en mode ping pong, …

Nous rejouons les auto-évaluations tous les 3 mois afin de valider ou non le progrès.
Point d’attention : lorsque vous utilisez ce genre d’outils d’auto-évaluation je vous conseille de faire en sorte de les garder au sein de l’équipe sinon ils risquent d’être dévoyés (voir loi de Goodhart).

Est-ce que tu es à l’origine de ce modèle d’auto-évaluation et de ces cartes ? Comment et quand t’es venu l’idée ?

Oui ce modèle d’auto-évaluation est de moi.
Il est librement inspiré du Squad Health Check créé par Henrik Kniberg il y a quelques années chez Spotify afin de mesurer l’impact du processus d’amélioration continue sur les équipes et l’organisation.
Vous pouvez réutiliser librement les cartes disponibles ici.

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

Dans son livre “Coaching Agile Teams”, Lyssa Adkins représente le métier du coach agile avec un modèle permettant d’appréhender les différentes facettes du rôle.
Je m’en suis inspiré afin de créer ce modèle qui représente (à l’heure actuelle tout du moins, début 2022) mon point de vue sur ce métier.

A partir de cette représentation on pourrait aisément coller certaines compétences et connaissances.
Pour être en mesure d’accompagner des équipes de développement, il faut avoir un background solide du métier de développeur :

• Maîtriser plusieurs langages de programmation (avec des paradigmes différents : procédural, objet, fonctionnel) ;

• Une très bonne connaissance des pratiques d’ingénierie logicielle (CI/CD, testing, architecture).

En plus de ces hard skills, il faut être aussi en capacité de :

• Faciliter des ateliers ;

• Communiquer avec n’importe qui au sein des organisations et donc adapter sa communication à son audience ;

• Comprendre les autres et faire preuve d’empathie ;

• Faire grandir les autres en leur transmettant du savoir et en les coachant (utilisation de questions ouvertes).

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

Non je travaille avec plusieurs équipes chaque jour dans des contextes différents (j’ai 5 clients en parallèle en ce moment).
Il n’y a pas vraiment de journées types mais plutôt des types d’activité récurrente :

• Préparer des ateliers (techniques ou non) ou des code katas ;

• Faciliter des ateliers ;

• Animer des communautés ;

• Effectuer des Code Reviews avec une équipe ;

• Animer des sessions de veille technologique (cf Xtrem Watch)

Chez Promyze nous avons imaginé un format collaboratif pour l’échange de connaissances et l’alignement des bonnes pratiques, les Ateliers Craft. Pensez-vous que cela peut vous aider dans vos missions ?

Oui totalement, je vois Promyze comme une plate-forme permettant d’accélérer le changement culturel. Elle permet de systématiser / sanctuariser les échanges collaboratifs sur le code via les ateliers Craft.
La plate-forme va permettre d’ancrer ces ateliers dans la routine des équipes leur permettant de :

• S’aligner sur leurs coding guidelines

• Prendre du recul sur leur code

• Dédier du temps à l’amélioration / apprentissage continu sur leur code, architecture, …

C’est clairement un outil à mettre dans toutes les mains des coachs agiles techniques.

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

Pour que le coaching soit un succès il y a 2 facteurs primordiaux :

• Le support du management afin de pouvoir libérer du temps aux équipes ;

• Etablir un “contrat” de coaching avec les équipes accompagnées.

Lorsque je parle de contrat ce n’est pas quelque chose de forcément très formel cela peut être par exemple : où on en est aujourd’hui et on veut être dans N jours.
Cela permet de fixer un cap et de se donner des objectifs.

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

Tout à fait, j’utilise de nombreux outils venus du coaching.
J’utilise par exemple :

• Un dérivé du Lean Change Canvas de Jason Little pour matérialiser la vision des communautés que j’accompagne (plus d’infos ici) ;

• GROW pour accompagner les équipes (Goal / Reality / Options / Will plus d’infos ici) et structurer son approche de coaching ;

• Le Solution Focus en rétrospective ou en coaching d’équipe permettant de déplacer le regard sur les solutions plutôt que sur les causes / problèmes ;

• De nombreux outils du Management 3.0 tels que le Delegation Poker ;

• Training from the Back of the Room pour la conception de mes ateliers en mode 4C permettant de créer des formations / ateliers participatifs et engageants.

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

Afin de démontrer la pertinence de certaines pratiques ou techniques je déroule des katas de Code avec les équipes.
Les katas permettent d’appréhender de nouveaux concepts (Approval Testing) en dehors du code de l’équipe et de passer des messages de manière bienveillante.
Il y a de nombreux repositories de katas tels que coding-dojo, katalyst ou encore kata-log.

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

C’est pourquoi il est primordial d’avoir un contrat de coaching avec l’équipe. Ce “contrat” engage chaque membre de l’équipe à à respecter le choix du plus grand nombre.
Évidemment nous ne sommes pas dans le monde des bisounours et certains individus sont plus réceptifs à ce genre d’initiative que d’autres. Je compte aussi sur les plus motivés (Early Adopters) pour convaincre les plus réticents.

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

Il y a souvent la réalité des projets ou des produits qui nous rattrapent.
Le temps que l’équipe est en capacité de s’octroyer pour son amélioration continue et son apprentissage peut s’avérer plus faible ou plus important fonction des périodes et de la réalité de l’organisation (les rushs et les imprévus existeront toujours).
Cela fait partie du quotidien du coach que de gérer ces périodes de creux avec les équipes accompagnées. C’est souvent l’opportunité de creuser de nouveaux sujets et de préparer de nouveaux ateliers à destination des équipes.

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

On peut mesurer l’impact de l’intervention d’un coach agile technique de plusieurs manières :

• Le ressenti de l’équipe (avec le Health Check mentionné ci-dessus ou des sondages permettant de récupérer le feedback des personnes accompagnées) ;

• Via les sondes de qualité : taux de couverture de code, nombre de tests unitaires, évolution de la complexité cyclomatique, réduction de la dette technique, … ;

• La diminution du nombre de defects ou a minima le nombre d’aller-retours des features entre le développement et le recettage ;

• La hausse à terme de la vélocité de l’équipe ;

• La mise en place de métriques globales permettant de mesurer l’optimisation globale : utilisation des 4 métriques Accelerate (4-key metrics, certaines peuvent être difficiles à mettre en place).

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 ?

Je dirais, a minima 3 mois afin de voir les premiers impacts et les changements de pratiques et potentiellement de mentalité s’ancrer parmi les personnes accompagnées.
En général, le coaching prend fin lorsque l’équipe ou moi-même sentons qu’elle est autonome sur son apprentissage et son amélioration continue.
Cela n’empêche pas l’équipe de faire appel à moi de manière ponctuelle lorsqu’elle s’interroge.

Quelles sont les erreurs fréquentes ou les écueils à éviter lorsqu’on exerce du coaching agile technique ?

Ce métier requiert énormément d’empathie et de pédagogie. Je dirais qu’il faut absolument éviter de se placer en tant que sachant égocentrique.
Lors de chaque accompagnement, j’aime décrire mes règles d’engagement :

Je suis un développeur comme vous, je ne prétends pas détenir LA vérité. Ce que l’on voit ensemble est mon point de vue que je vous demande de toujours challenger.

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 ?

Oui, en tout cas sur mon marché c’est certain qu’il y a une prise de conscience.
Je l’explique par un contexte technologique en constante ébullition et une concurrence accrue qui poussent les entreprises à aller vite en prenant de nombreux raccourcis (ne pas investir sur les tests, ne pas former ses équipes, prendre des raccourcis en terme d’architecture) qui coûtent cher à court terme : baisse de vélocité, augmentation du coût d’implémentation de nouvelles fonctionnalités, perte de clients…

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

De mon point de vue c’est la même chose. J’irais même plus loin en disant que dans le contexte d’équipes de développement, les coach dits agiles, devraient en réalité faire du coaching Agile Technique. Je ne ferais appel qu’à des coachs en capacité d’accompagner les équipes à la fois sur leur cadre mais aussi sur la qualité de ce qu’elles produisent afin de leur délivrer un maximum de valeur.

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

Il y a quelques Best sellers que je recommande volontiers:

• “Technical Agile Coaching with the Samman method” d’Emily Bache

• “Training from the Back Of The Room” de Sharon Bowman

• “Code that fits in Your Head” de Mark Seemann

• “The Pragmatic Programmer: From Journeyman to Master” de Andrew Hunt et David Thomas

• “The Software Craftsman” de Sandro Mancuso

• “Clean Code” d’Uncle Bob

• “Implementing Domain Driven Design” de Vaughn Vernon

• “Fundamentals of Software Architecture” de Mark Richards et Neal Ford

• “Domain Modeling Made Functional” de Scott Wlaschin

Je m’arrête là sinon je vais en taper des dizaines supplémentaires 😉

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

J’alimente une Knowledge base avec mes derniers ateliers. J’anime également le meetup Craft Luxembourg que je vous invite à visiter on essaie d’avoir a minima un événement par mois.
Merci ! 🙏