Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Sur ton blog, JP, j'ai vu un article.
Est-ce qu'il vaut mieux que le Scrum Master soit technique ou pas ?
Moi, j'ai une opinion là-dessus, mais je suis curieux d'avoir la tienne.
Qu'est-ce que tu en penses ?
Alors moi, donc, effectivement, j'ai un article là-dessus.
Ce que je raconte, c'est que déjà, ce n'est pas un prérequis absolu.
Ce n'est pas un prérequis absolu.
Il y a plein de Scrum Masters qui sont très bien,
qui n'ont pas ce bagage, ce bagon de technique.
Et en fait, finalement, c'est aussi normal qu'on ait plein de bons Scrum Masters,
qu'il n'y ait pas ce bagon de technique,
parce que c'est un peu une forme de difficulté supplémentaire.
C'est-à-dire que quand on a le bagage technique,
c'est dur de résister à pas l'utiliser, en fait,
de ne pas rentrer dans des discussions techniques, etc.
Et donc ça demande peut-être un effort supplémentaire.
Ça dépend de comment on facilite les choses,
mais effectivement, quand on est en posture de facilitation d'une réunion,
un peu la règle d'or de la facilitation, c'est,
je ne participe pas, je suis neutre.
Effectivement, quand on est neutre, on prend du recul,
on n'écoute pas ce que disent les gens,
on écoute comment ils se le disent.
Et là, c'est assez simple de voir que,
tiens, il y a une personne qui reste dans un coin,
qui n'est pas impliquée,
il y en a une au contraire qui est très forte,
c'est tout le temps elle qui parle,
et tout le monde boise ses paroles, tout le monde se range.
Depuis tout à l'heure, on tourne en rond,
on est juste en train de dire les mêmes choses encore et toujours.
Et du coup, là, on peut avoir une vraie posture de facilitateur
qui aide beaucoup cette réunion,
puisqu'on détecte tout ça et on aide.
Et ça, effectivement, c'est plus dur
quand on a ce réflexe de s'intéresser à la technique
et de systématiquement rentrer dans les discussions,
et quand on est participant, c'est compliqué d'être facilitateur.
Donc c'est un peu une difficulté supplémentaire.
Donc ça veut peut-être juste dire que pour être bon Scrum Master,
quand on est technique,
ça demande un peu plus d'effort que pour pas être mauvais,
que si on n'est pas technique,
c'est pas très dur, finalement, de pas être mauvais Scrum Master.
Mais à l'opposé, finalement,
une fois qu'on a réussi ce cap-là,
obtenir être vraiment un Scrum Master hors-père,
ça devient peut-être difficile quand on n'a pas le bagage technique.
Il y a effectivement des ateliers où c'est très compliqué
de les animer si on n'a pas un minimum de compréhension technique.
Je donne l'exemple du découpage de User Story.
Il y a plein de manières de s'y prendre,
et en soi, c'est une compétence qui est très importante.
Toutes les équipes agiles doivent maîtriser ça,
et c'est assez complexe, c'est pas si simple.
Mais finalement, comment on apprend une équipe à le faire ?
Il y a un moment où on a beau leur expliquer comment ils doivent s'y prendre.
C'est pas pour autant qu'ils arrivent, en fait,
il y a un moment où il faut le faire par l'exemple,
il faut les prendre par la main,
et faire le premier découpage avec eux et les accompagner.
Et après, ils comprennent,
ils apprennent et ils vont y arriver.
Mais les toutes premières fois,
c'est tellement un peu alien,
quand on n'a pas l'habitude,
et c'est une manière spéciale de penser,
de se dire, je découpe un truc technique de manière verticale
pour avoir des petits bouts de fonctionnel.
C'est assez compliqué pour des gens qui n'ont pas déjà acquis.
Et comment on fait ce travail-là ?
C'est compliqué si on n'est pas technique,
parce que finalement,
si on ne comprend pas du tout ce que c'est que la User Story
et les fils que ça tire derrière,
comment on fait un découpage de User Story ?
Il faut quand même comprendre ce qui se passe derrière.
Donc, c'est...
technique ou pas, on peut très bien s'en sortir dans la profession.
C'est potentiellement
une difficulté supplémentaire de technique
pour ne pas être mauvais.
Par contre, pour être vraiment excellent,
c'est peut-être compliqué de le devenir sans être technique.

C'est un peu...
plusieurs points de vue que j'essaie de partager.
Je partage complètement ton point de vue,
notamment quand tu dis,
en tant que facilitateur,
d'être technique te donne
une difficulté supplémentaire
pour être partie prenante.
J'en arrive même à me dire que...
Enfin moi, c'est clairement...
Quand j'entends les gens réfléchir
et me dire j'aimerais devenir Scrum Master
ou j'aimerais aller vers là,
moi j'ai tout de suite des gros warning
qui viennent dans ma tête, parce que...
Souvent, un bon développeur,
surtout en France,
qu'est-ce qu'on va lui proposer
comme voie d'évolution, une voie hiérarchique.
Et malheureusement,
la voie hiérarchique dans l'agilité,
les gens ont fait parfois
un peu rapidement des transpositions
et le Scrum Master est perçu
comme une forme d'évolution vers l'eau.
Or, on sait tous les deux qu'il n'y a pas
d'ascendant hiérarchique, en tout cas,
c'est mieux d'éviter,
que c'est même nuisible d'avoir un
ascendant hiérarchique vis-à-vis de l'équipe.
Mais du coup, il y a ce truc-là,
moi je vois beaucoup de gens qui perçoivent
cette évolution-là comme une évolution de carrière.
Et je dis attention, attention, attention,
parce que
les compétences pour être un bon Scrum Master
ne sont pas du tout les mêmes
pour moi que celle d'un bon
TECOS, un bon développeur.
Et voire même, les développeurs
sont rarement équipés,
je ne vais pas tomber dans le stéréotype du geek
au fond de la grotte, mais un petit peu, peut-être,
des fois, il faut assumer.
Ce n'est pas les mêmes compétences.
Les compétences techniques et les compétences
de communication, ce n'est vraiment pas
la même famille de compétences.
Donc pour moi, je vais même plus loin que toi,
je considère que c'est même un inconvénient
d'avoir un bas grand technique.
Maintenant, derrière,
la question que ça pose, toi, tu dis,
à un moment donné, je vais avoir besoin,
je vais pouvoir me servir de mon côté technique
pour aider l'équipe à découper, très bien.
Pour moi, la question est différente, elle est plutôt
sur la légitimité.
C'est-à-dire que les développeurs, on a
une espèce de Neabullshit incroyable.
Et dès qu'un mec
essaye de faire semblant
de genre, je maîtrise un sujet
ou essaye de s'intéresser à un sujet, si on sent
qu'il est vraiment trop loin du truc,
il y a la cote de crédibilité qui chute en flèche.
En tout cas, c'est l'impression que j'ai.
Du coup, la question, c'est
comment faire un Scrum Master pour être
crédible vis-à-vis de son équipe
et être légitime, sans avoir la compétence technique.
Malheureusement, pour le coup, je ne suis pas
sûr d'avoir la réponse.
Parce que moi, justement, j'ai le profil
ou avant d'être Scrum Master, j'étais technique,
j'étais développeur. Et c'est vraiment
pour le coup quelque chose que j'ai pu ressentir
dans mes équipes. Effectivement,
il y a une phase où on est un peu
en se découvre l'un l'autre
et on se construit sa légitimité
au sein de l'équipe.
Effectivement, moi, j'ai cette phase-là
où, oui,
je construis ma légitimité
au travers de ma compétence
technique, mais effectivement, quand on va
me parler de technique, je comprends.
Comme je disais,
moi, je signe casquette, c'est souvent
autour du test, etc. Donc là, on est
en train aussi de toucher du coaching un peu technique.
Et donc voilà,
c'est peut-être pas le chemin
classique pour un Scrum Master,
parce qu'effectivement, Scrum Master est pas technique.
Comment il asseuille sa légitimité
en tant que tel ? Je sais que moi,
ça m'est vraiment rêvé dans les équipes de...
Oui, le fait que
je comprenne ce qui se passe
me donne une forme de
légitimité autour de l'équipe.
Après, ça va dépendre de
l'ambiance dans laquelle on se retrouve en fait.
Effectivement, parfois, il y a des équipes
où il y a une forme presque de défiance,
c'est... Qu'est-ce qu'on nous embête, quoi ?
On laisse nous faire le boulot
comme on a envie, etc. Alors que d'autres
finalement, ils sont déjà
dans une agilité qui tourne
et c'est juste super bienvenue
un mec qui est là et qui a du bagage agil
et qui va nous aider à mieux nous organiser
et à mieux voir nos examens d'amélioration.
Et donc forcément,
selon le contexte,
oui, on n'asseuille pas sa légitimité
de la même manière, on en a plus ou moins besoin.
Donc voilà, donc je...
Je bote un peu aux touches sur cette question.
Non mais tu bote pas du tout en touches,
au contraire, je pense que tu y réponds,
au travers de l'exemple que tu mentionnes
et de ton parcours.
Ce que j'entends, c'est que clairement,
ton passé de développeur te permet
d'asseoir ta légitimité.
Ouais, moi, dans mon quotidien, c'est vrai que c'est souvent
comme ça que je le vois.
Après, Fittian, c'est pas la seule chose,
mais c'est assez...
Oui, c'est apprécié, quoi.
C'est qu'effectivement, quand on aide les gens,
ouais, quand... Ouais, elle est challengeée,
à avancer, à...
Ah, après, il y a toujours la forme, bien sûr.
Fittian, je suis bien conscient que
j'ai plus fait vraiment de devs
à temps plein depuis la somme d'année,
que c'était évidemment pas
sur les mêmes technos, que c'était sur des vieux trucs, etc.
Et donc voilà, donc oui,
quand on formule une suggestion,
on met des formes autour.
Voilà, attention, est-ce que...
Mais il y a un moment, en fait, où ça, avec les choses se touchent,
puisque quand c'est... Si on veut leur vendre
du père programming, ça me choque pas
qu'en tant que Scrum Master,
je vende du père programming, bien que ça soit
avant tout une pratique de
Craftsman-Chim, une pratique technique d'ingénieur.
Et il y a un moment,
voilà, la question, ça devient, on est face
aux bordes, les mecs, ils sont là et se disent
« Bah, comment... Comment on peut faire ?
On peut pas travailler en même temps ? »
Et là, on leur dit, est-ce que ça irait
pas plus vite si on s'y mettaient à 2 en même temps ?
Est-ce qu'on pourrait pas essayer ?
Et là, du coup, il y a quand même
une adhérence, finalement, entre les sujets.
Et c'est normal, dans toute l'équipe, le PO,
il est pas technique, mais le devient
forcément un peu, puisqu'à la fin, on construit
un produit qui est technique, tout comme on s'attend
à ce que l'équipe de développement, qui est technique,
s'approprient le produit. Donc au final, tout ça,
c'est pas vraiment des sujets différents,
ils se touchent et
ils se combinent. Donc,
c'est forcément une forme d'attout, mais
effectivement, comme je l'ai dit et comme tu l'as repris,
attention à
bien faire la part des choses, et quand je suis
en Scrum Master, quand je me mets en facilitation,
attention, je...
Ce que je dis, il faut pas écouter ce qu'ils disent,
il faut écouter comment ils le disent.
Ça, c'est une compétence à acquérir,
qui est pas...
forcément évidente, ou iné, iné
à tout le monde. Et c'est effectivement un peu ça,
le soft skill qui devient utile
pour te permettre d'être Scrum Master, que si tu l'as pas,
ça risque peut-être
de tourner en chef de projet technique,
pas terrible à voir.
Et...
Écoute,
je te remercie, ce sera le mot de la fin,
merci J.P. d'avoir
participé à cette tour chronique.
Si on veut aller lire l'article
d'origine, on vient où ?
On va sur jp-lambere.me, mon blog.
Je te remercie J.P.
A bientôt.
J'espère que tu as apprécié cette émission.
Et si c'est le cas, je t'invite
à venir t'inscrire sur artisan-développeur.fr
Et je te dis à demain.