Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Michael Azera et Jean-Pierre Lambert.
Bonjour les gars.
Salut. Salut.
Michael, c'est toi qui nous donne cette super opportunité, je te remercie.
C'est gentil.
Tu as ouvert le feu avec un super article sur « Faut-il abolir le planning poker pour le bien de l'équipe ? »
Oui.
Tu touches là quand même un sacrosin du scrim.
Alors comment oses-tu blasphémer ?
Je peux passer du côté obscur depuis bien longtemps.
J'avais mes raisons après.
Vous avez tous lu l'article en manchée, c'est ça ?
Je pense que tu peux pour les auditeurs qui n'ont pas lu en reprendre la substance et reprendre ton point de vue.
La substance, c'est que derrière le planning poker, qui fait partie d'une mini-jeu du scrim en tout cas, du spring planning,
il y a un côté psychologique que beaucoup de gens ignorent, ou se voient la face, ou ignorent complètement.
C'est que les développeurs sont tous humains et que pas tout le monde va avoir la bonne direction à prendre.
Pas tout le monde va essayer de mettre toutes les forces de son côté pour avoir le bon logiciel.
Chacun va penser un petit peu à son propre périmètre, son propre job, etc.
Et que la finalité qui est en fait de construire un super logiciel, il arrive que beaucoup de personnes l'oublie.
Beaucoup de personnes préfèrent se faire bien passer auprès des managers plutôt que d'arriver aux exigences d'un bon logiciel,
quitte à paraître moins efficace ou moins performant auprès du manager.
Ce que je dis, c'est que j'ai réveillé pas mal d'hypothèses de scénarios qui se passent avec le planning poker que j'ai vécu moi-même.
Et j'arrive à soulever quelques points que le planning poker, ça relève des estimations.
Ça passe avant tout par la connaissance de chacun, non pas du logiciel, c'est facile en général,
on boit sur des logiciels qui sont assez maîtrisables même dans l'esprit.
Mais il y a des niveaux techniques complètement disparates.
Et le problème, c'est qu'avec ce genre de planning poker, la plupart des managers et Scrum Master,
j'y mets la plupart, donc je n'y mets pas de ment parce que je n'ai jamais travaillé avec,
mais la plupart de ces Scrum Master prennent les estimations pour argent en comptant.
Les développeurs ont bien compris ça, on est resacélation, on est rattrapés au tir à chaque fois,
donc tous les délits du matin, etc.
Tu m'avais dit trois jours mais t'as passé quatre jours.
On a beau leur dire, on a l'impression qu'il faut faire polytechnique pour comprendre ça,
on a beau leur dire, c'est une estimation, c'est comme la météo, on pensait mais ça n'est pas.
Il y a eu plein d'imprévus, finalement on s'est rendu compte que c'était plus complexe que ça, etc.
En fait là tu mélanges trois trucs pour moi, mais peut-être que du coup,
tu mélanges le fait que le regard du manager qui crée un biais dans l'échange,
parce que tu dis les développeurs pour ne pas passer pour des burnes,
pour ne pas passer pour des casse-pieds, ou des planquées,
ou des fénéants, ou des planquées, vont en parler.
Ils ne vont pas estimer à la juste valeur par rapport à leur propre compte.
À ce qu'il faut, ok.
Après il peut y avoir des agendais, des intérêts personnels cachés, ok.
Donc il y a la relation au manager, il y a aussi la relation à ce qui a été donné comme estimation,
et la relation à l'ignorance de la profondeur d'une feature, voilà.
L'ignorance technique.
Parce que toi, ce que tu proposes à la fin de l'article,
c'est que tu proposes de partir sur que cette réunion ne se fasse pas devant le manager,
et se fasse que avec un Tech Lead.
Alors moi ce que j'ai, c'est que cette réunion, on la maintient,
c'est-à-dire qu'on garde un sprint planning, c'est toujours sympa même de se réunir,
mais au moins parce que les gens, je comprends qu'ils attendent des estimations, etc.
J'arrive pas jusqu'à dire, même si je suis pour, mais on ne peut pas le faire en entreprise,
je suis au courant de nos estimates, on n'en est pas là,
mais je parle du principe qu'il faut en amont que les développeurs se rencontrent
pour tous ensemble se confronter à une estimation qui paraît moyenne pour tout le monde
et qu'on puisse annoncer directement un sprint planning, écoutez, pour nous, voilà, c'est du 13.
Mais au moins ça a été pensé par tout le monde.
Ce qui te gêne, c'est que cette discussion est lieu devant autre chose que des développeurs.
C'est ma passade, c'est qu'il n'y a pas de discussion, c'est la vie, c'est comme les délits,
dès que ça commence à parler technique, attendez, attendez, vous verrez ça entre vous.
Le problème, c'est qu'entre nous, on n'a jamais cette occasion, et dans beaucoup d'équipes,
il n'y a pas ce leader, si on n'impose pas quelque chose, il n'y a pas ce leader qui va dire
« hey les mecs, ils venaient nous réunir », parce qu'il va passer pour prétentieux,
il va passer pour « mais de qui, pour qui tu le prends ? »
Non, t'inquiètes pas, moi je suis déjà sur ma tas, je sais ce que je ferai plus tard.
Les gens deviennent égoïstes en fait, mais c'est normal, donc ça fait partie du jeu.
Moi ce que je propose, ce que j'ai fait pendant un an là, dans la dernière mission,
c'est que je prenais les développeurs à part, dans un tableau blanc,
une salle comme J.P. est là par exemple, avec un tableau blanc, et on se challenge émutuellement.
Attends, tu me dis « pour faire un trop minoscope, il faut récupérer ça, ça prend deux jours, d'accord ? »
Mais est-ce que tu as pensé au grand que passe ?
Ok, là en fait tu es en train de nous décrire ce que doit être un planning poker,
ce que tu dis juste c'est que cette discussion pour toi, c'est difficile de l'avoir devant un manager.
Elle peut pas dire « 10 minutes » des fois durant le journée, cette discussion.
Donc fatalement tu peux pas la faire devant un manager.
J.P., qu'est-ce que tu en penses de tout ça ? Qu'est-ce que ça évoque pour toi tout ça ?
Alors là pour le coup effectivement, je rejoins Michael, effectivement on ne peut pas avoir ce niveau de détail de discussion
lors d'un planning poker.
Mais c'est tout le but.
Oui.
C'est tout le but.
Justement le but c'est d'avoir des estimations et de les avoir rapidement.
C'est vraiment l'idée que fondamentalement, une estimation c'est du déchet.
Le langage ligne c'est du déchet.
Effectivement, passer une heure à estimer, ça construit moins de valeur que passer une heure à construire le produit.
Donc du coup très bien, on est dans des contextes, comme tu disais Michael,
le No-estimate et la plupart des entreprises ne sont pas encore prêtes pour y aller.
Donc on se retrouve dans un mode où il faut quand même planifier et donc estimer avec tous les soucis que ça remène avec.
Donc du coup passons moins de temps possible dessus.
En tout cas c'est l'enjeu du planning poker.
Et du coup par rapport à l'argument initial de Michael, qu'est-ce que tu en penses toi de cette difficulté à avoir de faire ce cérémonial devant le management ?
Alors déjà il n'y a pas le management dans l'équipe.
Le Scrum Master n'est pas manager et le manager n'a rien à faire dans cette réunion-là.
Déjà.
Ensuite effectivement quand on lui...
On en revient en fait, c'est sur le...
Ah, Michael, laisse-lui les up, s'il te plaît.
Non mais on en revient, c'est sur le mindset qu'effectivement ces estimations, après elles vont finir par être soumis d'une manière ou d'une autre.
Soumis n'est pas le bon terme d'ailleurs, elles vont être présentées.
Et c'est ça le problème d'ailleurs, c'est qu'on est logiques d'où plutôt...
Elles sont soumis et quand la seule option derrière c'est...
Ah mais non mais en fait on acte deux mois donc en fait je m'en fous d'une estimation ça doit être fait en deux mois.
Effectivement quand on est dans ce contexte-là,
oui on se retrouve à faire des solutions de repli pas très clean, on voit tout le...
Oui mais en fait on n'est pas dans le cadre agile.
Donc forcément quand on n'est pas dans le cadre agile, le planning poker il a du mal à bien marcher.
En tout cas dans le format de base.
Et c'est intéressant quand je relève ce que tu dis, il y a des jeux psychologiques qui se passent derrière.
Bah oui c'est ça le problème.
Comment ça se fait ?
Il y a des situations qui encouragent ou qui permettent ce genre de jeux psychologiques.
Mais c'est plus global.
Qu'est-ce que le Scrum Master ?
C'était l'expression de Constantin, Constantin Guerre.
C'est le Scrum Master chronomètre.
Il fait rien d'autre, il fait juste ça.
Voilà moi je...
Dans les exemples que tu donnes,
moi ça me fait surtout risser le poil.
Effectivement il y a une...
Ce que tu dis est tout à fait censé.
Si on part de l'hypothèse de base, oui c'est ça qui arrive.
Le problème c'est que ce n'est pas du tout les bonnes hypothèses.
Ce n'est pas du tout comme ça que ça devrait se passer.
Les estimations devraient être relatives.
Ça ne se pose jamais la question du nombre de jours que ça prend.
On se dit juste, est-ce que c'est plus compliqué ou moins compliqué,
compliqué au sens large, un tas de critères ?
Bah c'est là que tu touches le fond du problème, avec cette phrase-là.
De le faire en relatif ?
C'est plus compliqué ou plus compliqué.
La plupart des développeurs avec qui j'étais,
j'ai vu tout un terme de développeur qui était 10 ans de plus ou 10 ans de moins,
ils ne peuvent pas savoir si c'est plus compliqué ou pas.
Je prends un exemple.
C'est à fin de t'espoir ma chute.
On pourrait revenir mais en tant que Scrum Master,
il y a des outils justement pour expliquer ce que c'est le relatif.
Justement pour arriver à ce stade où en 5 minutes,
enfin on arrive à sortir une estimation grosse maille,
et c'est ce qu'on veut, puisqu'encore une fois,
l'enjeu c'est de faire une roadmap de ce qui va se passer dans 3 mois.
C'est ça ?
Ne prenons pas la tête 3 heures.
Alors à ce stade de la discussion,
j'ai prouvé un besoin, c'est de reformuler.
Ce que tu dis Jean-Pierre,
par rapport à l'argumentaire qui a été développé par Mickael,
c'est que si on part de l'hypothèse de base,
qui est que finalement l'environnement et l'écosystème
n'ont pas été corrompus par rapport aux hypothèses, aux valeurs âgées,
oui, le reste du raisonnement est potentiellement valable.
Donc finalement ce que tu viens de dire, Jean-Pierre,
c'est que c'est plus une question de contexte que d'outils.
Là où le titre un peu accrocheur et volontairement accrocheur
de Mickael remet en cause l'outil,
pour toi c'est plus le contexte en fait.
Ça dépend de ce qu'on met derrière le contexte,
parce qu'un bon Scrum Master ça peut aussi aider énormément,
à justement protéger l'équipe,
à quand même réussir à mettre en place
que la pratique se passe pas trop mal,
même si derrière l'environnement au-delà de l'équipe
et lui il n'est pas complètement clean.
Mais sinon oui.
J'aimerais bien revenir, je pense qu'on n'est pas vraiment
sur le vrai problème.
Évidemment ça fait partie de ce que j'avais écrit, etc.
Mais le vrai problème c'est pas celui-là.
Le vrai problème c'est que c'est un poste que j'avais cuit hier.
C'est-à-dire je le fais très simplement.
Dans le projet dernier que j'ai fait en Frisland,
pour un grand groupe, etc.
J'ai imposé des pratiques élitistes.
Mais quand j'ai élitiste c'est top level,
c'est-à-dire du TDD mais perfect, strict,
ton sensu sur front et back, du Redux,
la plupart des gens savent même pas ce que c'était,
du fonctionnal programming,
la plupart faisaient de l'objet,
là on était en fonctionnal programming,
du domain driven design.
La plupart ne savent même pas ce que c'est un bout de ligne de contact,
donc il fallait apprendre, il fallait former sur ça.
J'avais imposé ça parce que j'étais technique,
je pouvais le faire et le projet s'y prêtait complètement.
Donc le problème c'est qu'il faut imaginer vous,
comme un enfant,
qui n'a jamais vu tout ça et on lui dit
en combien de temps tu fais cet exercice de maths ?
Parce qu'on part du principe,
il connaît ce qu'il imagine qu'il doit faire.
Mais non, il sait pas ce que c'est une racine carré le mec.
Il sait pas du tout.
Donc on arrive en fait à demander
à des gens d'estimer quelque chose qui ignore totalement.
Et donc il y a tout un format,
et c'est pour ça que je proposais quelque chose en salle
pour les avertir,
regarder ce qui vous attend.
Tu me disais, ce truc là c'est juste une requête en base ?
Non, il faut faire le test ici,
il y a ce wrong pass, il faut que ça le programming,
il faut créer ce truc là, il faut faire ça, il faut faire ça.
Donc là où le mec pensait une brique,
le mec le développeur pardon, et pensait une seule brique,
en fait il en a 50.
Et là il se dit, mais attends, et moi si j'étais au courant
de faire, mais c'est 40 que j'aurais mis en story point,
c'est pas 2.
Donc oui j'ai besoin d'aide là, j'ai besoin.
Donc moi ce que je veux dire par là, ce planning poker,
évidemment on a compris que c'est une estimation,
que c'est pas pour les bonnes équipes,
c'est par Jean-Claude, etc.
Mais il y aurait quand même un décalage, j'imagine bien que
si je l'ai vécu, donc c'est arrivé.
La personne disait 2, pour quelque chose
qui valait à son niveau, qui valait 40,
ça semblait guet. Il y avait trop de choses à découvrir en même temps.
Le project manager, quand tu vas le voir,
et tu lui dis ou même le Scrum Master,
tu vas le voir, tu lui dis, vous savez,
ce qu'on a estimé lundi, en fait,
ou vendredi dernier pour le spring à venir,
on avait dit 2, en fait c'est 40.
Mais il va le prendre hyper mal,
mais c'est déjà vécu, enfin c'est déjà vécu.
Mais attendez, je comprends pas.
Mais Miquel, ta solution est overkill, voilà ce qui arrive.
Alors que pas du tout, pas du tout.
C'est juste que la personne à ce moment-là, elle n'était pas au niveau
de faire ce genre de projet. Donc évidemment,
moi ce que j'aime c'est former,
j'adore, mais les devs je suis toujours en contact avec eux,
je les adore. Mais,
ce que je veux dire là, c'est que dans beaucoup de projets,
le planning poker a ses valeurs,
quand tout le monde
a le même niveau et la même compréhension du sujet.
Là évidemment, c'est génial comme truc,
parce que ça va très vite, on a l'institution.
Mais dès qu'il y a un décalage de niveau énormissime,
énormissime,
là il n'y a plus de problème.
Hier, en conférence, quand je donnais une conférence, on me disait
ouais, moi je le mets dans mon repository,
c'est un détail technique, on s'en fout, mais
je lui dis, mais non, il doit être là. Et là, il fait,
attends, mais t'es en train de me refaire tout le projet, là, je fais, bah ouais.
Ah mais j'avais pas vu ça comme ça, c'est vrai que ça a du sens.
Et donc en fait,
moi ce que j'ai voulu faire par ce projet,
c'est, écoutez, on ne va pas en poker planning,
parce que de toute façon, ça va être insensé, ce que vous allez dire comme
comme chiffre, parce que c'est pas ce que vous avez fait
dans les autres entreprises. Là où il y avait
peu d'élitisme et peu de tests,
peu de trucs, etc. Vas-y on code, et c'est bon, ça marche.
Là, on va très très loin.
Ça veut dire qu'on était
vraiment dans des zones,
il y a des refactoring toujours, on ne mettra pas plus tard,
c'est vraiment, ça allait très très loin dans
l'objet.
Et donc, il fallait les accompagner.
Et pour ça, il faut des réunions qui durent peut-être une journée
pour une feature. J'accompagne vraiment les développeurs pour chaque feature.
C'est ça que je veux dire, donc c'est pour ça
que le poker planning, le planning poker, pardon,
de bruit en blanc comme ça,
c'est trop dur pour quelqu'un,
pour un enfant, entre guillemets, qui découvre
tout un tas de montagnes de développement,
de pratiques qu'il n'ignorait avant. Il peut pas chiffrer ça,
c'est pas possible.
Il ne sait pas ce que c'est.
C'est ça, Michael.
Michael, Jean-Pierre, pendant.
Moi, ça me...
Je vois
une partie fondée dans
en fait, le moment,
je vais aller au bout de ce que je veux dire.
Je reviens sur l'estimation relative,
ainsi que comment on mesure la
vélocité. C'est-à-dire que
on ne devrait pas, je mets
en le conditionnel, ça suppose que
il y a le mindset, etc.
Mais on devrait avoir aucun problème à ce que
on est estimé 2
et en fait, ça prend 3 itérations.
Ça te dit juste que notre vélocité,
elle est de
2,2 tiers de points
par itération.
Et du coup, en fait, il n'y a pas ce problème-là,
c'est à ce contexte-là, parce qu'en fait,
on s'est lancé sur un truc qu'on savait pas.
Maintenant, quand je vais le comparer,
une story future,
parce qu'effectivement, on en revient sur, c'est pour ça qu'elle est rapide,
c'est que même sans imaginer tout ce qui est derrière,
on arrive à faire la coopération, c'est que
au pif, le fonctionnel, il est quand même plus
au moins compliqué, a priori on va toucher
à beaucoup d'endroits, pas trop, ou simplement, je ne sais pas
où je vais, mais c'est un des critères qu'on met dans les points,
l'incertitude, le risque, etc.
Donc en fait, on a quand même les outils,
encore une fois quand on le fait bien,
et du coup, en fait, on compare
juste, et après, c'est la réalité,
une manière très empirique qui nous dit le temps que ça apprend réellement.
Maintenant, là où je te rejoins, c'est
parce qu'effectivement, dans l'histoire que tu cites,
tu arrives encore de projet.
Et là, on change finalement le niveau de décision.
Ah non, c'est un projet de centre-hatch.
C'est un projet vraiment à ce moment, mais du coup,
l'équipe existait déjà.
Oui, mais tu arrives avec un certain niveau
de contexte technique, ce que j'entends,
dans ce que dit Jean-Pierre.
Voilà, c'est ça, exactement.
Donc c'est-à-dire que finalement,
on s'attend à avoir une forme de continuité
justement dans cette vélocité,
dans l'habitude que les points ont comme valeur,
qui est cassée, mais quelque part, est logique.
Parce que finalement,
dans les pratiques que tu apportes,
tu apportes pas du tout le même definition of don,
quelque part.
Donc du coup, effectivement, il faudrait avoir la maturité
de prendre du recul et de se dire,
ok, on change un peu l'équipe,
il y a Michael qui rejoint l'équipe de personne,
donc on s'attend à ce que la vélocité,
elle fasse pas un changement monstrueux,
elle va pas être divisée par 10.
Par contre, attention, on va pas du tout avoir
le même niveau d'exigence,
parce que la vélocité va falloir qu'on la remeusure
à nouveau et qu'on la prenne pas comme
quelque chose de fiable pour faire les prévisions.
Mais je reviens toi, effectivement,
il y a toujours quand même ce côté-là de...
Ben oui, bien sûr qu'on va dégrouer des trucs
au fil de l'eau. Donc là, il y a le cas particulier
où il y a une personne qui est à côté et qui peut le pointer
du doigt, donc finalement, c'est cool.
Mais, sur le fond, on devrait le dégrouer
au fil de l'eau. Ben c'est pas que c'est plus gros
que ce qu'on a prévu, c'est qu'en fait,
les points ne représentent pas ce qu'on avait en tête,
et c'est bien pour ça qu'on utilise des points,
justement, pour qu'on ne les utilise pas aux heures.
Du coup, comment tu gères le cas où ça arrive
tout le temps, ces trucs-là ? C'est-à-dire, assez bien,
quand sectionnel, quand sectionnel, quand J2 est 40,
évidemment, des bonnes équipes qui se disent agile
devraient accepter ça.
Il faut dire, écoutez, on a merdé sur ce coup-là,
mais quand ça arrive tout le temps ?
Non, on n'a pas merdé. Excuse-moi, Michael,
on n'a pas merdé, on a appris. Oui, on a...
Non, non, oui, dans ce sens-là.
Tu vois, non mais attends, je suis révélateur
justement d'un état d'esprit.
Le simple fait de dire, et encore moi,
je vais juste témoigner hier.
Hier, moi, j'ai un témoignage très récent,
tu vois, bientôt 20 ans d'expérience,
Craftman jusqu'au bout des doigts.
Mon PEO, il y a 2 semaines,
me demande, tiens,
j'ai telle story, combien ?
Alors déjà, je dis, estime-le s'il te plaît.
Je dis non, je ne vais pas te l'estimer,
je vais de le budgetiser.
C'est...
C'est une nuance qui pour moi est importante.
Parce que finalement, il ne comprenait pas que les estimations,
c'est faux. Alors que tout le monde comprend qu'un budget,
c'est jamais respecté, donc c'est bon.
C'est monsieur, oui. Donc, j'ai dit,
c'est un budget.
Je lui ai donné 6 jours de budget pour la story,
d'accord ? Mais il est dire qu'on
l'a pitié, on l'a détaillé
à peu près une minute la story, d'accord ?
Il y a tout le processus, le X-design passe par là,
on découpe en tâche
26 jours.
Il m'a fallu quand même un petit moment
pour me dire, non, c'est pas que t'as merdé.
C'est pas juste que t'as merdé.
Il y a des trucs que tu aurais pu un peu mieux anticiper.
Mais quand tu es sur un facteur 5,
c'est sûr que tu es vraiment mauvais,
et je ne pense pas que ce soit mon cas, en tout cas,
pas sur ce coup-là.
Soit c'est que tu n'avais pas la même
préconception des choses. Et effectivement, on y
aurait peut-être chissant bien, dans ma tête, c'était
vachement plus simple que ce qu'il y a eu à faire
finalement. Mais tu vois, ce simple
déclic de dire,
je oses mettre un chiffre,
et après je prends le risque, qu'il soit pas bon.
Et d'ailleurs, finalement, mon PO
m'a même pas engueulé sur ça. C'est moi qui me suis
mis la pression tout seul de me dire, mais
tu vas passer pour un con. Par rapport
à l'image que je me fais moi-même de ce que
les autres attendent de moi. Donc tu vois qu'on peut
se la pourrir tout seul la vie. Il n'y a même pas besoin
qu'un PO te fâchie,
pardon, qu'il te mette la pression.
Il y a un point qui est important que je parle
dans l'article, c'est qu'en fait, ça crée
mauvaises ambiances dans l'équipe quand tu sais
que la personne, elle met deux devant toi,
un développeur qui ne connaît pas ces sujets-là,
te met deux devant toi, t'as deux choix. Soit
tu l'arrêtes tout de suite et tu dis, attend, et là
on part dans une discussion technique, évidemment,
on se fait couper au bout de 1 minute.
Soit on la se faire,
on la se faire.
Et après on va le voir, ce que je faisais en général.
Au début je me faisais couper, après j'ai compris,
après j'allais le voir. Et je lui dis, tu sais
ce que tu as mis en deux, je peux te montrer,
c'est du vin que tu feras.
Je t'assure c'est du vin. Et là,
tu es en train de te brûler les doigts,
là tu mets deux, mais tu ne respecteras jamais
deux, c'est pas possible. Même moi je ne le fais pas en deux,
c'est pas possible. Je ne le frappe pas en deux.
Et quand ça arrive une fois, alors la personne
se dit super, j'ai envie de comprendre, etc.
Quand ça arrive tout le temps,
la personne se fait cataloguer pour quelqu'un
qui ne s'est même plus estimé auprès.
Et évidemment ça arrive aux oreilles du
product manager, etc. Et on se dit, je ne comprends pas.
Je vais en entendre un prénom, Bruno.
Il me dit que c'est
à chaque fois c'est deux, mais en fait à chaque
fois c'est 20. Mais c'est quoi le problème avec lui ?
Bon bah d'accord, on va le virer, c'est ce qui s'était passé.
Parce que la personne pense qu'elle n'est pas efficace.
Non en fait, c'est juste qu'elle n'est pas formée
sur ces pratiques-là. Elle venait d'un domaine
où il n'y avait pas cet élicisme, ou mon code
comme décrade et tout, c'était nickel,
et on met en proie qu'il y avait 40 bugs, mais ça passait
bien. Et là, ou un truc où tu ne veux pas
de bugs dans un gira pendant un an,
c'est
énormément le gap à faire. C'est pour ça
que moi, pour éviter cette mauvaise ambiance,
je préfère. Et pourtant, il me remerciait
parce qu'il apprenait énormément de choses devant
le tableau blanc. C'est un challenge.
Comment tu imagines le truc ? Il décide moi
juste sans aller dans le détail, il décide moi au tableau.
Et là, tu as pensé à ça, alors attends, il y a un truc
que tu as oublié. De une, c'est quoi ? Ah, alors attends,
laisse-moi réfléchir. Ils étaient comme ça devant le tableau.
Ça apporte une communion entre les devs, une vraie
discussion, ce qu'on n'a quasiment jamais
pour des pratiques même qui se disagent, chacun dans
son coin général, surtout quand l'open space est de 5,
6 développeurs voire 10. Là,
il y a une communion avec tout le monde et on se dit
« OK, comment on va réussir ? Est-ce qu'on met
cette chouette dans le sprint ou pas ? Aussi fine qu'elle soit,
évidemment, des coupées, etc. Est-ce qu'on la met ou pas ?
Est-ce que chacun, et après on assigne, on a
passé dans ce sprint-là parce qu'il y a beaucoup
de valeur ajoutée sur ce sprint qui est capable
de l'affaire en temps de temps. Et là, avec
toutes les exigences qu'on a listées, tu dois
de la pression et end-to-end, et unitaire, et
truc, et le domaine de juvent design, et des coupées,
et le dry, plein de trucs à respecter, qui est
capable de faire ça ? Si on en vient
et dit « écoutez, on pensait tous deux,
mais en fait c'est 20, là on arrive
en sprint planning et on dit « Mesdames, messieurs,
c'est du vent ». Tout le monde est content,
bon humeur, et là on a une estimation
qui est plus proche de la réalité. Ça va
alléger la pression sur les développeurs,
ils vont être beaucoup moins en pression,
parce que là ils vont dire « Putain, j'ai du vent, j'ai le temps
déjà d'apprendre des trucs ». Mais au moins, c'est à leur vitesse.
C'est quelque chose qui m'aurait pris 5, parce que moi j'ai
l'habitude de faire ces trucs-là, eux peuvent se permettre
de vendre, et c'est normal, et après plus tard ils font
du 5. Mais... Vas-y, vas-y,
non, je vais...
Tu as mangé la time box d'une minute,
je vois JP qui dote de l'indicateur.
Non, j'ai envie de rebondir,
parce que c'est aussi
pour respectif, c'est parce que
dans l'équipe, tout le monde
n'est pas au même niveau,
je sais pas, c'est potentiellement
au même niveau, ou simplement
pas le même
talent, ou simplement la même maîtrise
d'une techno, effectivement,
ou des personnes qui arrivent sur le projet,
forcément, donc elles aussi fonctionnelles à
prendre en compte, à prendre en main, etc.
C'est pour ça aussi qu'on met des points,
c'est justement parce que si on commence à mettre
du temps, bien sûr que ça prend pas le même temps
à quelqu'un qui maîtrise déjà tout, qui est
au top sur la techno, et qui en plus
est vraiment bon intrinsèquement
vers ce qu'il y a quelqu'un qui débarque.
C'est pour ça qu'on met des points, parce que ce qu'on va
mesurer, c'est l'équipe au global,
et ça c'est plutôt stable,
et tu vois, j'ai toujours du mal
quand on parle, quand on parle, tu dis, ben non, moi
ça serait simple que si je le fais, mais si c'est toi, c'est 20.
Là, ça veut dire qu'on n'est pas en train de penser en point
comme on devrait penser en point. T'as tout compris, mais la réalité
de tout, je suis d'accord, parce que toi, t'as un
Scram Master puriste, on va dire, dans l'équipe, et je pense
que tu le fais très bien. La plupart des Scram Master
que j'ai vu dans 8 boîtes différentes, ils pensent en temps
derrière. D'ailleurs, je leur ai fait une échelle de temps avec
des stories points, un mapping genre. Parce que derrière
c'est un point, le Product Manager,
j'ai discuté longtemps avec un Product Manager
dernièrement, il me dit, Michel,
moi c'est mignon tout ce concept de points, etc.
Mais il me faut un truc concret, là, combien de temps
j'annonce aux sponsors, combien de temps.
Et comment tu fais Jean-Pierre alors ?
Comment tu fais pour faire cette conversion ? Parce que oui,
bien sûr que le Project Manager fait cette conversion.
Comment tu fais pour l'aider à faire une projection intelligente ?
C'est à moi ou ça qui tu te branches ?
Oui Jean-Pierre, oui, Jean-Pierre, comment tu fais ?
Parce que moi, ces questions-là, d'ailleurs, on les a posées
très clairement lundi,
j'ai donné une entreprise,
et elles étaient vraiment dans des questions du...
Mais oui, mais tu sais quand nous on lance un projet,
en fait, on demande un budget.
Donc du coup, comment on fait ?
Et en gros, ma réponse c'était,
tu lis, eJ planning and estimating
de mycon, tout est dedans.
Il t'explique, tu fais des estimations
relatives, tu fais des points,
tu mesures ta velocité, si tu ne la pas
parce que tu démarres, oui, du coup,
tu vas bricoler avec une velocité approximative
en faisant le détail de tâches et le calcul en points,
mais c'est juste pour le démarrage.
Et oui, tu rajoutes, et tu fais comme à l'ancienne,
tu rajoutes 50%, si tu es dans un mode
ou de toute façon, tu dois tenir une deadline
et que le scope il n'est pas négociable.
Mais parce qu'on est dans une logique où
on fait la différence, ok,
ce qu'on veut, ce n'est pas une estimation, c'est un engagement.
Parfois, c'est ça le contexte.
Et toi, du coup, le code d'assertitude,
tu le vois entre ce que l'équipe est capable
de faire et la réalité de ce qui se passe,
tu le vois converger au bout de combien de sprints
dans ton expérience Jean-Pierre ?
Euh...
En fait, il y a un peu de critères.
Il y a déjà combien de sprints, effectivement.
Et en général,
8, c'est déjà pas mal en fait, quand tu commences
à avoir 8, donc ça fait 2 mois,
4 mois, ça fait 4 mois, ça fait 2 semaines.
Et c'est normal en fait,
ça suppose aussi que l'équipe soit un peu prestable,
qu'elle soit déjà formée dans les différentes étapes
d'équipe.
Et ça suppose aussi qu'elle ne soit pas en dans de si,
parce qu'on a aussi régulièrement le...
En fait, on a du mal à faire du délivrer,
il y a en fait un sprint ou deux sprints sur 3,
bah en fait, on fait plein de bêvres,
on dit que c'est donne, mais il n'est pas mettant prod.
Le sprint d'après, on le met en prod, et donc,
on ne livre presque rien, même si par contre, on livre de la valeur.
Et donc du coup, c'est une grosse dente,
donc là, forcément, donc il y a un peu ces deux critères.
On a combien d'hysteriques pour faire la moyenne,
et il y a aussi fianc équalécaire type.
Est-ce que, globalement, à chaque iteration,
on fait entre 15 et 18,
donc globalement, la moyenne est doit être un peu préfiable,
on alterne entre 5 et 30.
Là, du coup, ça compte dans le cas
de notre certitude, et puis il y a aussi le temps
qu'il reste forcément, si on est à l'unitération de la fin,
on va espérer qu'on est beaucoup plus précis,
si on a 6 mois de travail.
Comment tu expliques du coup au manager ?
Bah non, finalement,
on avait fait tout notre...
dire là, là, on est vraiment
sur du côté humain, sur du côté management,
parce que le coût de... en général,
au début, on est plutôt tendance à être optimiste,
en tout cas, c'est ce que j'ai pu voir,
en tout cas, c'est peut-être un biais très personnel,
mais en tout cas, les devs, je remarque, sont souvent
un peu très optimistes.
Comment managerialement parlant,
parce qu'on manège aussi son manager,
c'est pas que les managers qui managent, c'est super donné.
Comment tu gères ton manager,
ton boss, ton pio,
ton ce que tu veux, et quand tu vas lui dire,
bah c'est bon, on a appris maintenant,
et en fait, ça va être 4 fois plus.
En fait, du coup, c'est qu'il faudrait...
Alors, déjà, c'est ce que je dis,
si on est dans une situation où ce qu'on nous demande bien,
il faut être clair, ce qu'on nous demande,
ce n'est pas une estimation, c'est un engagement.
Encore une fois,
et je ressors encore une fois,
Jay estimating and planning de mycon, il explique,
il y a des stratégies, il faut que le permette soit négociable.
S'il n'est pas négociable, on se cas,
il faut prendre de la marche comme un projet ancienne,
mais en fait, il n'y a pas de secret, on veut toujours un projet logiciel.
Éventuellement, le top, c'est de mixer un peu des deux.
Et surtout, et là, c'est la différence
par rapport au projet ancienne,
c'est qu'on va le communiquer.
C'est qu'à chaque intération, on apprend,
on a une velocity qui est plus fiable, on voit comment on avance,
on réestime et on tient des choses au vu de ce qu'on a appris.
Et donc, on remet un jour, et effectivement,
on est censé donner une estimation qui est une fenêtre
avec le code d'incertitude.
Et finalement, comment on emmène ce changement de mindset ?
Parce que là, la réponse,
tu n'as pas un peu à côté, je ne te dis pas comment sortir le changement,
je dis comment le faire, penser autrement.
C'est en faisant vraiment de l'incrémentale.
Parce que du coup, tu vas construire de la confiance.
C'est quand, quand tu dis, toutes les deux semaines,
regarde là, il y a un vrai truc concret,
il est sorti, il est là, il tourne, il apporte de la valeur.
Ok, c'est le truc, il est totalement partiel,
on ne va pas le mettre sur le marché, mais il y a vraiment quelque chose.
Il est en plus, il est là.
Là, il y a une confiance qui se construit.
Et du coup, le mec, il va commencer à te faire confiance
qu'à la bout de la chaîne, on n'y sera aussi.
Qu'est-ce que tu en penses, Michael ?
Est-ce que ce n'est pas finalement dans les écosystèmes que tu as pu voir ?
Est-ce qu'il y avait cette confiance là ?
Moi, j'ai eu la chance, la dernièrement,
donc c'était pour un grand groupe, mais c'était en mode startup.
C'est-à-dire, c'est un projet from scratch.
Donc tout le concept, quand j'ai écrit cet article,
ça venait de, je partais de ce contexte là.
C'est vraiment un projet from scratch.
Ce n'est pas quelque chose que j'aborde directement.
Donc j'ai connu tout cet article chiffrage,
engagement à prendre,
enfin, il est considéré comme un engagement, etc.
Ça passe très, très, très mal.
On a eu de la chance, ce n'était pas passé, mais ça passe très...
Enfin, au début, je l'ai contrôlé leur chiffrage.
Au début, ils voulaient tout en trois mois.
Je me dis que ce n'est pas possible.
Tu bâilles fonds des...
Enfin, tout en initial aussi gros que ça,
en trois mois, ce n'est pas possible.
Donc déjà, tu les sens un peu frillé,
tu les sens déjà sur la défensive dès que tu vas négocier
une rallonge.
À partir de là, ils nous disent d'accord,
maintenant, estime-moi tout ça.
Donc ils attendaient une estimation,
et forcément, elle était fausse,
l'estimation, forcément, elle était fausse.
Parce que, un, j'avais pas l'équipe,
j'avais pas encore accruté les personnes,
donc ça dépend.
Est-ce que tu recrutes John Skeet
ou un junior ?
Ça dépend.
Tu... c'est pas la même chose.
Moi, tout ce que je sais, c'est que derrière,
on est toujours attendus par cette notion d'engagement,
et que en entreprise,
l'estimation n'existe pas,
ce mot-là n'existe pas,
à part dans les bonnes entreprises.
J'en ai pas connu.
Pourtant, j'ai fait la plupart des grands groupes.
Mais j'ai pas connu,
le mot estimation est égal à engagement.
Mais, Miquel, juste,
je suis pas bien persuadé
que les grands groupes
soient les écosystèmes les plus favorables.
Exactement.
Mais c'est en même temps,
là où il y a le plus de développeurs aussi, en même temps.
Je dis pas que c'est pas là où il y a le plus de développeurs.
Je dis que c'est pas forcément
les écosystèmes les plus favorables, surtout.
Je suis d'accord.
Parce que moi, les écosystèmes que j'ai connu
dans lesquels c'était favorable,
c'était des petites trucs.
Oui, évidemment, oui, bien sûr.
Mais dans ce cas-là,
ça regroupe pas la majorité aujourd'hui des devs de France.
La majorité des devs de France
qui ont envie de faire du craftmanship,
qui ont envie d'avoir une meilleure agilité
dans leur équipe, etc.
La plupart sont dans les grosses boîtes.
Après, moi, ce que je te dirais aussi,
c'est que quelque part,
c'est aussi le rôle peut-être
du Scrum Master en mode un peu dégradé
dans ce genre d'organisation.
C'est d'essayer de construire une bulle d'agilité.
Moi, c'est le sentiment que c'est ce que j'avais parfois.
Et on peut en débattre.
Est-ce que c'est vraiment,
est-ce que c'était vraiment mon rôle au Scrum Master ?
Est-ce que je n'aurais pas dû plutôt être le coach agile
qui fait évoluer la boîte ?
Mais voilà, je me dis juste,
faisons en sorte qu'il y ait une bulle
où déjà, cette équipe peut y aller.
Et finalement, peu importe comment on estime,
on est bien avec Otsu et on se débrouille
pour gérer ça.
Et d'une certaine manière,
certains diront que c'est ce qu'ils attendent
du rôle de manager.
Et aussi souvent, il n'est pas forcément assumé.
Parce que je n'ai pas l'impression
que ce soit ce qu'a vécu Michael.
Au contraire, je n'ai l'impression
que le Scrum Master,
même si je l'adorais personnellement,
humainement, il n'y a pas de soucis,
mais c'était des personnes qui te rassaient des cours.
Le problème dans le monde du Scrum Master,
c'est qu'il n'y a pas des GP partout.
GP passionné, la preuve,
c'est que tu fais des vidéos de super, des trucs, etc.
La plupart des Scrum Masters que j'ai connues,
je pense, c'était peut-être,
évidemment, je ne l'ai pas cité,
mais je pense qu'on s'était qu'un.
Non, pas de soucis.
Non, pas de soucis.
Évidemment, il n'y a pas de soucis.
Il y a moi, je l'ai entendu.
Ils sont pas ces Scrum Masters
pour beaucoup, sans plaisanter,
parce qu'ils n'aiment plus le dev.
Ou alors, c'est parce que c'est un métier à la mode, etc.
Le nouveau chef de projet ?
Moi, ça me faisait mal au coeur.
Moi, ça me faisait mal au coeur qu'en réunion,
j'en connaissais 4 fois plus
sur l'agilité que le Scrum Master.
Il y avait un problème,
il y avait un décalage.
C'est pas possible.
C'est-à-dire que même,
enfin, c'est pas normal que ce soit moi
qui anime sur une planning, par exemple.
C'est pas normal.
Chaque fois, je reprenais sur les mots,
parce qu'on partait en cacahuètes à chaque fois.
Et il n'y a pas,
et je n'ai pas trouvé encore
de super Scrum Master
formé et passionné.
Parce que pour moi,
c'est un métier de passionné.
Et le problème aujourd'hui,
c'est que, comme il y a beaucoup de projets
qui se veulent agiler, etc.,
c'est un métier
où il y a une pénurie.
On veut un Scrum Master.
On veut, ça, on veut.
Et tout le monde le devient aussi facilement.
Aujourd'hui, quelqu'un,
il passe une certif Scrum,
il est certif Scrum,
c'est rien.
C'est des cacahuètes.
Derrière, il y a énormément de choses.
Il y a plein de livraires, comme Jean-Pierre le dit.
Il y a une éducation,
des cultures, certaines boîtes
qui se sont faits différemment.
Il y a des mix des fois,
des Scrum 4 bands, des trucs, etc.
Les gens ne sont pas curieux.
Moi, ça me faisait de la peine.
Quand j'envoyais,
mes derniers Scrum Masters,
j'envoyais un lien.
Lis-moi ça.
Regarde, ils pensent l'inverse de toi.
Non, je ne lirais pas, Michael.
Je ne lirais pas.
Mais pourquoi ?
Ça prend 5 minutes à lire l'article.
J'ai juste envie d'avoir ton avis.
Non, Michael, je ne lirais pas.
C'est des gens,
la plupart, sont bornés.
Ils pensent bien faire.
Et au final,
ils te détruisent un projet.
Je sais que le mot est assez puissant,
mais c'est une vérité.
Parce qu'à la fin,
ils t'attendent le tournant.
Michael, regardez la velocité.
Vous êtes chez là,
vous êtes tombé là.
Je fais d'accord.
Mais on est en même temps le seul projet
de toute la tour
de 1000 personnes qui marchent
et qui en proident dans les délais.
Ouais, mais regardez,
en velocité, vous êtes là.
Donc, est-ce que ça,
ça protège l'équipe ?
Je pense plus que ça.
Ça nuit à l'équipe.
Parce que justement,
les mauvais éléments,
quand je dis mauvais,
excusez-moi, c'est
les éléments juniors
qui ont envie de progresser.
Ils n'ont pas l'occasion
de progresser.
Tu me dis de faire un test unitaire,
mais t'es malade,
t'es en regard à la velocité.
Moi, on m'attend que ça remonte.
Moi, je code comme je faisais
dans ma mission précédente.
Michael, désolé.
Évidemment, ça passe pas
le code review.
Les mauvaises ambiances,
je ne vous dis pas.
Les fights et compagnie.
Mais donc, c'est un problème
beaucoup plus profond
qu'on peut l'imaginer.
Et que, dans la théorie,
évidemment, tout se passe bien.
Mais voilà,
c'est dans les petites structures.
Et en général,
dans les petites structures,
la plupart des gens sont déjà passionnés
parce que pour aller dans les petits structures,
il faut être passionnés.
Quand tu vois une petite structure,
c'est que tu as aimé déjà
avoir un moindre salaire
par rapport à un grand groupe.
C'est une vérité
dans beaucoup de cas
en ville de France.
Donc, c'est vraiment,
ça regroupe vraiment
une communauté de passionnés.
Scrum Master est un métier
aujourd'hui qui fait rêver
beaucoup de monde,
mais dont la majeure partie
ne devrait pas le faire.
Ils n'ont pas la culture agile
et ils ne sont pas passionnés.
Je te propose Jean-Pierre,
que ce soit le mot de la fin.
Comment tu as envie de réagir
sur cette dernière
reprise de parole de Michael ?
Ça me fait penser
à un article que j'ai hanté
depuis longtemps,
que j'ai pas encore osé
vraiment écrire
sur la question du...
Est-ce qu'il vaut mieux ?
Qu'est-ce que c'est
quoi le pire
entre ne pas avoir
de Scrum Master
et avoir un mauvais Scrum Master ?
C'est un peu le débat.
Mais c'est intéressant.
Ok.
Merci à vous de les gars.
Jean-Pierre,
si on veut en savoir plus
sur ce que tu fais,
on peut venir où ?
Toujours sur www.mc.n.e.
ou sur ma chaîne YouTube
où je vous présente
Scrum Life.
Super.
Michael,
où est-ce qu'on peut venir
voir un petit peu
tes blasphèmes
et tes billets d'où ?
Vous pouvez aller
quasiment
sur www.willcomecompany.com
en même temps,
vous voyez ce que je fais,
ce que je propose comme prestation
et en même temps,
il y a un lien
vers mon blog,
il y a l'intérieur.
Donc c'est www.willcomecompany.com
et voilà.
Donc j'essaie de faire
plusieurs podcasts
au fur et à mesure aussi.
Ça marche.
Merci à vous d'être venus.
Car t'as toi cher auditeur,
on a vraiment besoin
de ton feedback.
Qu'est-ce que tu as pensé
de ce format ?
C'est un nouveau format
qu'on explore.
J'aimerais vraiment savoir
est-ce que ça t'a plu ?
Est-ce que c'était amusant ?
Est-ce que c'était chiant ?
Est-ce que tu en veux d'autres ?
Si tu en veux d'autres,
sur quel sujet ?
Alors évidemment,
pour que ce soit fun,
il faut que tu me trouves
des sujets un petit peu clivants,
tu vois,
et si possible,
à contre-courant
et j'irai chercher
des gars qui ont envie
de participer.
À demain.