Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Constantin Gué, Constantin Bonjour.
Bonjour Benoît, bonjour tout le monde.
Ravie de t'avoir aujourd'hui sur le podcast, est-ce que tu pourrais te présenter en quelques
mots pour ceux qui ne te connaîtraient pas ? Bien sûr.
Donc Constantin Gué, aujourd'hui je suis coach agile ou scrum master suivant les besoins
et j'ai un gros passé de développeur.
J'ai été développeur pendant 17 ans et don une grosse partie en frillance tout seul.
Le jour où j'ai intégré une entreprise courant 2013 je crois, ça a fait beaucoup
de changements pour moi puisque je devais travailler en équipe.
Et ayant travaillé tout seul et étant totalement autodidacte, je sentais qu'il me manquait
pas mal de choses et que j'étais pas forcément hyper performant tout ça.
Et c'est à ce moment-là le hasard faisant bien les choses que un de mes amis avec
qui je déjeunais me parle d'un coach qui était arrivé chez eux, travaillé dans une
grosse banque et qui leur avait parlé de scrum, d'agilité, tout ça.
Alors moi je ne connaissais pas du tout dans l'entreprise où j'étais, on ne connaissait
pas du tout non plus.
Mais ce qui m'en a dit m'a fait tilt parce que j'y voyais vraiment un cadre qui me
permettait d'améliorer mon processus, d'avoir un processus de travail déjà, ce que je n'avais
pas ayant travaillé tout seul pendant très longtemps, d'avoir un processus de travail
et donc de me sentir mieux dedans, de me sentir plus cadré.
Donc j'ai commencé à m'y intéresser, j'ai lu des livres, j'ai participé à des conférences
et puis ça m'a permis ensuite de pouvoir tester des choses dans l'entreprise où j'étais
avec la super équipe avec laquelle je travaillais.
Donc on a testé plein de trucs, on a fait énormément de bêtises bien entendu et puis
voilà et puis ça c'est, je me suis vraiment intéressé de plus en plus, j'ai passé
mes certifications et jusqu'à un moment où en fait j'étais devenu city-o de l'entreprise,
city-o Europe et en fait je faisais quasiment plus que le Scrum Master entre guillemets,
je m'occupais plus que de ça et voilà et à un moment j'ai eu une opportunité,
je m'entendais plus forcément avec la nouvelle direction de l'entreprise donc je suis pas,
j'ai posé ma démission, j'ai eu l'opportunité de trouver un boulot en tant que Scrum Master dans
une USN et je me suis dit ben ouais, bancaux faisons ça de toute façon, c'est ce que j'aime faire
aujourd'hui donc je suis parti là-dedans et puis de fin en aiguille, je me suis, j'ai commencé à
écrire des articles sur un blog, sur les sujets que j'apprenais en fait, sur les choses que j'ai
découverts, les expériences que j'avais, à peu près, c'est à peu près au même moment où Jean-Pierre
à commencé Scrum Life, ouais c'était ça, c'était le fin 2017 et donc moi j'ai découvert
quasiment tout de suite je crois, c'est pas le premier ou peut-être au deuxième épisode et puis j'ai eu
la chance de le rencontrer à Gilles Tour Paris si je me souviens bien fin 2017 et voilà et puis
comme il me connaissait un petit peu de nom parce que je répondais pas mal aux commentaires
et parce que moi ben voilà ça me permettait vraiment de grandir, d'apprendre des choses,
de confronter une expérience que j'avais pas forcément et un peu plus de terre à terre et voilà
et puis ça c'est, on a gardé contact jusqu'à ce qui m'interroge sur mon expérience du sprint
d'une semaine que j'avais avec des équipes à ce moment là donc c'était ma première vidéo
sur Scrum Life et puis on est resté encore plus en contact par la suite et jusqu'à travailler
ensemble sur Scrum Life et jusqu'à aujourd'hui travailler complètement pour Scrum Life à 100%
voilà tout en faisant bien sûr du conseil en continuant de faire du conseil en parallèle ne
serait-ce que pour garder un petit pied dans le terrain et pouvoir dire des choses pertinentes.
Ce que je trouve super intéressant c'est comment est-ce que finalement progressivement,
petit à petit par l'engagement que tu as pu y mettre tu es tu en as arrivé à changer
complètement de situation finalement en quelques années tu es passé de développeur ou voir manager
une des responsabilités à un faux preneur et consultant où tu redeviens quasiment
fri, une toute petite équipe quoi. Ouais complètement, complètement et aujourd'hui on me demande d'ailleurs
souvent si ça me manque pas le développement parce que c'est vrai professionnellement je
n'en fais plus du tout alors je reste à fermer de la programmation pour automatiser ma maison
ou les trucs comme ça mais ça reste très basique et en fait pas du tout parce que le plaisir que je
retrouvais enfin que j'avais en tant que développeur je le retrouve complètement en tant que Scrum
Master ou coach agile c'est la résolution de problème en fait donc les problèmes sont pas
forcément les mêmes bien sûr mais moi ce qui me plaisait c'est ça c'était la
aider à apporter des solutions à être créatifs à trouver justement les solutions les plus créatives
les plus sympas les trucs comme ça à y participer à participer à leur mise en place tout ça et
en fait c'est ce que je fais aussi c'est ce que je retrouve en étant Scrum Master avec les équipes
de voir vraiment on est bloqué sur quelque chose et puis pouf par l'intention collective par la
réflexion le brainstorming tous ensemble on a eu vraiment ce déclic ce déblocage et maintenant
on est et puis après il y a plus qu'à tester voir si c'était vraiment la bonne solution
donc voilà je retrouve vraiment ce même plaisir voir peut-être encore plus décuplé parce que en
tant que Scrum Master je vais être beaucoup plus à ne pas le faire moi même tout seul et donc
vraiment à être dans plus dans le collectif donc voilà ça me manque pas du tout alors du
coup j'ai une très bonne je me demandais comment est ce qu'on va passer de tout ce que tu nous
racontes à notre sujet du jour mais je crois que là on a enfin une transition tout trouvé puisque
le sujet du jour c'était le père programming tu m'avais sollicité au détour d'un message on
disait question pour toi en discutant avec un dev il m'explique que le père programming ça devrait
être fait avec par simony car c'est très fatiguant je me suis donc dit que cela ne devrait pas être
généralisé ni même dans une intération avec un rythme qu'on veut soutenable j'ai quelques
expériences en paire mais pas c'est pour juger t'en pense quoi là où je dis qu'il y a une transition
c'est que pour moi le père programming on est totalement dans cette idée d'intelligence
collective ou pour moi le père programming c'est quand tu un peu tu sais j'ai cette image de dragon
ball z là ou quand ils font fusion il y a deux personnes qui travaillent ensemble et dont les
cerveaux vont fusionner pendant quelques instants quelques instants quelques heures de travail pour
pour avancer et faire avancer le chemin public du coup je t'avoue que ça m'intrigue cette idée
de père programming c'est quoi ton expérience toi avec avec ça et quelle image tu en as aujourd'hui
toi et quelle image tu vois que les entreprises ont en général de cette pratique alors moi moi
comme je t'ai dit j'ai été finance pendant très longtemps donc le père programming je n'ai
je n'y avais pas goûté je connaissais même pas j'avais même pas l'idée et en fait c'est venu chez
moi assez naturellement que justement quand j'ai intégré l'entreprise et que j'ai commencé à
travailler en équipe ou sans connaître le père programming en soi je me rends compte je me suis
assez souvent et de façon assez naturelle c'est tout simplement voilà quelqu'un à travailler
sur un truc on se met ensemble pour régler un problème on réfléchit ensemble et et comme tu dis
on le fait en fusion en fait on n'est plus deux personnes qui réfléchissent on met vraiment
deux cerveaux qui se fusionnent en un et qui réfléchissent en même temps avec des ping-pong et
de façon super agréable.
Donc sans la formalisation on va dire du per programming tel que je l'entends aujourd'hui,
on en faisait et en fait c'était les moments à mon avis les plus agréables de développement.
Donc j'ai découvert au final le vrai per programming assez tard,
c'est-à-dire vraiment quand je suis passé de l'autre côté et que je suis devenu Scrum Master,
c'est la pratique je l'ai découverte et aujourd'hui ça me semble moi une aberration de faire autrement
et tel que je le vois aujourd'hui compris dans les entreprises, c'est un peu de façon un peu
naïve et classique, c'est les entreprises se disent bah non on ne va pas mettre deux
personnes qui travaillent sur la même chose, ça va nous coûter deux fois plus cher et donc
il y a une vraie difficulté de les convaincre, d'essayer et de voir le résultat, bah non ça
va pas leur coûter deux fois moins cher. J'ai réussi quelques fois malgré le fait justement
que moi même... Deux fois plus cher tu veux dire. Comment ? Tu as dit non ça ne va pas leur coûter
deux fois moins cher je suppose que tu veux dire deux fois plus cher. Ah oui non non, tu s'intéresses
encore même. Non ça va pas leur coûter deux fois plus cher ça va ça peut leur coûter
justement effectivement deux fois moins cher de faire comme ça parce qu'il y a plein de
bénéfices. Moi même j'ai pu le tester avec des équipes où voilà j'avais réussi à les
convaincre d'au moins essayer donc petit à petit, c'est à dire de se dire bah là y a peut-être
dans le planning à la fin du planning on se dit tiens y a une tâche, une relativement importante
peut-être que vous pouvez noter de faire en paire, ils ont commencé et là où j'ai trouvé ça
bien dans le sens je pense que j'aurais je leur ai fait découvrir quelque chose c'est que
peut-être je sais pas je sais même pas si c'était la deuxième semaine peut-être quelques jours après
justement avoir commencé à tester ça, moment je reviens je sais pas je vais faire une pause je reviens
dans le bureau et là il y avait personne, je n'ai personne dans le bureau et donc en fait bon bah
je m'assois je travaille et en fait à un moment ils reviennent et ils étaient partis d'eux-mêmes
dans une salle pour faire du mob mais ils voulaient se mettre en fait dans une salle avec un grand
écran pour pouvoir pour que ce soit plus à l'aise et tellement ils avaient été convaincus par cette
approche d'être plus efficace en travaillant à plusieurs sur le même problème et donc voilà là
je me suis dit bah c'est vraiment génial ça marche vraiment donc c'est vrai quand j'ai une personne
qui me dit qu'il y a un développeur qui me dit le père programming ça devrait être fait avec
parsimonie c'est fatigant moi je suis un peu embêté aussi parce que ne l'ayant jamais connu en
tant que développeur j'ai pas de légitimité pour dire non tu te trompes je n'ai que l'expérience
des autres en fait pour ça donc c'est pour ça aussi effectivement que je t'en avais parlé pour avoir
ton avis parce que le sentiment que j'ai au-delà de comme je disais pour les entreprises c'est
vraiment pour moi le problème c'est la vision du coup que ça a pour les développeurs souvent
la la pourquoi est ce qu'ils sont réticents quand j'en parle c'est le côté
perte de temps fatigue effectivement et puis à côté un peu on sait pas faire et en fait j'ai
le sentiment que bah en fait le le père programming oui c'est fatigant et j'en suis complètement
convaincu c'est fatigant mais tout comme si tu me demandais là de faire 150 pompes c'est fatigant
ouais par contre si je m'entraîne que j'y vais petit à petit que je m'entraîne à le faire dans
les un an dans un an faire 150 pompes ce sera moins fatigant complètement moi l'image qui me venait en
tête et que j'avais envie de partager avec toi c'est celle de la montagne en fait donc on est
complètement dans la dans la même lignée parce que ça va parler à tout le monde oui c'est très
fatigant le père programming et et ça a des impacts intéressants parce que quand tu as passé
une journée de 5 6 heures à père programmé t'es rincé moi je suis pas capable de faire plus de 7
heures de travail en père programming dans une journée tu vois c'est déjà énorme 7 heures de
père programmé ce qu'il faut comprendre que quand tu perds programme tu es c'est quelque chose
assez intense en fait c'est à dire que tu es à ton cerveau il a plus de 100% tout le temps là où
quand tu es tout seul tu as toujours ce petit moment où tu vas butiner à droite à gauche une petite
youtube un petit facebook un petit petit pipi un petit café un petit ci un petit là une petit
petit coup de mou après le repas tu as tout ça quoi alors que quand tu binhommes tu es en
vraiment à fond tout le temps quoi donc oui oui c'est très fatigant et j'avais envie de te dire
de manière un peu sarcastique ou ironique saut wat et alors est-ce qu'on est payé on est
est ce qu'on est payé pour faire des choses pas fatigantes facile où est-ce qu'on est payé pour
livrer de la valeur et le faire en tant que professionnel et là on a déjà un premier fil
c'est dire que ceux qui seront capables de faire ça à mon avis on a un avantage dans la valeur qui
peut amener à leur entreprise qui est qui est c'est même pas comparable tu vois en termes de
de poids on est sur on n'est pas sur sur une petite amélioration on joue plus du tout dans
la même cour en fait parce que non seulement c'est fatigant mais ça demande de la technique
alors on va adresser les points que tu as que tu as eu en termes de coup est-ce que ça coûte plus
cher pour moi la réponse est évidente non ça coûte pas plus cher et je vais même aller à
contre courant ça fait gagner énormément d'argent maintenant il faut qu'on s'entende sur ce
que ce qu'on inclut dans ce coup si tu comptes juste le coût de la fabrication ça va pas te
coûter deux fois plus cher mais ça va te coûter un peu plus cher que si tu le faisais tout seul
par contre là où tu y gagne pourquoi est ce que je me permets de dire que tu y gagnes énormément
d'argent c'est que par contre la qualité de ce que tu fais est sans commune mesure mais c'est la
maintenance en fait c'est sur le long terme la maintenant sur l'exact et la maintenant sur le
long terme c'est à dire que non seulement tu l'as réduit parce que la qualité ce qui fait à l'instant
t elle est sans commune mesure meilleur imagine que tu économises tout en plan de test fin tu
as il ya moins de bug et en plus t'as un deuxième effet qui se coule c'est que tu as fait circuler
la connaissance dans cette idée de maintenant tu as la fois la qualité intrinsèque du logiciel
et qu'est ce que ça va demander comme ressource comme énergie de s'approprier un code que tu
pas sur lequel t'es pas intervenu parce qu'évidemment meurfuit en toujours par là c'est toujours
pendant les vacances du développeur que t'es la plus grosse merde et donc t'as cette enjeu aussi
d'apporter de la sécurité psychologique au développeur et on sait que maintenant la
sécurité psychologique c'est un des enjeux majeurs de performance des équipes parce que les gens
sont sereins ils connaissent globalement les choses tu vas venir péter les éventuels silos
voilà il ya tellement de valeur générée en knowledge management en connaissance partagée de l'équipe
sur le produit mais sur les pratiques aussi sur la cohérence du code que pour moi ça
ça compense mais largement largement largement les coûts qui sont effectivement un petit peu
plus élevés sur l'instant de produire la même feature par deux personnes au lieu d'une qui que
je moi je mets j'estime de manière totalement empirique pas du tout scientifique à 1,4 fois le
prix que tu vas payer sinon c'est marrant ça peut être encore une fois très intuitif c'est ce que
je dirais aussi je suis là c'est d'accord donc sur l'instant ça te coûte peut-être 40 50%
plus cher mais en fait c'est pas que c'est un surcoût c'est que c'est un investissement c'est un
investissement dans la tête des développeurs dans leur compétence dans l'harmonisation dans
la connaissance et dans la qualité de ce qui est fabriqué parce que seul tu fais facilement des
erreurs à deux tu en fais beaucoup moins et oui et les erreurs sont moins chers c'est le c'est le
diagramme de c'est la boucle de feedback de dixpé hein ah bah oui parce qu'elles sont
chopées beaucoup plus tôt exactement beaucoup plus tôt alors voilà vas-y vas-y excuse moi juste
pour revenir sur le mot que tu utilises quand tu dis que oui c'est un surcoût en fait moi je
rêve presque envie de dire en vrai c'est le vrai coup ouais oui oui tu es raison c'est une autre
manière de voir bah ça dépend en fait est ce que tu préfères payer un maintenant ou payer sans plus
tard et c'est là où on vole on voit le problème c'est que moi dans dans les grosses entreprises
dont j'interviens souvent ils vont te dire qu'ils préfèrent payer sans plus tard parce que sans plus
tard c'est pas leur budget et là il ya plein d'autres billets qui vont rentrer en ligne de compte
et qui vont amener à ça je suis complètement d'accord avec toi parce que tu as adressé d'autres
points parce que là on a parlé du coup et donc plus le regard de l'entreprise ou en tout cas de celui
qui donne le donor d'ordre le manager qui va mobiliser la ressource maintenant tu as les arguments
vis-à-vis des développeurs c'est une perte de temps c'est quelque chose que j'ai entendu souvent
même dans ma propre entreprise dans ma propre équipe et à un moment donné tu peux pas forcer
les choses si il ya des tâches je veux bien l'entendre qu'il soit qu'il y a un petit côté
répétitif qui ont pas de sens de le faire à deux ce qui va venir interroger sur ce qu'est le
per programming pour moi pour moi le per programming je l'entends au sens xp du terme
parce que c'est mon voilà ça restera jamais mon le noyau mon va dire ma la première marmille
dans lequel je suis soit tombé et ça ça a fortement imprégné toute ma manière de réfléchir
et au sens d'experts du per programming il ya quelque chose qui est systématique dedans du coup pour
moi aujourd'hui que deux développeurs qui vont travailler ensemble à la résolution de problèmes
de manière ponctuelle pour moi je ne définis pas ça comme du per programming je définis ça comme
de développeurs qui s'entraide ce qui veut pas dire que ce soit pas bien attendons nous on
entendons nous bien c'est des je suis déjà très content quand je vois de développeurs travailler
ensemble et s'entraider je dis juste que pour moi ce que je définis comme étant per programming c'est
la démarche systématique de travailler à deux sur un sur un projet sur une future dans cette idée
de j'arrive le matin je ne me pose même pas la question de savoir si je vais bosser à deux c'est
je commence à trouver mon binôme du jour et ensuite qu'est ce qu'on fait aujourd'hui donc là
dedans il ya des choses qui sont effectivement peut-être pas très utiles de le faire à deux je
veux bien l'entendre pourquoi pas moi les séances que j'ai faites des dernières séances que j'ai
pu faire j'ai toujours eu le sentiment que c'était profitable mais c'est vrai qu'on a alterné des
c'était par sujet toi il ya certains sujets qu'on travaillait à deux et certains sujets qui
étaient travaillés tout seul c'est fatiguant oui ça c'est l'autre ça c'est l'autre chose qui est
donné mais encore une fois pareil si je me demande d'aller monter sur l'imalaïa pas surement
d'en être incapable si je m'entraîne pendant plusieurs mois je vais pouvoir le faire et puis
je pourrais m'entraîner à sûrement avoir d'autres sommets avant l'imalaïa tu vois le
Mont Blanc par exemple je pense qu'en quelques mois de préparation je devrais être capable de le faire
mais ça va me demander un vrai engagement mais pour moi c'est la différence entre le touriste qui
veut monter une fois à la montagne ou le guide de montagne quoi et notre métier c'est plus d'être
guide de montagne et on sait pas faire je pense que c'est un vrai vrai frein beaucoup de développeurs
savent pas faire mais il ya des choses que tu n'as pas exprimé et qui sont beaucoup plus subtiles et
inconscientes et qui sont pour moi les vrais freins du binommage fin du binommage du père
programmé c'est la dimension psychologique quand tu es en train de binommer tu dis un petit côté
se mettre se mettre à nu quoi en fait parce que tu fais rentrer l'autre dans ta zone d'intimité
vraiment autant physique que de travail alors maintenant avec le développement du remote on
arrive à bosser à deux c'est pas la même ça pas la même dimension mais tu retrouves quand même
ce côté là où tu fais rentrer l'autre dans ta sphère d'intimité qui est ton ton idéux et pour un
développeur c'est quand même quelque chose de oui c'est vraiment quelque chose d'intime en fait
parce que tu vas voir tout ce que fait l'autre et d'ailleurs si tu écoutes bien les premières
discussions de binommage de les premières séances de père ça tourne autour de quoi ça tourne autour
de ah tiens toi tu fais ça comme ça tu utilises ta raccourcie ou tiens tu n'utilises pas les raccourcis
ou tiens tu utilises la souris ah mais tu sais qu'il y a ça et il y a vraiment une phase qui est
pas évidente il faut avoir un certain état d'esprit d'accepter de faire rentrer l'autre dans sa
dans sa fragilité j'ai envie de dire dans ses carences d'accepter de les montrer à l'autre
parce que finalement quand tu vois du code produit tu vois des carences mais quand tu vois
l'autre en train d'écrire tu en vois encore plus et ça c'est assez intimidant et pour moi
je pense que c'est quelque chose de désagréable qu'il faut arriver à dépasser et je vois
je pense qu'il y a beaucoup de gens qui n'arrivent pas à dépasser ça en fait tout simplement du
coup du coup c'est intéressant ce que tu dis j'avais pas forcément vu ça mais je m'y retrouve
beaucoup donc je suis tout à fait d'accord est ce que du coup toi de ton expérience tu conseillerais
par exemple pour quelqu'un qui commencerait le père programming avec quelqu'un qui serait plus
expérimenté par exemple voilà un développeur un peu plus junior ou même qu'on a plus senior mais
qu'on n'a jamais fait qui commencerait avec toi est ce que tu conseillerais de tu te mettrai
dans quelle posture d'abord à moi je dirais qu'il ya plutôt un pré roquis puisqu'une posture le
pré roquis c'est de se sentir en confiance c'est à dire qu'en gros tu sais à ce truc c'est tout ce
que vous dirais pourra être retenu contre vous là dans l'estat américaine si tu pars dans une
séance de binommage avec un peu ce truc là on se disait au la la faire faire gaffe parce que l'autre
il a peut-être me planté un couteau dans l'eau là je pense qu'il y a mauvais il y a mauvaise
mayonnaise et je pense ça va être périlieux de faire ça ou alors en tout cas les séances ont
mettre vraiment du temps à venir à se mettre en place et si il y a une tri comme du flicage ou de
la vérification aussi je fait je me mets dans la place d'un développeur qui est en période d'essai
il vient d'arriver il fait du binommage ou du père avec son manager ça peut être compliqué ça
ouais pas de compliqué je me demande en fait est-ce que le manager aurait pas intérêt à se mettre
mais le manager il est rarement développeur il est rarement en développeur quand je dis manager c'est
le lit tech quoi on va dire de l'équipe est ce qu'il aurait plutôt tendance est ce qu'il faudrait
pas qu'il se mette lui d'abord au clavier pour limiter faire des erreurs exprès pour montrer
que il n'est pas parfait que l'autre peut lui faire remarquer ses erreurs et que ça se fait et pour
que ce soit plus facile ensuite c'est une manière de l'aborder moi j'ai pas de je n'ai pas de comment
dire de te directir et fort sur ça il faut le sentir pour moi le prévoquist c'est plutôt de se
mettre en confiance donc ce que tu viens de dire c'est une manière de mettre l'autre en confiance
et ou alors tu travailles avec une équipe l'idéal est évidemment une équipe qui a déjà une confiance
préalable mais même dans ce genre d'équipe il faut pas se tromper c'est quand même pas évident
donc il y a vraiment ce frein là pour moi qui est le plus important mais une fois que tu l'as
dépassé c'est là où pour moi le père programming devient le plus beau et j'ai des expériences de
père programming très intense émotionnellement j'entends j'ai dans les dans les d'ailleurs
quand il y a quelques années je me suis lancé en freelance j'ai commencé à recruter des freelance
pour faire des projets et c'est au cours d'une expérience avec un binôme mention spécial pour
randeska qui se reconnaitra si s'il écoute ce podcast où j'ai vraiment vécu quelque chose
d'assez intense où j'imagine que c'est ce que tu peux ressentir quand tu danse quand tu fais de la
danse de comment dire de technique ou de compétition tu sais ou avec un haut niveau d'engagement
technique et d'engagement dans ce sportive dans ce que tu fais sûrement il se sentiment d'une
danse à deux assez intense et c'était une espèce de communion des esprits pour te donner
une idée de la de la fluidité qu'on avait atteint lui il était au clavier et moi j'étais à la souris
essaye de faire ça de coder à deux avec quelqu'un au clavier et l'autre à la souris et imagine ce
que ça sous-entend de de synchronisation et de fusion pour sans que l'autre ait à dire ce qu'il
doit faire de savoir exactement à quel moment il faut mettre le pointeur de souris ou en fonction
de là où on en est de la production c'est comme si tu avais deux cerveaux qui codaient avec 4 mains en
fait et c'était hyper intense et de cette expérience là j'ai eu envie de recruter une équipe
pour retrouver ça mais je l'ai jamais retrouvé donc c'est aussi c'est aussi une manière de te dire
ça dépend des gens que tu vas avoir de leur envie d'y aller de la fréquence à laquelle ils vont
pouvoir expérimenter ça de l'engagement qui vont y mettre et pour moi c'est une pratique juste
fantastique le père programmé du coup c'est est ce que tu dirais que c'est vraiment
lié aux personnes ou est ce que tu penses que quel que soit les gens si vraiment ils sont impliqués
dans le produit ça fonctionnera je pense que quel que soit les gens ça peut fonctionner il faut
qu'ils en aient envie il faut qu'ils aient envie d'essayer et ça peut mettre plus ou moins de temps
je pense ça peut être plus dur pour certaines personnes tu n'as peut être plus facile pour d'autres
je pense ça va dépendre aussi tu vois on va toucher à des choses qui tournent autour de l'estime de soi
de l'image qu'on a de soi de la capacité à écouter un point de vue divergent tu vois on se
rapproche quasiment de j'ai envie de dire la meilleure manière de se préparer au père programmé
c'est peut-être même pas de coder ensemble c'est peut-être de faire des spectacles d'un pro
tu vois dans le père dans le dans une imprôte il y a ce truc que tu dois toujours partir avec ce
qu'a amené l'autre quand ce que tu rajoutes dans une imprôte doit être dans la continuité la
fluidité de ce que de ce qu'a amené l'autre si tu arrives en permanence dans une session de père
en disant à toi tu l'aurais fait comme ça mais moi je l'aurais fait comme ça ça peut arriver
mais si jamais tu n'arrives pas à dépasser ça et pour en tirer le meilleur des deux et qu'on est
en permanence dans une espèce de confrontation de point de vue ça ça risque d'être un peu
douloureux tu vois alors que si au contraire les deux construisent en permanence sur ce qu'amène
l'autre c'est c'est beaucoup plus c'est beaucoup plus puissant quoi ouais juste que tu veux dire et
c'est peut-être un peu ce que j'avais en tête dans ma question comme tu l'isais c'est quand je disais
qu'on est vraiment impliqué avec le produit c'est-à-dire que justement on arrive à dépasser
ce que pense l'autre de nous parce que ce qui compte pour nous c'est de réaliser le produit le
mieux possible et donc c'est l'enjeu n'est plus les plus haut au même endroit en fait exactement si
tu es capable de dépasser tout est peur tout est le regard de l'autre le jugement de l'autre
pour te disant tout ça je le fais pour une raison qui nous dépasse qui me dépasse l'équipe c'est
de dépasser tout ça et de rentrer dedans et de commencer à en sentir les bénéfices parce que
le problème c'est qu'il faut payer le prix de la mise à nu avant de avant de ressentir ce que ça
peut amener et il faut je te dis accepter complètement son imperfection sa fragilité
ses limites pour rentrer dedans et c'est par le par le travail collectif par la fusion de deux
cerveaux que tu vas ressortir grandit tout ça après personnellement j'ai jamais vécu en
situation professionnelle de mob j'ai pu parfois en animer mais je l'ai pas je l'ai pas vécu de
l'interieur je me sens moins moins pertinent j'ai l'impression de ce que j'ai vu que c'est moins
fusionnel que tu puisses dans un travail de construction et que ça ça a des vertus de par
contre c'est intéressant parce que tu fais monter beaucoup plus vite les gens niveau en fait quand
tu es en minimum c'est de 1 à 1 que se fait la diffusion de la connaissance en bas en mob j'ai
l'impression que d'un coup pff c'est tout le monde qui monte en level sur les pratiques sur la manière
de faire j'ai l'impression qu'il y a une difficulté supplémentaire en mob c'est que c'est que du
coup il faut synchroniser et harmoniser encore plus de cerveau c'est déjà pas facile à deux donc à
quatre je me demande ce que ça peut donner j'adorerais vivre ça de l'intérieur mais j'en ai pas eu
l'opportunité quoi bah écoute moi l'expérience que j'en ai eu alors j'étais en tant que
scrum master donc j'étais effectivement j'étais pas dedans dans le côté code réalisation mais
l'expérience que j'en ai eu et ce qui à mon avis je pense et une des raisons pourquoi ça a bien
fonctionné c'est que l'esprit de j'allais dire l'esprit de meute je sais pas si c'est le bon terme
plutôt que l'esprit collectif est arrivé très tôt c'est-à-dire c'est pas au moment de développer
au moment de coder que qu'il est venu c'est aussi par l'approche que moi j'ai de scrum et que j'ai
formé tel que j'ai formé l'équipe c'est-à-dire une de mes convictions dans dans scrum de de bonnes
pratiques c'est que les la création des solutions ne se fait seulement pendant le sprint planning
ou après pendant le sprint bien sûr mais pas avant le sprint planning en tout cas ce qui fait que
dès le sprint planning en fait toute l'équipe commence déjà à réfléchir en collectif à la
solution on lui apporte pas une solution en disant il faut faire telle fonctionnalité on a tel problème
l'équipe va essayer de trouver ensemble quelle fonctionnalité elle fait donc tu vois rien que
déjà là tout le monde a un peu près participé à donner son avis sur la solution la façonner un
petit peu donne son idée d'architecturer comment est-ce qu'on l'architecture etc donc avant même
tu vois de se mettre au alordis et au code l'esprit de collectif a créé la solution ce qui fait que
c'était peut-être plus facile pour eux ensuite de se dire pas oui en fait on la suite c'est que
on la crée tous ensemble on le réalise tous ensemble en fait c'est ce que je veux dire mais c'est
top et je pense que là c'est un contexte super favorable je vois qu'on a bien bien bien mangé la
timebox je crois qu'il va être temps de conclure cet épisode si les auditeurs veulent en savoir plus
sur ce que tu fais constantin ils peuvent venir au et ben sur scrum life la la première chaîne
youtube francophone qui parle de scrum et de l'agilité en général voilà n'hésitez pas n'hésitez
pas à nous rejoindre à regarder les vidéos on fait des on fait des live tous les jeudi midi donc
enfin de 13 heures à 14 heures exactement donc là on a changé un petit peu cette année
l'épisode sort en début de semaine qui laisse le temps aux gens de le digérer un petit peu et on
fait le live le jeudi pour pour en parler voilà pour discuter avec la communauté donc n'hésitez pas à
nous rejoindre et puis voilà après je pense que sur lindine sur twitter voilà vous pouvez me
contacter directement ce sera avec grand plaisir j'essaye de prendre toujours du temps pour répondre
aux questions qu'on me pose aux interrogations etc et d'être le plus dents possible quoi
merci constantin d'être venu aujourd'hui merci benoît merci à tout le monde quand tu as
toi cher auditeur j'espère que tu as kiffé cet épisode un peu plus long d'habitude mais je sentais
que si je coupais à 20 minutes au plein moment où on allait rentrer dans les sujets t'allais
t'allais vouloir m'échapper donc on l'a fait un petit peu plus long tu peux me dire si tu préfères
si c'est moins bien enfin voilà je suis toujours preneur de feedback sur sur la durée c'est
quelque chose qui me travaille et puis si tu en veux si tu as envie d'en savoir plus sur comment
écrire du code durable je t'invite à venir rejoindre cursus artisan développeur sur compagnons
artisan développeur.fr dans la rubrique formation