Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec J.P. Lambert, J.P. bonjour !
Bonjour !
Une fois n'est pas coutume, c'est une surprise pour J.P.
puisque je ne l'ai pas prévenu du sujet que j'allais envoyer à Dessin,
parce que J.P. la dernière fois nous chauffait un petit peu,
ça avait donné lieu à pas mal d'échange sur
est-ce que le Tech Lead est un antipaterne ?
Dans le sens où il rassemblait en lui
finalement beaucoup de pouvoirs, beaucoup de responsabilités
et ce qui allait un peu à l'encontre
de la notion d'organisation, d'auto-organisation
et d'une notion d'organisation plate,
avec peu d'héarchie.
Et moi aujourd'hui j'ai envie de faire le Troubillon
et d'avenir chercher J.P. parce que j'ai envie de te dire J.P.
si on applique le même principe, est-ce que le Scrum Master
n'est pas un antipaterne ?
Parce que dans l'extrême programming, ce que j'ai toujours préféré
à l'XP qu'à au Scrum, c'est que
cette responsabilité de l'auto-organisation,
cette responsabilité et de l'animation
effectivement t'as un coach qui arrive,
qui est là pour aider l'équipe.
Mais la grosse différence c'est que dans l'XP
il a vocation à partir ce coach,
il a vocation à rendre l'équipe autonome
et il n'y a pas de rôle qui prenne le relais,
ce rôle est distribué sur l'équipe.
Pourquoi est-ce que dans le Scrum
on devrait garder un Scrum Master ?
Je pense qu'il y a plusieurs manières
de regarder les choses.
Je pense qu'autant seulement on n'est pas
sur la même temporalité, c'est-à-dire que
finalement en extrême programming,
enfin pour le coup je te fais confiance,
je ne maîtrise pas jusqu'à ce point-là
sur le fait que le coach est censé partir.
Alors là on est peut-être justement à se dire
qu'on dépasse le cas où l'équipe est mature
et où est-on de toute seule,
alors que Scrum finalement,
en fait la plupart des équipes vraiment matures
que j'ai vues faire du Scrum,
à la fin s'écartent du Scrum.
Pour plein de raisons que ça soit
parce qu'il n'y a plus de productonneur,
mais maintenant c'est toute l'équipe
qui se le produit, que ça soit parce que
finalement on s'oriente plus vers du campground
ou ainsi de suite.
Il n'y a pas plein de machins.
Autant que quand on démarre, c'est super important
de faire du Scrum by the book
parce que sinon en général on fait juste du grand n'importe quoi.
Autant une équipe qui est déjà bien mature,
j'ai du mal à percevoir le cas
où on ne dérive pas vers autre chose en fait.
Est-ce qu'il est normal ?
On construit son propre framework
qui devient complètement adapté au mieux
à sa propre situation.
Donc au début on a besoin de ce framework
pour bien mettre en place tous les principes de base
qui restent comme
la mejoration continue et la rigueur.
Mais une fois qu'on les a vraiment acquises
la mejoration continue finie
par nous emmener vers autre chose.
Et sur autre chose, c'est peut-être aussi qu'on a plus besoin
de Scrum Master.
Après on peut aussi parler
d'organisation cible.
XP
il y a la maigre connaissance je crois
n'a jamais vraiment été utilisée
officiellement sur
des projets critiques
ou vraiment énormes.
Ah ça va, c'est pas la peine de frapper en dessous de la ceinture pour te venger là ?
Non c'est pas ça, c'est juste pour dire que
en fait
c'est ce que je disais beaucoup
lors de ma conférence
sur le rôle de Scrum Master
c'est que souvent on se dit
oh c'est bon si l'équipe est mature
elle a pas besoin de Scrum Master
ce que je réponds c'est que
ouais mais attendez des équipes matures
ok je suis d'accord, moi j'en ai vu, ça arrive
c'est génial, ça marche nickel
mais il faut aussi que l'organisation
elle soit mature.
Et ça c'est beaucoup beaucoup plus rare, voir que j'en ai pas vu
je dis pas que ça existe pas un Spotify
et compagnie, c'est pas pour rien qu'on nous en parle
mais c'est assez rare en fait
d'avoir vraiment l'organisation apprenante
très mature.
Et du coup le rôle de Scrum Master
il est aussi beaucoup par rapport à l'organisation
donc ce qui est vrai c'est que
au fil de la monter en
compétences en maturité de l'équipe le rôle
de Scrum Master change. Au début
oui il est là en professeur
on fait la méthode c'est comme ça il est là aussi beaucoup
à assurer la rigueur, attendez
là faut le faire bien, ça c'est ça
etc. et après l'équipe a acquis ça
c'est normal et parfois elle a acquis très vite
parce que on est déjà sur des personnes
qui sont peut-être déjà matures
des gens qui sont déjà des professionnels
du développement etc.
Mais maintenant le Scrum Master
il est encore pas mal de taf pour que l'organisation
devienne agile elle aussi
parce que sinon en fait
une équipe mature
dans une organisation qui n'est pas agile
en fait ça va tourner vaguement
mieux, il y a un moment où on se tape les murs
il faut que les murs ils bougent aussi
donc
et après les gens diront
oui mais ça c'est pas du Scrum Master
c'est du coach agile, a priori c'est le même rôle
donc voilà
je pense qu'on peut l'expliquer
de plusieurs manières, après le fait de le comparer
au Tech Lead et de ressortir
exactement mes arguments contre celui de Scrum Master
je pense qu'on avait probablement à dire
des choses qui tiennent la route
c'est probablement pour ça que je critiquais le Tech Lead
c'est pour garder mon pas
mais c'est vrai aussi qu'on peut avoir ça
c'est que
peut-être que l'argument de dire
on n'a pas besoin de Tech Lead, l'équipe va s'auto-organiser
ça va être génial, tiens parce qu'on a un super Scrum Master
et qu'en fait
si on a pas un super Scrum Master, il faut qu'on a un super Tech Lead
il y a aussi peut-être un peu le Saint Pont qui se mord la queue
au final c'est chaque équipe
chaque personnalité
qui trouve ces fonctionnements
non, tu as pas de temps
sortir comme ça
d'un simple
c'est chacun qui trouve son chemin
non, non
on va essayer d'être rigoureux
et en fait je trouve une certaine cohérence dans ce que tu dis
finalement ce que tu dis c'est
oui quelque part
le signe que l'équipe a besoin
dans Scrum Master est un signe qui a la besoin
de murir et l'organisation
mais d'à la même manière qu'une équipe qui a besoin
d'un Tech Lead
est-ce que tu amènes est vachement intéressant sur la notion d'organisation
on va y revenir
mais quelque part dans l'argument du Tech Lead c'est pareil
parce que l'organisation
c'est elle est pas prête à entendre parfois qu'il y a du travail de fond à faire
qu'elle est pas prête à entendre qu'il faut
investir c'est pareil et tu vas te taper contre les murs
donc quelque part ce qu'on est en train de dire
c'est que le rôle de leader
que ce soit Tech Lead
ou que ce soit Scrum Master
parce que Scrum Master pour moi a un rôle de leadership
ce qu'on est en train de dire c'est qu'effectivement
c'est surtout
c'est d'autant plus utile
voir indispensable pour les équipes qui sont pas matures
on peut y mettre ce qu'on veut derrière ce terme de mature
mais qui ne sont pas complètement autonomes
et qu'au fur et à mesure que l'équipe acquiert
cette autonomie, cette maturité
parce que de la même raison que ce que t'as évoqué
un Tech Lead au bout d'un moment
quand les patterns sont compris, quand
l'équipe tourne, quand le savoir a été transmis
peut-être que le besoin du Tech Lead est moindre
quoi
il y a peut-être aussi un élément que j'ai envie
de rebondir sur ce que tu viens de dire
c'est... alors ça c'est aussi
dans le cas idéal
où voilà, l'équipe ne bouge pas
parce qu'on a aussi souvent le cas où finalement
l'équipe elle bouge régulièrement
et donc finalement on a aussi besoin
d'avoir un peu toujours des
référents, des piliers qui restent
pour que les nouveaux
c'est quoi du coup la notion de maturité
et assez... on arrive peut-être à l'avoir
en termes d'équipe mais c'est aussi au prix
que régulièrement il y a des nouveaux qui faut qu'on embarque
dans cette maturité d'équipe là
pour moi la maturité ultime
c'est quand l'équipe est par elle-même capable
d'embarquer des nouveaux. Après toutes les questions
de proportion si tu changes les 3 quarts de l'équipe
il va être plus compliqué que si tu changes
un membre. Mais on en revient sur la maturité
de l'organisation c'est aussi commode
d'avoir... que... d'en avoir qu'un seul référent
qui ne bouge pas et tout le reste
on s'en fiche. Donc et là on arrive
sur les notions pourquoi c'est des autres batters
mais c'est finalement...
Il y a aussi un élément d'ailleurs que j'ai
je ne pensais... c'est...
c'est un peu... c'est une question
qui pose des bas, c'est... est-ce que le
Scrum Master est un manager?
C'est une question qui pose des bas parce qu'évidemment
déjà parce que c'est un peu un gros mot
manager.
Et en fait il y a plusieurs points de
vue de répondre
à cette question-là.
C'est évidemment pas un manager
dans le sens du petit chef à la française
évidemment, qu'il doit offrir
n'est pas un manager mais juste un petit
chef.
Par contre, manager
dans le sens, la personne qui s'assure
que l'environnement est là, que
en termes d'humains, les personnes
grandissent bien et ainsi de suite
on n'est pas si loin que ça.
Et tu vois, c'est peut-être
ça aussi que... que... que... que Monsieur
The Otherlands compagnie
avec, quand ils ont fait le modèle, c'est que
là peut-être qu'en fait le Scrum Master
c'est le manager de l'équipe
évidemment on change tous les noms
parce qu'on veut pas retrouver les mêmes travers
mais du coup voilà et là
ça fait écho à des discussions qu'on a pu avoir. Oui, quand tout part
il y a un manager qui est là, qui est à côté
qui s'assure de diverses choses
donc ça peut être aussi une manière
de voir les choses de se dire, bah oui, non. Après
effectivement, il est de moins en moins présent
sur l'équipe, peut-être qu'il s'occupe de plusieurs
équipes, peut-être qu'il s'occupe justement
beaucoup plus de l'organisation et là on voit bien
le côté rôle du manager c'est que finalement
c'est bon, il se débrouille, maintenant
ce qu'ils ont besoin c'est d'avoir du support
de l'organisation et son boulot
il est surtout sur l'organisation. Il est d'être
présent quand on a besoin de lui mais au final
c'est surtout l'orgas. Donc ça peut être aussi
un point de vue de se dire bah oui mais parce qu'en fait
on a toujours besoin de ce rôle de manager
voilà donc là c'est très très
un peu iconoclastin ce que je dis je pense que ça peut
faire hurler pas mal de gens et c'est une question
tendicieuse mais ça peut être une piste de réflexion
En fait moi je te propose même que ce soit
un sujet d'épisode parce que
là on arrive au
bout de la timebox et
moi ça me pose plein de questions
sur comment tu définis exactement le rôle
en fait ça ramène à la question du rôle
du manager et il y a des questions
très à la fois organisationnelle
et il y a la
fois des questions plus larges d'état d'esprit
je te propose que ce soit un autre sujet
de postcast en tout cas pour revenir
sur ce qu'on a évoqué
il y a deux points que je voudrais
rajouter. Le premier
c'est de dire que je n'ai vu les seules
expériences de scrum que j'ai vues
tourner à plein régime
ce n'était que dans des boîtes
qu'il l'avait
mis en place à l'origine
et même dans celle là
je parle juste de ma petite expérience
je ne suis pas en train de dire que c'est la seule manière de faire
je dis juste que je remarque que les entreprises
qui ont démarré autrement et qui veulent y aller
mettent beaucoup de temps pour y arriver
à se transformer
et que les seules que j'ai vues
parce que finalement le scrum est quand même assez récent
les seules que j'ai vues vraiment tourner à plein régime
c'était des boîtes qu'il avait
démarré là dessus et même dans ces boîtes
là j'ai un exemple en tête
finalement les autres services ils ont mis des années
à les faire
rentrer dans la logique
parce que les autres services, j'entends que le
dev produit était sur des
des proches très traditionnelles
et ça a été
un choc des cultures, ils sont pris conscience qu'à un moment donné
ils avaient du mal à distiller
la culture qui voulait
dans leurs propres boîtes, ce qui est quand même assez dingue
mais bon c'est comme ça
et puis sur cette notion
de leadership
qui doit amener l'organisation
vers l'esprit agile
je pense que le Scrum Master
par contre est beaucoup mieux outillé pour le faire
que le Tech Lead, parce que finalement le Tech Lead
il a le même rôle d'aider
l'entreprise et d'améliorer la culture
pour valoriser la technicité
par contre je pense qu'il lui manque
à moins qu'il les ait travaillés
ces compétences là, mais en général
un très bon développeur
en Tech Lead
ne va pas forcément
avoir les compétences relationnelles
de communication nécessaire
pour faire bouger les choses
et ça peut facilement
donner des étins sales, donner des clashes
moi j'ai quelques exemples en tête aussi
donc je pense que le Scrum Master est mieux outillé
parce que par contre un Scrum Master qui n'a pas de compétences
relationnelles et de compétences en communication
lui il est mal barré pour moi
la même manière de voir, je te vois
de l'éliminer de la tête, t'as pas l'air d'accompagner
ça m'évoque pas mal
de choses, je sais qu'une fois on parlait du rôle
est-ce que le Scrum Master est technique
je pense que
aux origines de Scrum
voilà, oui
aux origines de Scrum c'était
le rôle que tu décris en fait
du Tech Lead
qui en plus avait les compétences
on va dire les soft skills
qui allaient bien et qui avait vraiment
ce rôle de leader
et qui savait emmener tout le monde
et je dis pas que c'est mal
qu'on soit écarté de ça, encore que ça reste une
supposition de ma part
je pense qu'au début
c'était beaucoup plus flou
on était beaucoup plus sur ce genre de choses
voilà, après
moi je suis pas sûr qu'un développeur
qui est très bon mais qui manque
de soft skills doit finir Tech Lead
tout court dans l'absolu
pour moi c'est un peu de rôle différent
c'est un rôle managerial aussi
Tech Lead est quand même une dimension
faire grandir les gens
comme tu le dis, faire communiquer
faire passer beaucoup de messages etc
le bon Tech Lead
je suis pas sûr que ça soit
c'est pas un expert justement
on s'attend à ce qu'il soit bon
à minimum, voire très bon
mais
c'est pas juste un expert
c'est une subtilité
dans le shot carrière
je pense
en tout cas de ce que j'ai pu voir
un Tech Lead qui manque de soft skills
ça peut créer
plus de problèmes qu'autre chose dans l'équipe
mais c'est ce que tu as dit
c'est très intéressant
et je te propose que ce soit le mot de la fin
parce que là on a explosé la timebox
je te remercie J.P. d'être venu
avec plaisir
quant à toi cher auditeur
j'espère que tu connais déjà Jean-Pierre Lambert
si ce n'est pas le cas, va tout de suite sur Youtube
regarder sa chaîne, tu cherches Scrum Life
ou J.P. Lambert et tu te rembras
c'est un pur concentré
de retour d'expérience
et de super trucs
je t'invite vraiment à aller mater sa chaîne
et puis si ce n'est pas déjà fait, je t'invite
à rejoindre la communauté des artisans développeurs
sur artisanddeveloppeur.fr
je te dis à demain