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.
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!
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 :
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é.
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.
Il y a des choses qui ne s’apprennent pas, mais qui vous aideront à mieux accompagner les équipes en coaching 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!
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.
Voici quelques recommandations à consulter afin de poursuivre la réflexion :