Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec JP Lambert, JP bonjour.
Bonjour.
J'aimerais qu'on réagir sur un article que tu as posté où tu dis
est-ce que le Tech Lead est vraiment un rôle à avoir dans l'équipe ?
Et c'est même un vrai provocateur en disant
mais c'est peut-être un antipaterne en fait.
C'est pas peut-être d'ailleurs tu dis
avoir un Tech Lead d'abord c'est un antipaterne.
Moi je me suis persuadé.
Ah ouais tu rentres dedans, c'est quand même pas classique
en point de vue dans toutes les équipes,
c'est rassurant d'avoir ce Tech Lead qui te dépâteouille,
qui te sort de la mouise,
toi tu dis non mais c'est un antipaterne.
Expliquez-vous, Monsieur Lambert.
Alors déjà tu dis que c'est courant,
je reformulerai en disant
c'est très courant dans toutes ces entreprises françaises qu'on croise.
Mais c'est pas une généralité d'absolu.
Déjà voilà, histoire de faire le pédant,
on prend le Scrum Guide,
l'équipe de développement,
il n'y a qu'un seul rôle,
il n'y a qu'un seul titre qui est reconnu,
on appelle ça développeur,
derrière c'était un testeur,
un designer ou effectivement un développeur.
Mais voilà on efface complètement les rôles de chacun.
Ce qui ne veut pas dire que dans l'équipe
il y a évidemment des experts,
on réunit différents experts qui sont doués
plutôt pour certaines choses plus que pour d'autres,
mais on ne veut pas le savoir de l'extérieur.
Si ça part en sucette,
c'est le problème de toute l'équipe.
Et donc ça c'est...
Du coup c'est la, c'est censé être la règle,
donc ça veut dire que vu de l'extérieur,
l'entreprise, le management,
ne devrait pas poser un rôle différent dedans.
Parce qu'en gros voilà,
c'est ce que j'explique dans l'article,
c'est que finalement mettre un télétrique dans l'équipe,
c'est faire un pari qui est risqué,
et qui nous rapporte potentiellement peu.
C'est un pari qui est risqué parce que,
si on a un mauvais teclid,
l'équipe c'est sûr elle est morte.
Voilà, Eva, Eva rame,
elle arrivera pas à progresser, les gens...
Voilà, ça va casser tous les élanques pour avoir l'équipe, etc.
Ouais, un mauvais teclid c'est quoi un mauvais teclid?
Parce qu'en général, tu arrives au rang de teclid
quand tu as prouvé ta valeur dans la technique,
c'est que tu as...
Moi je vois le rôle de teclid
comme une espèce de reconnaissance
plus par l'équipe elle-même que par le management.
Donc déjà, ça a l'air sans ce que tu dis,
c'est que finalement c'est l'équipe qui donne cette reconnaissance-là.
Et encore une fois, l'équipe peut s'organiser,
l'équipe a le droit, il faut qu'on ait des lides dans l'équipe,
dans le sens des personnes qui sont des meneurs qui emmènent tout le monde.
Par contre, est-ce qu'il doit avoir ce rôle officiel?
Donc là on parle pas de la reconnaissance de l'équipe,
on parle bien de la légitimité donnée par l'organisation.
Tu vois, ça me choque pas qu'il y ait une personne
qui ait une posture de teclid.
Ça c'est très bien, c'est ce que t'as dit.
Il y a un nouveau, ben oui je l'accueille, je l'aide,
je connais le produit,
j'ai plus d'expérience, je l'accompagne,
bien sûr qu'on veut voir ça dans l'équipe.
Et c'est ça mon point en fait,
c'est que si tu n'ohmes pas de teclid,
cette notion de lide peut émerger quand même.
Et ça va très bien se passer.
Par contre si tu n'ohmes une personne,
déjà le pari risque,
parce que si c'est une personne qui finalement n'est pas faite pour ça,
et pour moi c'est une casquette qui n'est pas technique,
on s'attend à ce qu'un teclid soit bon techniquement,
mais aussi une dimension managériale,
c'est à dire que j'ai des collègues et je les fais grandir,
je leur donne des conseils,
je les embarque vers d'autres choses, vers d'autres cieux.
Et alors que finalement tu auras exactement,
alors à l'inverse si tu prends un bon teclid,
mais que tu ne n'ohmes pas de teclid,
tu le mets juste dans l'équipe,
en fait il va faire du bon taf aussi,
et on va quand même avoir une bonne dynamique d'équipe qui va se former.
Parce que pour ça je dis pour moi,
je comprends pas l'intérêt de prendre ce pari-là
qui est inutilement risqué,
et à l'inverse effectivement,
on risque de casser les lents fondamentaux
d'auto-organisation de l'équipe,
parce que voilà, fondament c'est ça,
la règle c'est,
vous êtes tous avec le même titre,
et vous débrouillez comme vous voulez,
vous auto-organisez,
et à côté de ça on leur dit,
bon par contre lui il est teclide,
ça va l'opposer même de cette règle de base
de l'équipe de développement s'auto-organise.
Alors sous cette angle de vue,
je suis à juste à 120% d'accord avec toi,
puisque moi je considère que dès que tu donnes une responsabilité à quelqu'un,
de facto tu l'enlèves aux autres.

Donc à partir du moment où tu vois pas mal de bottes qui me disent,
je comprends pas,
mes développeurs sont pas impliqués,
mes développeurs sont sans pas responsables,
puis là tu craises un peu et tu te rendes compte qu'ils ont un chef,
un sous-chef et un sous-sous-chef,
et là tu dis bah oui,
mais enfin,
vous avez déjà enlevé toute la responsabilité,
c'est commencer par enlever des chefs,
vous verrez que vous laisserez la place
à l'équipe de prendre cette responsabilité.
Et le deuxième point sur lequel je te rejoins,
c'est la notion de dépendance à une personne.
Je trouve ça super risqué dans un projet,
d'avoir des personnes qui ont des territoires.
C'est dangereux parce que la personne,
il faut qu'elle puisse partir en vacances.
Et c'est dangereux parce que c'est juste une question
de savoir complètement à l'encontre du collectif ownership,
de l'appropriation collective du code.
Si tu commences à avoir des territoires
qui sont plus ou moins marqués,
bah moi je considère que là tu es mal en mancher,
quand même, parce qu'il va y avoir des zones
qui ne seront pas maîtrisées
ou qui ne seront maîtrisées que par certaines personnes,
ce qui augmente ta dépendance à ces personnes.
Et ça je trouve ça dangereux,
parce que c'est aussi quelque chose qui vient nuire
à la notion de rythme durable.
C'est-à-dire que si tu peux pas prendre de vacances,
bah tu n'es pas sur un rythme durable pour moi, tu vois.
Donc il y a tous ces enjeux qui se mélangent.
Et si tu fais cette nuance entre le titre officiel
et le rôle qui peut émerger,
moi ça me va bien.
Je ne sais pas comment ça règle,
ce que je viens d'amener et comment ça te fait règle.
Je suis d'accord.
Alors toi même tu parles de collective ownership
et je pense que tu le dis de manière teintée
au sens que ça a dans le monde du développement.
Moi je l'élargis, tu vois.
Là tu donnes l'exemple de comment les gens
maîtrisent une partie du code.
Tu peux faire la même chose avec.
Après la colonne développement sur le bord,
il y a une colonne à valider et c'est le royaume du testeur.
Et c'est pareil.
On fait comment le jour où le testeur, il est en vacances.
On produit plus rien,
on met juste tout qui s'entasse dans la colonne à valider.
Tu vois et c'est la même chose, c'est...
L'équipe s'organise quand même longtemps.
Elle peut dire,
bon bah Bob c'est quand même notre expert du test,
il a fait 20 ans de tests avant,
donc c'est naturellement lui qui va porter l'étage de test.
Mais c'est la responsabilité collective de toute l'équipe.
Le jour où il n'est pas là, on n'est pas bloqué.
Et le jour où il est sous l'eau,
parce que d'un sujet à l'autre,
on n'a pas non plus la même répartition de travail.
On est là, on l'épaule, on l'aide etc.
Et oui donc cette notion de collective ownership est très bien.
Mais voilà, moi j'ai envie de dire,
au sens global de toutes les tâches,
de tout ce que fait l'équipe,
en le décoréant du sens que ça spécifiquement sur le code.
Moi je t'en joins après,
je...
Mon sujet de bataille c'est quand même l'étève,
donc forcément...
Je vais là où je puise dans ce qui est mon quotidien
et dans ce qui est mon cheval de bataille.
J'épuise mes cas concrets,
après je suis complètement d'accord avec toi
et je vais même aller plus loin.
C'est-à-dire que...
je vois trop d'heves qui se limitent.
Ah c'est bon j'ai fini le dev'
et puis je m'en occupe plus.
La responsabilité collective,
elle s'arrête pas, ça marche en local quoi.
La responsabilité collective,
elle est d'aller vérifier de bout en bout,
sur la prod,
est-ce que je livre la valeur qu'on m'a demandé ?
Est-ce que je livre la valeur que j'ai même co-construite ?
Et là tu parles de valeur,
c'est-à-dire qu'en fait c'est même pas le fait
que je m'assure que le code que j'ai fait
passe toutes les couches jusqu'à la prod.
Et il y a une dimension produit derrière,
parce que oui le produit,
c'est pas le productoneur,
le produit c'est toute l'équipe.
Et donc oui, on parle bien de valeur,
on parle bien de démarche,
d'expérimentation, de X etc.
Tout ça clairement,
oui ça doit être global,
et oui dès qu'on commence à enfreindre
ces trèques de base,
on a une équipe qui,
où on enlève toutes les qui,
qui doit être,
ce qui doit s'auto-organiser,
et qu'on devrait enfreindre ça,
c'est souvent la fin des récords qui commencent quoi.
Eh ben écoute Jean-Pierre Merci,
je te propose que ce soit le mot de la fin.
Réal plaisir.
Quant à toi chère auditeur,
j'espère que tu as aimé cet épisode.
Si c'est le cas,
je t'invite à aller voir l'article,
enfin voir lire l'article de JP sur la question,
je te mettrai le lien dans la description.
Je t'invite également aussi à venir découvrir sa chaîne YouTube,
tu t'as Scrum Live dans YouTube,
tu vas forcément trouver un épisode.
Et je te dis à demain.