Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Jean-Pierre Lambert, JP, bonjour.
Bonjour.
Je te propose qu'on rebondisse sur un poste LinkedIn,
le dernier en l'occurrence qu'on a fait ensemble,
où on échangeait du fait d'avoir un Tech Lead,
est-ce que c'était un anti-pattern ou pas.
Et ce que j'ai trouvé assez dingue, c'est que sur LinkedIn,
ça a généré un échange que j'ai trouvé vachement intéressant,
où il y avait quelque part le camp du pour, le camp du contre,
ce qui disait non, non, il faut laisser les choses un peu se faire
et le leadership émerger, dans lequel on va dire qu'on était plutôt dedans,
et il y avait le camp de ceux qui disaient non, non, non, c'est inérési,
il faut dans un mode finalement commande un contrôle,
comme ça que je l'ai perçu, imposer les bonnes pratiques,
il faut imposer de faire bien, et dans un mode très directif,
où j'ai même entendu quelqu'un dire, moi je relis tout,
un peu en mode tour de contrôle, je relis toutes les poules request.
Ce qui m'a frappé au-delà du débat, pour ou contre,
qui fondamentalement, moi j'ai une préférence,
mais j'ai pas d'avis définitif, ce qui m'a frappé un moment donné,
c'était de me dire mais en fait ça dépend du contexte.
Est-ce qu'il y a une vérité absolue à avoir, est-ce qu'on est obligé de choisir un camp ?
Quand on est dans un navire et que c'est la tempête,
je me vois pas faire un stand-up pour dire, bon alors les gars,
qu'est-ce que vous en pensez, quelle voile il faut y c'est ou pas,
c'est le capitaine qui donne des ordres directs, simples,
et après quand il fait beau, là oui on peut parler,
discuter tous ensemble de comment on va arriver à la destination,
comment on gère les vivres, comment on gère la vie à bord,
et voilà, j'ai été curieux de ta réaction sur ça,
qu'est-ce que tu en penses ?
Ben moi tout de suite, en fait ça me fait le parallèle avec mon quotidien en fait,
c'est-à-dire que en tant que Scrum Master,
oui il y a clairement ça, il y a clairement, parfois on est dans des contextes,
c'est même en tant que consultant dans des missions, donc on en voit passer,
ou oui, le rôle du Scrum Master c'est de mener l'équipe à l'excellence,
et donc effectivement tout le focus est l'auto-organisation,
la vision produite, la meilleure ration continue, etc.
Mais il y a d'autres contextes, d'autres missions,
ou non là faut juste qu'on délivre,
et parfois c'est parce que le contexte n'est pas très sain,
mais souvent c'est comme tu viens de le dire,
le bateau est en train de couler, donc faut qu'on réagisse,
c'est pas juste pour presser les gens, c'est juste que c'est vraiment le contexte qu'on a.
Et là du coup, parfois ça retourne un peu le cerveau,
en tant que Scrum Master, est-ce que je suis là plutôt en coach agil,
à faire que les choses émergent avec sa meilleure,
ou d'autres moments où...
Non, non, les gars là Scrum, ça marche comme ça,
tac, tac, tac, tac, t'as story, c'est ça, et on y va,
et on retombe un peu avec ça, et il n'y a pas de bonnes,
ou de mauvaises postures, d'ailleurs ça me fait penser un article
que j'ai écrit exactement sur ce sujet-là,
on pourra mettre dans la description,
et les deux postures sont même un peu complémentaires,
parce qu'il y a plusieurs phases aussi de maturité d'une équipe,
ou de contexte projet, et oui le vrai bon,
c'est pas celui qui sera l'un ou l'autre, c'est celui qui sera
à utiliser des deux postures, et donc oui clairement,
le contexte, de toute façon, ça c'est une phrase
qui ressort tout le temps, notamment dans l'agilité,
ça dépend du contexte.
Quand tu dis il, c'est intéressant, c'est qui ce il ?
Est-ce que c'est le Tech Lead, est-ce que c'est le manager,
parce que pendant la discussion,
il y a eu ça aussi, j'ai l'impression parfois
que l'équipe est livrée à elle-même,
et non les gars, c'est pas parce que le manager
ne fait pas partie prenante de l'équipe,
c'est pas parce que c'est un cochon, c'est un poulet,
qu'il n'existe pas, le manager a une responsabilité
dans la régulation de l'équipe,
quelle que soit sa forme de...
Tu vois, j'ai l'impression parfois que le command & control
a effacé la notion de management,
bah non, toujours un manager, toujours un mec qui est responsable,
ne serait-ce qu'un responsable légal ?
Bah non, mais c'est vrai que,
je pense que si j'étais un peu dur,
je pense qu'en France, on est quand même très habitué
au manager incompétent,
c'est-à-dire qu'en fait, finalement, soit il est complètement absent,
soit c'est un petit chef,
et ce qui est aussi très cohérent avec le côté
où finalement, c'est des anciens techniques
qu'on fait monter dans des rôles
dont ils n'ont pas forcément envie,
donc c'est quelque part normal qu'ils soient incompétents,
vu que c'est pas son appétence, c'est pas ses talents,
et en plus, on ne l'informe pas.
Alors que normalement,
oui, un manager est là pour aider,
il est là pour faciliter, il est là pour donner
ce que l'équipe a besoin, et effectivement,
si l'équipe a un défaut de formation sur un sujet,
et qu'elle a besoin quand on l'aide
à monter en compétences, par exemple, sur le TDD,
c'est normal d'appeler quelqu'un à la rescousse d'extérieur
qui va coacher l'équipe sur ce sujet, par exemple.
Oui, normalement, le manager est là,
après c'est vrai qu'avec l'agilité,
on l'efface un petit peu,
c'est-à-dire qu'effectivement,
on a l'équipe qui a une hiérarchie un peu plate,
le Scrum Master dans l'équipe Scrum n'est pas chef,
il convainc les gens de faire ce qui est bien,
mais il ne peut pas leur donner d'ordre,
et puis globalement, on a tout le mouvement,
voilà, ManagerMap 3.0,
mais qui finalement,
change beaucoup dans les pratiques, mais pas sur le fond,
en fait, ça nous ressente sur
le vrai rôle du manager, c'est-à-dire qu'on est là
pour mettre en place, construire l'environnement
où l'équipe pourra s'épanouir,
et non plus dire aux gens quoi faire,
mais ça en fait, ça a toujours été vrai,
on voit passer 10 fois par jour sur LinkedIn,
les citations de Steve Jobs ou n'importe qui nous dit
« Ben non, moi je recrute des gens intelligents
pour qu'ils prennent des initiatives,
pas pour que j'en dise, comment bosser ».
Toi, est-ce que tu pourrais nous raconter
comment tu as réagi, parce que tu es Scrum Master
de certaines équipes ?
Est-ce que tu pourrais nous donner un exemple
d'un dernier moment où il y a eu une crise,
et où il a fallu gérer la crise ?
Quel style tu as eu, comment tu t'es positionné
par rapport à l'équipe ?
Ben typiquement, je l'ai fait via la rétrospective.
Donc il faut savoir, il y a toujours évidemment plein de styles
et de manière différente de faire,
moi souvent, j'utilise la rétrospective
comme mon premier moyen d'action,
c'est-à-dire qu'on n'y vivait pas de manière neutre,
c'est-à-dire que j'étais avec l'équipe
pendant typiquement deux semaines
et j'ai vu un peu ce qui s'est passé.
Donc du coup, il y a un côté, voilà,
j'imagine ce que dont l'équipe a besoin,
donc là évidemment il y a tout mon expertise,
mon passé, mon expérience,
par contre je ne vais pas arriver en disant
les gars, il faut faire ça, etc.
Déjà parce que ça se trouve, je vais complètement me planter.
C'est eux qui sont dedans, donc moi je suis quand même
à moitié dedans, donc si je leur dis
il faut faire ça, ça se trouve, je vais même taper à côté.
Après il y a aussi le fait qu'ils me controngent
peut-être pas par principe.
Donc par contre en retrospective,
je vais utiliser tout le format,
je vais adapter le format pour les driver
de certaines manières. Si je suis bonneur,
voire je suis à peu près sûr qu'il y a des problèmes
plus de relations dans l'équipe,
c'est parfait, on va mettre des activités
qui vont nous orienter vers ces questions
de relations, etc. Si j'ai raison,
logiquement, ça va finir sur le tapis
et ça va être adressé. Après si j'ai tort,
c'est pas grave, la retrospective tournera autrement
et on parlera d'autres choses et il n'y aura pas de soucis.
Mais moi, c'est pas mal comme ça.
Effectivement, si tu parles des dernières fauts
servais, il y avait eu ce genre
de soucis là, il y avait des développeurs
qui n'arrivaient pas à travailler ensemble
tout simplement. Du coup,
c'est entraîné en cascade,
c'était un peu obscur, est-ce
que les storiais avançaient ou pas,
ou s'en était du coup, le PO
rentrait aussi un peu dans le cercle,
il était aussi perdu, il savait pas si ça avançait
ou pas. Du coup, il en avait à se demander,
est-ce qu'on me ment en fait, ou est-ce qu'on me cache
des choses ? Donc, quand on a fait
les ateliers comme ça là-dessus, que j'ai
aussi documenté, d'ailleurs, cette atelier
sur mon arti et sur mon blog,
en gros, on essayait de
voir quelles sont les relations entre les gens,
comment on en échange, et est-ce que les
autres personnes ont la même perception ?
Vraiment, c'est dit là
d'aligner toutes les personnes,
dans le même registre, il y a aussi
créer de la sûreté, quoi que les gens soient
libres de parler, etc. C'est une autre
retrospective que j'ai faite. En fait, c'est la base.
Et c'est super compliqué de construire
autre chose tant qu'on n'a pas adressé ces sujets
là, et c'est vrai qu'avec leur cul, je
rencontre que c'est un peu les activités
de base qu'on devrait maîtriser en Scrum Master,
mais on les aborde que très tard, en fait,
parce que c'est pas simple, et parce qu'on
part toujours du principe que ça tourne,
que ça roule, etc.
Moi, la dernière fois que j'ai dû
passer en mode plus directif,
je me rends compte que c'était lié
à des échéances qu'il n'y a pas longtemps,
il y a quelques semaines.
Et quand je réfléchis bien,
je suis passé dans un mode directif
sur le qui fait quoi.
Même si je demandais toujours, par principe,
si les gars étaient ok,
c'était quand même fortement suggéré.
Après, sur la manière de
faire, vu qu'il y avait beaucoup
de techno en jeu,
j'ai pu mettre mon grain de sel sur la
techno que je maîtrise, savoir Rubien
de Reils, mais après, c'est vrai que les
devs mobiles natifs,
ça, par contre, ça m'échappait un peu.
Donc je contrôlais
par les artefacts, c'est-à-dire, est-ce
que j'avais de l'intégration continuous,
du continuous delivery,
des tests autos, de la couverture
de code, que parce qu'il était visible
extérieurement.
C'est intéressant ce que tu dis, parce que
finalement, en tant que Scrum Master,
ou même PO, qui ne serait pas technique,
comme ce que tu as dit là, finalement, je n'ai pas besoin
d'aller dans le code pour quand même avoir
un peu un feedback de est-ce que ça tourne
ou pas. Ah, c'est clair. Le problème, c'est
que ça reste des enjeux techniques, donc
encore faut-il bien
comprendre à quoi ça sert tout ça.
Et l'importance que ça, parce que moi, ce que
je vois, c'est que souvent, quand on dit
au PO, on va passer
une à deux journées à mettre en place le
truc de déploiement
continue par plateforme, le mec te
regarde et te dit, mais c'est quoi le fonctionnel
qui va émerger ? Alors le fonctionnel, c'est que
tu vas avoir des releases facilement.
Non mais d'accord, mais sinon, ça sert à quoi ?
Et la valeur perçue, tu vois, il y a
une grosse partie d'éducation, donc
oui, tu as raison, on peut contrôler
des choses sans un technique.
Encore faut-il être sensibilisé et connaître
l'importance de ces choses-là, et moi, je dois
reconnaître que dans mes clients,
j'ai quand même beaucoup de profils qui sont
pas très techniques, ils viennent me chercher
pour ça, et qui
sont très centrés
sur la feature livrée, quoi.
Après, pour moi, ça, c'est censé être
aussi parmi les compétences
à acquérir du développeur,
je suis capable d'expliquer
l'impact en termes de
sur le business. Donc effectivement,
ça ne change pas forcément le fonctionnel, mais
oui, on
développera plus vite, on pourra réaliser
plus souvent, il y aura juste moins de risques, on diminue
la probabilité qu'il y ait un bug. Ça,
c'est un exercice sur lequel, toi, tu vas se
faire juste pour dire, c'est sa double sens,
qu'effectivement, la personne doit
construire au fil de l'eau une sensibilité
technique. Maintenant,
il faut aussi se rendre compte que oui,
c'est quand même le business qui compte, et donc
quand je veux faire un refactoring,
un changement de SDK ou n'importe,
pourquoi je le fais ?
Parce qu'effectivement, si ça n'a pas de valeur,
vraiment, si ça n'a pas de valeur,
il a raison de me dire non, il faut que ça aille
de la valeur. Et la vérité, c'est qu'il y en a,
c'est juste que
on n'arrive pas à mettre les mots dessus, c'est
un exercice assez particulier.
Dépêche, je te remercie
pour cet échange.
C'est toujours un plaisir.
Quant à toi, chers auditeurs, j'espère que
tu as apprécié cet épisode. Si c'est le cas,
je t'invite à le partager avec un maximum
de monde. Et je te dis à demain.