Le premier billet, le défi de l’agilité, décrit le cheminement qui m’a conduit à accepter le challenge du TL : un rôle riche sur les plans technique, méthodologique, organisationnel et psychologique. Ce changement induit des défis tels que la maîtrise du changement ou encore la gestion d’une nouvelle dynamique ;  problématiques qu’il faut solutionner pour élever le niveau technique de l’équipe et lui donner plus d’autonomie.

Maîtriser le contexte

Je suis devenu Tech Lead il y a six mois alors que j’intervenais sur la mission depuis un an. L’équipe de développement compte douze développeurs pour deux TL sur un plateau d’une vingtaine de personnes.

De manière générale, le TL consacre le début de sa mission à une analyse des pratiques techniques pour y apporter un regard critique. Dans une équipe agile, les objectifs M.O.I. cités dans le précédent article m’ont conduit à explorer d’autres aspects :

• La mission ; évaluer l’intégration de l’agilité dans les processus du client, étudier les différentes applications et s’informer au possible sur les roadmap court/moyen/long terme
• L’équipe agile ; analyser l’existant, mesurer le degré d’agilité pratiquée, identifier les interlocuteurs techniques externes
• Les développeurs ; évaluer le niveau technique global et individuel, comprendre les trajectoires techniques de chacun

Cela fait beaucoup de challenges ! Mais j’ai eu l’occasion dans la mission d’étudier ces aspects pendant ma phase développeur sur le projet. Ces éléments m’ont permis de m’abstraire, psychologiquement, de l’équipe pour garder un prisme objectif sur les problématiques rencontrées. Ils m’ont également permis de garder une continuité dans le fonctionnement de l’équipe.

Identifier les vecteurs de confiance

Un cadre familier est toujours plus propice pour accueillir le changement : réorganisation, recrutement, départ… Il est essentiel de montrer une volonté d’amélioration sans pour autant déclarer vouloir tout jeter pour recommencer. On évite ainsi de s’inscrire dans une relation de défiance avec l’équipe.

Pour gagner la  confiance dans cette nouvelle relation, il faut avant tout se concentrer sur les liens inter-développeur à travers :

• la collaboration : pair-programming, atelier de conception applicative, revue de code de développeur, coding dojo collectif, etc.
• la communication : accompagnement sur des présentations techniques, revue de code collégiale, etc.

De plus, nous y avons ajouté un lien intra-développeur ; une introspection autour des aspects suivants :

• l’agilité et ses valeurs
• la cohérence technique projet/mission au regard des objectifs de carrière
• le plan de carrière et ses évolutions possibles

Très clairement, cette volonté de mise en perspective du métier se heurtera à l’audience. Chaque développeur est différent, et surtout aspire à des choses différentes. Charge au TL d’adapter son approche en fonction des profils.

Définir des indicateurs de progression

Ces entrants permettent au TL de dessiner une cartographie technique et relationnelle de l’équipe coachée. À partir de là, on peut établir un plan organisationnel autour des différentes applications afin d’optimiser la progression de chacun.

Dans cette optique, nous avons mis en place des rendez-vous mensuels, sur la base du volontariat, pour pouvoir récolter ces informations. Ces moments d’échanges permettent une prise de recul sur la condition du développeur pressé par la machine SCRUM. Ainsi, on essaie de donner du sens à la mission dans sa carrière pour savoir si la trajectoire prise correspond à ses envies.

A la sortie de cet échange, nous fixons des objectifs pour mesurer la progression au fil des rendez-vous : le TL et le développeur construisent ensemble le coaching.

Humeur et impressions

Très enthousiaste et épuisé par ces différentes réflexions, l’étape suivante est la vulgarisation et la diffusion de ces concepts.

Là, c’est plus compliqué et ça m’a fait douté de mon choix. En effet, la réalité du terrain est que chaque développeur a accueilli cette philosophie de manière différente. Mon incompréhension était totale quand je réalisais que les impliquer pro-activement dans la construction de la culture technique de l’équipe et de leur carrière, leur était soit pénible soit inutile. Mon erreur est d’avoir inconsciemment fait une projection de mes frustrations de développeur sur les membres de l’équipe : j’étais alors convaincu d’apporter quelque chose de neuf, d’innovant et de meilleur pour leur quotidien.

Le changement reste un facteur de stress et de doute malgré les efforts de forme que nous y avons mis. Véritablement, avoir une scrum team autonome et auto-organisée n’est pas évident à obtenir et il faut des membres conscients des responsabilités qu’imposent ces libertés. Suivant les carrières, ces questions arrivent peut-être trop tôt, trop tard ou ne sont pas du tout pertinentes. Pour y faire face, nous avons proposé une participation non-obligatoire aux ateliers techniques ainsi que des entretiens optionnels de mission : mettre un effort sur les personnes intéressées sans pénaliser les autres.

En complément, les rituels d’équipe tels que les coding dojos sont des moments de team building autour de thématiques variées comme le refactoring, le TDD ou encore le gherkin. A travers la dynamique de groupe et le pair-programming, nous espérons ainsi garder la motivation de l’équipe au plus haut et une bonne cohésion.

Mahamoud Saïd Omar