Coaching technique : pour aider les équipes de développement

En tant que programmeur, il est tout à fait normal de donner beaucoup d’importance à la technologie. Mais faire un bon produit logiciel, c’est d’abord et avant tout être en mesure de bien comprendre le besoin du client, puis bien communiquer ce besoin dans toutes les sphères du produit logiciel, le code compris. À travers mes diverses expériences en développement logiciel, j’ai observé que nous, les développeurs, avons tendance à prendre de trop grosses bouchées, à être cryptiques et à ne pas mettre en valeur le langage et les concepts du domaine.

Mais au-delà du code, le développement logiciel c’est aussi de la communication, du savoir-vivre, du savoir-faire et de l’échange avec les gens.

Et c’est là qu’intervient le coach technique! Dans cet article de blogue, je vous partage mon parcours, ainsi que les aptitudes, le quotidien et les responsabilités d’un coach technique.

Comment j’en suis arrivé à faire du coaching technique?

J’ai commencé ma carrière dans un centre de recherche en géomatique en tant que seul développeur dans l’équipe. Je travaillais surtout avec des étudiants pour qui le développement logiciel n’était pas la principale force. C’est ce contexte qui m’a permis d’apprendre à me débrouiller pour comprendre du code écrit par différentes personnes, de différents niveaux de qualité, pour tenter d’intégrer et d’uniformiser le tout, en plus de le faire perdurer dans le temps. J’ai découvert que le plus important dans tout ce processus, c’est la communication. J’ai essayé de trouver des stratégies pour résumer et vulgariser le travail des autres, de raffiner le code pour en faire ressortir les concepts importants afin que les nouveaux diplômés puissent continuer à travailler sur les concepts des autres. C’est tout un défi de travailler seul dans un contexte où tout est en exploration et en maintenance à la fois!

Construire un produit, c’est une page blanche. C’est plus facile et ça va vite! Mais ce n’est qu’une infime partie du développement logiciel. Après avoir construit, il faut le maintenir.

Tant qu’un développeur n’a pas vécu cet «après», c’est difficile de voir la valeur ajoutée des bonnes pratiques qui semblent ralentir le travail. Ce qu’il faut comprendre, c’est que ce n’est qu’un ralentissement temporaire dans le but d’aller plus vite par la suite et de faire perdurer le produit dans le temps. C’est principalement ce constat qui m’a amené vers le coaching technique : un besoin de redonner à la communauté par mon expérience pour continuer d’élever le développement logiciel à une qualité supérieure.

Dans les dernières années, je me suis rendu compte qu’en étant maintenant un peu plus vieux, j’étais capable d’observer chez les autres des comportements que j’avais eus au début de ma carrière. Des comportements qui se répètent ad vitam aeternam quand les développeurs n’ont pas quelqu’un pour les guider et les amener à prendre un pas de recul. Même si je suis loin de tout savoir, il y a des bases fondamentales qui se répètent partout!

C’est quoi un coach technique?

Un coach technique porte plusieurs chapeaux et son scope of work peut varier grandement selon le contexte. Dans tous les cas, son but ultime est de mettre en place les bonnes pratiques par l’enseignement et le développement des talents. Le coach technique supporte les humains et leur donne les outils pour mieux faire le travail.

Dans la plupart des cas, le coach technique est un consultant externe. Il s’immerge complètement dans l’équipe pour travailler en étroite collaboration dans le quotidien des équipes et pas seulement en périphérie.

De plus en plus, on voit des talents à l’interne prendre le rôle de coach technique, qu’il s’agisse de développeurs séniors, Tech Lead, Team Lead ou Engineering Managers. Dans mon cas, je suis Engineering Manager Senior chez Nexapp, en plus d’assumer le coaching technique dans mon travail au quotidien. Le coaching technique est assez nouveau pour moi puisque c’est un métier en émergence, mais c’est très complémentaire à mon rôle d’Engineering Manager Senior.

À l’inverse d’un coach Agile qui se concentre plutôt sur les processus, l’organisation du travail et la facilitation, le coach technique s’attarde de façon plus micro au code et à la qualité.

Par exemple :

• Comment découper de meilleures story?
• Comment coder de façon incrémentale, par petites étapes?
• Comment déterminer le résultat désiré avant de coder pour vérifier qu’on code la bonne chose?
• Comment reconnaître ce qui cloche dans le code (ex. : code smells)?
• Comment refactorer sécuritairement sans avoir de régression?
• Comment éliminer les silos et les temps d’attentes en favorisant le travail d’équipe (ex. : mob programming)?
• Comment avoir un cycle de développement plus court (ex. : test-driven development, behaviour-driven development)?
• Comment mettre en valeur et faire ressortir les concepts du domaine (ex. : domain-driven development)?

On arrive à faciliter la réponse à toutes ces questions en partageant un coffre à outils rempli de microtechniques, exercices, répétitions, méthodologies et techniques de travail qui développent de bons réflexes. Comme le coach n’est pas un mentor, il ne donne pas toutes les réponses. Le but est de donner beaucoup d’outils aux développeurs pour qu’ils trouvent en équipe ce qui leur convient et ce qui leur permettra d’atteindre leurs objectifs de qualité.

Qu’est-ce que ça prend pour être un coach technique?

L’expérience vécue

Un coach technique doit lui-même avoir vécu le pire pour être en mesure d’expliquer à un autre développeur les problèmes qui pourraient survenir s’il continue à coder comme il le fait.

Les softs skills

Il y a des choses qui ne s’apprennent pas, mais qui vous aideront à mieux accompagner les équipes en coaching technique :

• Leadership | Amener les gens à avoir confiance qu’on va se rendre là où on doit aller.
• Capacité à convaincre | Trouver les bons arguments pour amener les développeurs à essayer de nouvelles façons de faire (qui peuvent parfois sembler contre-productives de prime abord).
• Humilité | Au bout du compte, le changement est entre les mains des développeurs.
• Passion | S’intéresser non seulement aux nouveautés, tendances et meilleures pratiques, mais aussi à l’historique de l’industrie pour apprendre des erreurs de ceux qui sont passés avant nous.
• Pédagogie | Être capable de reconnaître quand c’est le moment de donner un conseil et quand c’est le temps de les laisser apprendre par l’erreur.
• Empathie | Se plonger dans la réalité de l’équipe pour les outiller selon leur stade de maturité et leur contexte.

À quoi ça ressemble le quotidien d’un coach technique?

Pour un coach technique externe, la journée commence généralement par une formation ou un Learning Hour, soit une heure de présentation plus théorique suivie d’un petit exercice. Le coach travaillera ensuite avec une équipe différente le matin et l’après-midi pour renchérir sur l’enseignement et le mettre en pratique dans le quotidien des développeurs.

De mon côté, le coaching technique est intégré dans mes tâches quotidiennes. J’aime beaucoup travailler en groupe (mob) pour, d’une part, briser les silos, et, d’autre part, renchérir sur les apprentissages des Learning Hours et identifier de nouvelles pistes d’amélioration dans la dynamique d’équipe.

Par exemple, on pourrait se pratiquer à identifier la plus petite tranche de valeur ajoutée, à implémenter la solution la plus simple possible afin de  travailler en de très courts cycles itératifs et déceler les problèmes plus rapidement, ou encore partir d’un bout de code existant et discuter en équipe de ce qu’on aime ou pas dans le code dans le but de définir nos seuils de qualité.

En dehors des exercices pratiques, j’encourage fortement les équipes à travailler en mob-programming ou en ensemble-programming pour trouver des solutions ensemble et mettre en pratique les apprentissages de la semaine. Mon rôle est de les laisser expérimenter et faire des erreurs! Mais je ne suis jamais très loin s’ils vivent des problématiques pour les guider ou les recadrer avec un exemple concret qu’on vient juste de vivre. Et curieusement, c’est très efficace!

Quand le travail d’un coach technique est-il terminé?

Lorsqu’une équipe a compris ce que j’appelle les fondamentaux, comme repérer les code smells ou les bonnes techniques de refactoring, qu’ils ont atteint une belle maturité, et qu’un membre de l’équipe est prêt à reprendre le lead, je peux les laisser aller. Mon objectif est de former d’autres coachs techniques! Quand je sens que quelqu’un est prêt à prendre le relai et à devenir lui-même le leader technique au quotidien dans l’équipe pour continuer à véhiculer les bonnes pratiques, je peux simplement entretenir le travail amorcé à intervalles réguliers pour souffler sur les braises de l’amélioration continue.

Pour aller plus loin

Voici quelques recommandations à consulter afin de poursuivre la réflexion :

• Le livre Technical Agile Coaching with the Samman Method par Emily Bache et le site web de l’autrice qui décortique entre autres le principe du Learning Hour.
• L’entrevue que j’ai accordée au podcast le Sprinkler Techno sur le sujet.
• L’article Coaching Technical Practices par Perdo Santo sur InfoQ.
• Le blogue d’un autre coach technique reconnu, Llewellyn Falco, ainsi que son GitHub.
• Différents sites d’exercices de katas: Kata-Log, Kata-Catalog sur GitHub, Emily Bache sur GitHub, TDD Buddy, Code Cop, Programming with Wolfgang.
• La chaîne YouTube Mob mentality show qui m’a beaucoup inspiré pour le mob programming et dont j’essaie d’amener les concepts dans mes équipes.
• Le site Refactoring Guru pour apprendre la nomenclature des code smells, des refactorings et des design patterns.
• Le blogue de Nicolas Carlo, Understand Legacy Code, pour développer des techniques permettant de mieux aborder le code legacy.