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.
Salut !
Aujourd'hui je te propose qu'on parle de l'adaptation, en fait c'est même toi qui m'a amené le sujet
puisque tu viens d'être papa pour la deuxième fois, moi je m'apprête à être papa dans quelques mois pour la cinquième fois.
Et c'est vrai que les enfants c'est quand même un truc fantastique pour tester notre capacité d'adaptation.
Et tu me disais c'est quand même dingue quand on regarde bien que tu partais de ce truc là de dire
on arrive à l'heure en fait globalement et pourtant il se passe plein de choses qui...
Comment ça se fait qu'on arrive à l'heure, comment ça se fait qu'on arrive à gérer des enfants ?
Qu'est ce que ça t'évoque ?
En plus j'ai dû me faire cette réflexion là en cours du visant justement.
On a un peu ce culte qui nous vient souvent avec le waterfall, avec la manière traditionnelle de faire.
On va planifier quelque chose et c'est ça qui va arriver.
En fait dans la vraie vie mais ça arrive rarement...
Jamais comme ça en fait.
C'est-à-dire que les gens arrivent à l'heure pas parce qu'on a planifié exactement tout ce qui allait se passer avant ça
mais parce qu'on passe notre temps à s'adapter.
On part jamais exactement à la même heure.
Il y a plus ou moins de voitures sur la route.
Parfois il y a des feux qui tombent mal, parfois ça va vite, parfois ça va bien.
Et puis même quand on arrive en retard ça gêne pas les gens d'ailleurs.
Quand c'est pas pile poil l'heure, au final tout le monde s'adapte.
Il y a une règle comme ça qui est de dire si on se donne plus de temps avant la deadline
alors on va passer plus de temps à bosser dessus.
Moi je vais me dire ça c'est pas un travers humain en fait.
On le présente c'est très comme c'est un travers humain.
Tenez en compte que vous faites votre gestion de projet.
Je vais me dire c'est l'expression même de comment la vie fonctionne.
C'est-à-dire que c'est l'adaptation ou trans.
Et si on a plus de temps on va marcher plus lentement et on arrivera à l'heure.
Et si on a moins de temps on va courir un petit peu et on arrivera à l'heure.
Alors ça c'est une analogie que je trouve vachement intéressante.
Et là il y a un lien je me demandais comment on allait passer du berceau à l'entreprise.
Et là tu m'offres ça sur un plateau parce que dès lors que je me suis retrouvé dans la posture d'encadrer des projets.
D'avoir des équipes à gérer et dans la gestion j'entends aussi à me motiver.
J'ai me retrouvé conscient de cette règle qui est que quand tu donnes un espace temporel
il sera consommé de toute manière.
Je suis toujours partagé entre la raccourcir pour stimuler
parce qu'il y a quand même une part de stimulation dans le fait de se fixer des échéances en fait.
Et laisser à ses temps pour que le travail soit bien fait.
Et c'est un compromis que j'ai toujours énormément de mal à trouver.
Et j'en ai fait encore l'expérience il n'y a pas très longtemps.
Un truc où la deadline nous paraissait large.
Finalement plein de choses sont arrivées au milieu.
Et c'est pas qu'on se soit mis à marcher plus lentement.
C'est juste qu'il y a des choses qui sont arrivées au milieu et qu'on a accepté.
Et du coup je me dis mais finalement on a encore pris quelques jours de retard sur la livraison.
Ce qui est frustrant parce que tu dis un truc qui nous paraissait large.
Même là où on se donne de la marge on n'y arrive pas.
Je me suis posé et en même temps si on avait serré trop la vis.
Je trouve que c'est mal saint aussi pour l'équipe.
Comment tu trouves toi ton entre deux ?
D'abord est-ce que tu es conscient de ça en tant que Scrum Master dans les équipes que tu amènes ?
Est-ce que tu as n'a que tu vas ou spiller pour leur mettre un peu la pression
pour qu'il en sorte un peu quelque chose ?
Parce que sans pression il ne sort rien de l'équipe.
En fait tu ne peux pas performer.
Oui ça dépend d'évidemment de comment on fonctionne mais typiquement en Scrum.
La pression entre guillemets c'est un élément clé.
Alors évidemment ça ne va pas porter ce nom là.
C'est plutôt le Commitment qui est clé dans Scrum.
Par contre l'élément fondamental et c'est là souvent que Scrum se fait détourner
c'est que ce Commitment il doit être fixé par l'équipe.
C'est-à-dire que c'est elle qui va se le fixer même.
Donc on va d'abord parler du cas où l'équipe est dans une bonne dynamique et tourne bien.
En gros c'est juste comme ça que ça se passe.
On se retrouve en planning et l'équipe se fixe son enjeu.
Et souvent les mots que je dis c'est de dire on doit être capable d'y arriver.
Donc n'en prenez pas trop.
Mais il faut que ça soit quand même un tout petit peu challenging.
Il faut que les derniers jours d'intérations il y ait quelque chose qui monte.
On se retrouve ensemble sur le pont etc.
Voilà juste pas trop.
Il faut réussir à trouver ce bon équipe.
Voilà donc c'est un peu ça à la règle.
C'est juste l'intention.
Et comment tu les guides toi ?
Comment tu les guides là dedans pour trouver le challenging juste pas trop ?
De manière très simple en fait il y a plusieurs manières de faire le sprint planning.
Moi je ne fais pas les points en fait.
Chaque fois je rajoute une user story je leur dis alors est-ce que ça passe ou pas ?
Et si ça passe on en met une autre.
Et si le faux...
Tu le fais au gut en fait.
Alors le gut et si il ne se sent pas à l'aise de y arriver juste comme ça.
On fait les tâches techniques et on met du temps sur les tâches techniques.
Et on se projette et on se dit bah voilà premier jour de l'intération vous allez faire ça à priori.
Puisqu'évidemment c'est un plan sur la comète et on ajustera tous les jours.
Voilà au bout de trois jours on aura fini cette story là très bien etc.
Et voilà et après à force l'équipe a moins besoin de faire ça et ça roule mieux.
Et effectivement elle y va plus juste au gut comme tu dis.
Mais voilà celle qui doit se le fixer et qui apprend du coup quand elle se rend compte.
Voilà bah là oui c'était compliqué on en a pris trop.
Au contraire oui bah là du coup on a un peu d'irrévé on a fait d'autres trucs parce qu'on avait de la marge.
Oui bah oui parce que c'est eux qui prennent leur engagement donc c'est eux qui prennent leur recul sur comment ça s'est passé par rapport à cet engagement là.
Et le fait qu'il y ait des imprévus qui tombent bah ça fait partie de ces choses là qui se disent.
Ah non faut qu'on se garde de la marge parce que parfois il y a des choses qu'il faut qu'on prenne comme on estime etc.
Voilà il y a plein de choses.
Après on nous dit c'est quand même la vélocité pour en double check quoi pour vérifier bon.
Vous êtes sûr que là vous n'êtes pas complètement sous-engagé ou contraint vous n'êtes pas sur ambitieux.
Mais voilà c'est juste un check à côté c'est pas ça qui compte ce qui compte c'est que ils se fixent leur propre engagement.
Et parce qu'il y a plein de raisons derrière genre bah aujourd'hui on n'a pas le pro de la techno donc comment on fait sans lui bah on va peut-être moins s'engager.
Parce qu'en fait on va un peu plus galérer sur ce morceau de code ou celui de référent et nous on va...
C'était l'équipe qui tourne bien après tu as l'équipe...
Après voilà après...
Tu as le good case et le bad case.
C'est ça donc après équipe là...
Donc là il y a l'équipe où voilà où c'est...
Bah on va avoir tombé sur la notion de...
Bah en fait voilà faut réussir à faire marcher l'humain tout court parce qu'en fait c'est...
C'est même pas pertinent de dire comment comment on déroule le rituel de sprint planning si de toute façon les gens sont pas dans le trip quoi.
Il faut qu'ils en aient envie, il faut qu'ils s'impliquent.
Donc si de base ils sont en mode...
Non mais c'est bon là on prend les points de toute façon tout ce qu'on n'aura pas fini on les reportera et puis c'est tout.
C'est pas ça non ce qu'on veut c'est...
Dernier jour il y en reste une story et on se bat pour la finir.
Donc après voilà faut pas faire trop faut faire juste qu'il faut.
Mais faut qu'on aie ça en fin d'interression faut qu'il y ait vraiment...
L'équipe qui fait bloc et c'est aussi une forme de team building quand à chaque sprint les deux derniers jours il y a un vrai...
Vraiment quelque chose qui se passe dans l'open space dans toute l'équipe.
Là on crée du lien aussi.
Quand l'équipe se fait juste en mode c'est pas grave moi je fais juste mon code.
Et quand je dis mon code probablement qui parle bien que du code parce qu'il est développeur il va pas faire le reste il va pas faire le test etc.
Donc il reste bien dans son truc, zone de confort il se pose pas de questions.
Et puis tout ce qui n'est pas fini de toute façon ça sera reversé etc.
Il faut voir aussi ce qu'on dit l'environnement parce que aussi parfois s'il y a l'environnement qui implique ça.
Parce qu'en fait il n'y a pas de vision produit on veut juste une usine à délivrer sans réfléchir etc.
Voilà donc soit c'est l'environnement soit c'est qu'on est sur des personnes qui sont déjà finalement pas mal blasés.
Parce qu'on trouve ça aussi.
Personnes qui ont été usés, grillés et qui n'y croient plus ou qu'on peut en vivre.
Donc on cherche juste le confort de pas se prendre la tête et ça leur parle pas quoi un truc de...
On y va on se motive yo yo yo tout ensemble go go go !
Ça leur parle pas non non c'est bon quoi je sais comment ça se passe le manager il arrive il nous met un truc dans le dos.
Et à chaque fois c'est pour ma gueule c'est bon quoi.
Donc après on arrive sur... oui il y a des gens qui sont brûlés en fait.
Et dans les équipes qui mangent bien comment tu gères le repos parce que dans ce que tu décris cette espèce d'effervescence des derniers jours.
Après il y a forcément ça met forcément une espèce de tension ça consombe de l'énergie comment tu redémars derrière ?
Déjà il y a la fameuse... donc il y a une vraie coupure.
Clairement on revue d'itération et rétrospective avant de rembrier sur le nouveau sprint planning.
Donc ça déjà ça...
Et ça en général tu le fais quoi ? Tu le fais sur une journée ça ?
Si on l'est fait à la suite ça va être une demi journée après sur un sprint de deux semaines ça dépend évidemment de la durée du sprint.
Moi ce que j'aimais bien faire c'était revue d'itération en fin de journée.
Du coup la rétro le lendemain le matin, matin tard genre à 10h30 c'est aussi que l'équipe a tendance à arriver tard.
Mais voilà donc déjà il y a une forme un peu de mou jusqu'on se prenait finant toute la matinée pour ces 10h30-12h.
Et ce qu'on faisait aussi en plus c'est que le sprint planning n'était que le lendemain matin.
L'après midi était off dans le sens où on le passait sur des dojo, des formations, des échanges entre nous, des discussions diverses etc.
Ou souvent ce que les gens ils aiment bien dire du temps, innovation, des choses comme ça.
Et on se rend compte qu'en fait qu'on construit énormément pendant ces temps là,
ça permet aussi beaucoup d'actionner ce qu'on dit en rétro simplement.
Je fais parfois en rétro on dit faut faire ci faut faire ça.
Mais écoute t'as l'après midi, vas-y prends une heure, fais le truc, faut qu'on fasse un dojo,
ou on se dit qu'il faut orienter le backlog vers un truc mais on ne sait pas bien faire une investigation,
ça tombe bien, on a l'après midi, on fait l'investigation.
Et au début on faisait même ça en cours d'itération, c'était qu'une heure ou deux.
Et je n'ai vraiment à un moment, j'ai vraiment milité pour qu'on le fasse entre les deux iterations.
Après la rétro il y a un moment, pour qu'on soit vraiment en mode, là c'est bon, là j'ai pas de backlog en cours.
On peut faire n'importe quoi, il faut faire d'autres choses.
J'ai pas l'esprit qui va gabond et me dire il faut que j'amende sur mes stories etc.
Non c'est cool, en fait ce que tu dis c'est que ce temps de relâche,
je ne peux pas l'appeler de repos parce que ce n'est pas du repos au sens où tu ne fais rien,
c'est ce temps où tu stoppes la pression, où justement tu laisses le cerveau,
faire l'éponge, prendre ce qu'il veut.
En fait dans ces moments-là, c'est là que tu construis en fait quelque part,
c'est là que tu agrèges la amélioration, c'est là que tu digères vraiment le...
Ouais, comment dire, c'est là que tu t'améliores en fait, c'est là que tu grandis quoi.
Très concrètement, on construit une culture déjà simplement.
Là toi, quand je te dis les gens ils font du dojo etc.
Je pense que ce genre de pratique qu'on a pu avoir ont été clés dans la construction
d'une culture d'ingénieurs fortes qui apportaient ces fruits et qui a pu se propager
au fur et à mesure des turnovers, des gens qui s'en vont, des nouveaux qui arrivent.
Voilà, parce qu'on le dit non c'est important, c'est là, vous avez un temps libre,
il faut faire des choses etc. Parce que à chaque fois avant, les gens faisaient du backlog,
ils faisaient plein de trucs, ils disaient bah voilà, on a plein de choses à faire.
Et puis on ne les fait pas.
Au moins déjà il y avait un après-midi ça a aidé quand même.
C'est clair.
Bah écoute JP, je te propose que ce soit le mot de la fin.
Merci d'être venu aujourd'hui.
Avec plaisir.
Chers auditeurs, si tu ne connais pas encore JP Lambert, je t'invite à aller sur Youtube,
tu tapes Scrum Life ou JP Lambert et tu trouveras, je te recommande surtout si tu bosses en Scrum.
T'allais voir tout ça.
Et puis si tu n'es pas encore abonné à Artisan Developer,
eh bien je t'invite sur artisandeveloper.fr à rejoindre la communauté.
A demain.