Cette entrée de blog est le premier d’une série qui détaillera des réflexions autour du rôle de TL que j’occupe depuis peu ; l’objectif étant de faire part des interrogations, craintes et actions liées à cette prise de poste.

A la base, c’était juste … non

Devenir Tech Lead n’était absolument pas dans mes projets initiaux. De ma courte expérience, les différents TL étaient proches du chef de projet technique avec la casquette « Normes et pratiques de développement ».

J’avais du mal à me dire « ok il est expérimenté mais vu le peu de temps où il développe avec nous, difficile de nous orienter correctement ». En effet, les pratiques et normes conseillées pouvaient être obsolètes ou rigides ou les deux ! Au Daily Scrum Meeting, n’ayant pas d’impact concret sur la valeur du produit, son activité se résumait à … on ne sait pas trop. L’image que je m’en faisais était donc très floue. À travers les missions, les personnes qui m’ont vraiment permis de progresser étaient les référents techniques ; je me suis alors dit que TL, ce n’était pas pour moi.

Le rôle de Tech Lead, une grosse incompatibilité avec les pratiques agiles

Si on se penche sur la pure théorie des rôles Agile, on s’aperçoit qu’il n’existe pas de Tech Lead !  En effet, la clé de voûte de l’équipe de développement est l’auto-organisation. Via ce biais, on s’assure que l’essence technique et métier du produit est acquise dans la collégialité et le consensus. La seule variation acceptée est d’admettre la présence de référents, techniques ou fonctionnels, qui sont des éléments moteurs pour le groupe.

La casquette TL n’a donc pas de sens et peut même être un frein ou un mur dans une équipe agile de par l’ajout d’une hiérarchie.

L’Advocacy, une solution pour « Agilifier » le rôle traditionnel du Tech Lead

Ma réflexion s’est donc tournée sur le rôle de référent technique. Qu’est ce qu’un référent technique ? Une personne qui s’y connait sur un framework ou une brique fonctionnelle ? Auquel cas ce rôle semble s’acquérir uniquement avec le temps. Mais est ce réellement si simple? Rapporter ses rôles moteurs à un degré de séniorité est finalement, de mon point de vue, assez réducteur. Emmener ce rôle sur une autre dimension pourrait apporter un plus dans une équipe.

M’intéressant au travail d’une personnalité bien connue du monde Google (et plus spécifiquement Angular), Todd Motto, un élément de sa tuile de présentation m’a interloqué sur un des articles de la société telerik.com :

« Todd Motto (@toddmotto) is a Developer Advocate ». Dans la littérature actuelle, l’advocacy est un style de diffusion de la connaissance et des pratiques à travers documentation, conférence, contribution, etc. Anciennement un peu comme un Developer Evangelist sans le côté… évangéliste technologique. Je trouvais donc intéressant d’essayer de traduire cet état d’esprit à une échelle équipe.

Au quotidien, cela se matérialise par :

• Veille et formation constantes sur les technologies du projet.
• Réflexion sur les problématiques de l’environnement de développement.
• Présentation (in)formelle d’outils et/ou de pratiques visant l’optimisation de l’environnement de développement.

Le deuxième point reste le plus important à mes yeux car l’essence du DA réside en cette empathie et bienveillance exacerbée envers les autres développeurs.

Advocacy + M.O.I = Une vision du rôle de Tech Lead enthousiasmante

Vous avez senti la transition vers le poste hein ? Ma chance sur le projet où je suis était double : un binôme avec un TL de presque 20 ans d’XP (contre 5 années pour moi) et une possibilité de changer le schéma traditionnel en place dans l’équipe.

Une différence d’âge, et alors ?

Chose compliquée au départ, j’ai  rapidement eu un complexe d’infériorité face à cette différence de séniorité. Même si on se complétait de par mon appétence front et son appétence back, le plus expérimenté prend naturellement plus de place (et encore maintenant). Le déclic a été de comprendre qu’il était inutile de vouloir gagner une légitimé similaire à la sienne : c’est tout de suite moins de pression !

Globalement, nous avons essayé de nous répartir les sujets et applications en fonction de l’historique des projets. Pour les ateliers de cadrage et conception technique, nous y participons ensemble pour avoir une vision complète pour l’équipe. En ce qui concerne le coaching de l’équipe, chacun partage ses réflexions, propose et organise des sessions de travail nécessaires avec l’aval de l’autre.

Motivation, Organisation, Innovation

L’advocacy reprend en partie ce coté expertise technique du TL et, également, la diffusion de pratique sans avoir un objectif fort de norme et de qualité. L’ouverture d’esprit de mon binôme et son expérience étaient également importants pour insuffler une nouvelle dynamique dans l’équipe. Le DA a pour but d’améliorer l’environnement technique des développeurs au quotidien alors que le TL assure l’homogénéité et la qualité du code produit : Tout l’enjeu est d’essayer de combiner les 2. Notre binôme s’est rapidement mis d’accord sur le fait de ne pas reproduire la traditionnelle hiérarchie TL/développeur pour permettre une réelle auto-organisation.

Partant de zéro (je parle bien sûr de moi, jeune padawan TL), il me fallait une base de travail pour me lancer. Pour avoir une idée claire du cadre de ses responsabilités, je me suis appuyé et inspiré d’un excellent livre blanc de la société octo.com : « Culture Code » qui traite de la façon de produire du code de qualité. Il y est détaillé une manière d’aborder le rôle TL et l’importance du « M.O.I. » :

• soutenir la Motivation de l’équipe
• mettre en place une Organisation favorisant la collaboration
• Innover et être ouvert aux idées

Cette démarche est vraiment intéressante pour nous dans notre volonté d’inscrire l’équipe dans une philosophie autour du software craftsmanship avec de solides valeurs agiles.

Mot de la fin

J’ai finalement sauté le pas car je trouve cette vision technique et « motivationnelle » ambitieuse et intéressante pour la suite de ma carrière. Renforcer ce lien, un peu perdu, entre le Tech Lead et les développeurs est fondamental pour donner  plus de profondeur et de couleurs aux tâches du quotidien. L’aspect coaching donne une réelle dimension humaine qui finalement fait sens dans les organisations agiles actuelles.

Mahamoud Saïd Omar