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 Dimitri Bailly, Dimitri bonjour.
Bonjour.
Comme c'est la première fois que tu passes sur le podcast, je te propose de te présenter
en une minute. Qu'est ce que tu fais de beau Dimitri ?
Alors moi je suis une activité principalement de CTO Mentor, d'accompagnement des équipes
sur leur organisation et la tech au sein des entreprises. J'étais CTO chez les furais.com
pendant 7 ans, 4 ans CTO et 7 ans chez les furais. Et j'ai aussi co-créé Flockon, une
conférence sur le travail en campant, en flux continu, en équipe. Et Tech Rocks, récemment
depuis 3 ans, une conférence et toute une organisation pour les tech leaders et les
CTO.
Dans les sujets que tu avais évoqué avant le début de l'épisode, on a parlé de comment
on optimise la vitesse de livraison plutôt que de l'occupation des personnes. Et ça
je trouve que c'est un vrai sujet, en tout cas moi je trouve ça intéressant parce qu'effectivement
je vois souvent dans les organisations qu'ils se préoccupent de savoir si les gens sont
bien occupés. Et toi tu dis non, en fait ce qui est important c'est la vitesse à laquelle
on livre et je trouve que c'est un changement de paradigme super intéressant pour donner
je sais pas pour donner des... tu crées un moudre ou je ne sais pas si t'as besoin
d'un point de départ mais moi je vois parfois des équipes qui pensent être agile et qui
mettent 2 à 3 mois pour livrer entre le moment de l'idée et le moment de la mise en prod.
Et encore c'est dans les best case. Qu'est-ce que ça t'évoque, qu'est-ce que tu veux
dire par là toi en fait ?
Alors c'est un vrai enseignement de travailler en campant là pendant 6 ou 7 ans et d'essayer
de comprendre avec flocon pourquoi campant plutôt que de littération ou du waterfall.
Il y a quelques lectures et quelques points vraiment très très forts qui me sont apparus
pendant ces travaux là. Et la première c'est ce qui s'appelle le cost of delay. C'est
qu'une façon de prioriser des fonctionnalités c'est d'estimer le prix qu'elle coûte à
ne pas la livrer. Donc c'est d'estimer les fonctionnalités à combien elle rapporte
par semaine. Et si tu la livres 2 ou 3 ou 4 semaines plus tard, finalement t'as perdu
cette valeur là à jamais. Donc on peut avec ce principe là de se dire qu'une petite
fonctionnalité qui rapporte très tôt sera beaucoup plus intéressant à mettre en production
qu'une grosse fonctionnalité qui rapporte beaucoup mais beaucoup plus tard.
C'est chaud parce que tu estimes en euro par semaine.
C'est chaud de faire cette estimation là non ?
Oui mais si tu fais de la béteste, si tu fais une simulation,
attends est-ce que c'est plus dur ou plus facile que d'estimer un effort ?
Écoute très honnêtement dans toutes les organisations que j'ai pu voir malheureusement
j'ai l'impression que et même la mienne à certains égards c'est clair que la notion d'effort
est beaucoup plus facile à estimer même si c'est probablement autant faux qu'une
évaluation business de l'impact d'un truc. C'est plus que j'ai du mal à imaginer comment tu vas
venir dissocier la valeur d'une sous-fonctionnalité en fait.
Alors on va partir sur l'axe donc il y a celui là qui est effectivement difficile de dire
combien vaut une fonctionnalité. Et il y en a un autre qui est plutôt que l'effort. Ce qui est
extrêmement important pour une tâche c'est ça durer de vie. Dans combien de temps il se passe
le délai entre j'ai l'idée et je la mets en production.
Est-ce qu'on appelle le TACTIME dans le lit ?
C'est le LEED TIME. Le TACTIME c'est plus un rythme de livraison de fonctionnalité c'est lié
mais on a tout le travail là quand on passe en campant et en livraison finalement continue
c'est de réduire la durée de travail sur une fonctionnalité toute seule. Quand tout va vite,
quand les fonctionnalités vont toutes très vite, on est agile parce que voilà on prend une fonctionnalité
et très peu de temps après elle est en production.
Et ça veut dire quoi pour toi à vite ?
Même 15 jours c'est vite quand on regarde la plupart des tâches qui sont dans les équipes actuellement.
C'est à dire que si t'as une idée et 15 jours après elle est en prod c'est vite.
Par rapport à j'ai un backlog, je livre tous les trois mois où c'est un peu l'état d'esprit
quand on a Scrum quand il fait des sprints de 15 jours, il se donne un lot fixe de fonctionnalité
qui seront en prod dans 15 jours.
Et là ce stade de l'épisode si quelqu'un écoute et dit ok c'est quoi la différence du coup
entre un lead time de 15 jours et des itérations de 15 jours si je mets 15 jours dans les deux cas livrés ?
C'est quoi la différence ?
Que toutes tes tâches mettent 15 jours à être en prod alors que tu peux avoir un lead time moyen
avec des tâches qui mettent un jour ou des tâches qui mettent 3 semaines.
Donc l'idée c'est de dire tu peux pas forcément réduire tes sprints à faire tout dans la même journée.
15 jours c'est déjà très bien et je pense qu'il y a très très peu d'équipes qui ont un temps moyen
entre l'idée et la mise en production y compris de tout ce qui attend dans le backlog.
Et du coup quand tu parlais de la valeur perdue tu parlais d'une méthode de priorisation.
Le truc qui me vient d'un coup à l'idée c'est que si j'aimais en l'impliquer je vois pas mal de
projets où ça ferait assez mal en fait parce qu'on se rendrait compte qu'en fait on ne perd rien.
Et de là je vais vous dire est-ce que ça vaut quelque chose qu'on est en train de livrer ?
Oui ça c'est une façon d'évaluer le stock des fonctionnalités qui sont en cours.
Quelle valeur ça a ? Quand on fabrique des voitures qu'on ne vendra pas
est-ce que ça vaut le coup de les fabriques et c'est ça que tu dis ?
Moi je vois des équipes parfois qui se bouffent le fois.
J'ai notamment tâtu une équipe qui se prend la tête et quand je leur pose la question
vous avez combien de clients ? Ah non mais en fait on n'a jamais mis en prod.
Et l'équipe ça fait trois ans qu'il se bouffe le
fois sur le respect des délais. Et là je me dis mais wow.
Donc moi c'est le mantra que j'ai au niveau de floconnes et de mes pratiques c'est mettre en
production et de regarder le temps que mettre chacune des tâches de façon isolée quoi.
Quand est-ce qu'elle a démarré et quand est-ce qu'elle se termine et est-ce que je
peux livrer une tâche toute seule de façon indépendante des autres ?
Et du coup c'est vrai que si on met ce filtre là où on cherche la vitesse de mise en prod
plus que ça suréglige, on se soit bien occupé et tout ça, on se retrouve dans une situation
tu me disais où du coup des choses, des pratiques comme le binommage ou même le mob prennent du sens en fait ?
Oui ça c'est vraiment je trouve que je manquais d'arguments pour aller vers
du per programming pour aller vers du mob programming qui me plaisent énormément et là je me suis
retrouvé à me rendre compte qu'effectivement si tu favorises la vitesse à laquelle une
fonctionnalité est conçue en dialogue avec le productonneur par exemple,
parce qu'il y a plein d'équipes où le productonneur il parle à personne jusqu'à ce qu'il livre
l'aspect et les développeurs commencent à travailler dessus et découvrent que c'est dur à faire
où il y a plein de discussions qu'on n'a pas eu lieu. Donc là on a perdu du temps à ne pas
discuter, à ne pas avoir un développeur qui discute avec le productonneur donc une sorte de
première paire qui pourrait discuter beaucoup plus tôt puis coder la paire review en même temps en
TDD ou en paire programming, voire du mob programming si ça fait du sens qu'il y ait beaucoup de monde
autour d'une table pour que la fonctionnalité aille très vite. Et ça tu l'as déjà vu parce que moi
du per j'en ai déjà vu beaucoup pratiquer et c'est une pratique que je trouve juste incroyable
dans ce qu'elle apporte dans la valeur ajoutée qu'elle amène. Mais vraiment incroyable c'est
dire qu'à chaque fois que je refais cette expérience, même après dix ans où je le fais,
je me dis c'est quand même badass. Et là je me dis ce que je n'ai jamais expérimenté personnellement
c'est de faire perprogrammer des gens de métiers différents. Je suis intimement convaincu de la
valeur ajoutée forte que ça peut avoir notamment dans des cas avec un développeur et un designer
qui puisse interagir ensemble. Dans le cas avec un product honneur, j'aurais un a priori du genre
j'ai peur qu'il s'emmerde le gars ou qui perdent un peu de temps. Tu l'as déjà expérimenté,
tu l'as déjà vécu ? Alors je l'ai déjà vécu partiellement donc pas de manière industrielle
et puis moi je suis pas à ce que tout aille super vite le plus vite possible. Je suis vraiment
dans les personnes les plus convaincus d'un rythme soutenable. Le but de jeu c'est d'un rythme
soutenable où les gens travaillent de manière posée maratonienne mais à l'intérieur de
quel tout va vite. Je sais pas si tu connais le jeu des prénoms qui est un petit test de dire
que si tu as quatre prénoms à écrire, si tu commences à écrire les quatre prénoms let par let,
chaque prénom en parallèle. Je vois très bien, ça porte un an, je me rappelle plus.
Le contexte switching, les quatre prénoms vont mettre le même temps à être écrits tous les
quatre. Si tu les écris un par un, chaque prénom va être écrit très vite mais il y a trois prénoms
sur lesquels va falloir dire non, je commence pas tout de suite. Pour moi c'est ça le point clé
qui arrive dans toutes les équipes, c'est que personne ne sait dire non à trois tâches sans
arguments. Avec le seul argument qu'il faut juste que j'en prenne une peu importe laquelle et les
quatre iront plus vite. Est-ce que tu veux dire c'est qu'il y a personne qui arrive à faire ça,
est-ce que c'est une question de courage, est-ce que c'est une question d'avoir les idées claires ?
Question d'avoir le courage effectivement de dire non à une personne qui attend la fonctionnalité,
à qui tu ne pourras pas dire pourquoi t'as pris quelque chose d'autre, parce qu'en fait il n'y a pas
besoin d'ordre, il suffit juste d'en prendre une après l'autre. Peu importe l'ordre, les quatre
iront plus vite. Pour l'auditeur pour être sûr de bien ressitué parce que l'idée c'est de dire
si t'as quatre tâches, quand même elle serait d'une durée de réalisation égale, si tu les
travailles les quatre en parallèle, vu que tu diffuses ton énergie sur les quatre, au global ton
lead time va prendre beaucoup plus de temps pour chaque tâche. Et si tu fais un random et que tu
les prends dans un ordre aléatoire, elles iront toutes plus vite du début à la fin que si tu
fais les quatre en parallèle, donc ta promesse elle est tenue d'aller plus vite et il y en a une qui
sera livrée quatre fois plus vite que les trois autres. Donc en termes d'effort, combien même ça
serait le même effort, ce qui est rarement le cas parce qu'en fait tu économises en plus le
coût du contexte l'utine. T'as moins d'effort, mais combien même ça serait le même effort, juste
en pure délai, la première fonctionnalité sortira quatre fois plus tôt que dans le cas où tu mènes
les quatre en parallèle. Et la dernière sortira plus tôt que les autres. Donc tu as gagné partout,
tu as eu le temps de prendre un café. Et qu'est ce qui fait que c'est pas plus répandu alors d'après
toi ? Et bien je cherche pourquoi les gens ne bossent pas comme ça parce que tu as bien, ce que j'ai en
tête actuellement c'est que pour pouvoir en faire comme ça il faut dire non à trois personnes,
je ne commence pas tout de suite. Donc ça serait l'incapacité à prioriser de manière extrême
parce que là finalement on se focus sur une tâche. C'est assez extrême comme ça me fait beaucoup
penser à un bouquin The One Thing. En gros tu fais bouger un domino à la fois qui emporte le suivant
et tu te concentres tout là dessus quoi. Et là dessus en développement logiciel, l'incrément il
fabrique autre chose. En fait ça c'est cette partie là qui est que tu vas aller plus vite,
tu vas avoir plutôt un retour sur un feedback de comment ça se passe en production et du
coup tu pourras même te dire que la quatrième elle n'est pas nécessaire par rapport à ton équipe
qui n'est jamais allée en prod, si elle allait en prod beaucoup plus tôt elle pourrait apprendre
que le reste des fonctionnalités qu'elle allait construire n'était pas nécessaire. Ça j'ai déjà
vécu ça plusieurs fois parce que quand t'as ça en tête après c'est difficile à enlever c'est
de dire j'ai une fonctionnalité je la mets en production la plus petite possible c'est tous
les MVP mais ça participe à la vitesse d'exécution en disant je fais beaucoup moins de choses de
façon plus posée à plusieurs et tout va plus vite. Un factuellement tout va vraiment plus vite
et deux tu peux faire moins de choses. En plus tu économises du gaspillage et tu emplies.
Bon écoute je revois ce que soit le mot de la fin Dimitri on a mangé la timebox c'était super
intéressant. Moi je suis curieux d'entendre les auditeurs si tu veux nous faire un retour
cher auditeur tu nous envoies un petit feedback soit en commentaire dans la publication de cet
épisode soit tu m'envoies un mail benoît à robasartisandeveloper.fr est-ce que ça te parle
tout ça est-ce que ce que raconte Dimitri fait éco chez toi et puis Dimitri bah écoute si les
auditeurs veulent en savoir plus ou est-ce qu'ils peuvent venir te lire ou te regarder ? J'aurais
tendance à dire qu'ils viennent aux conférences que j'organise puisque j'ai trouvé des gens qui
parlent de ça bien mieux que moi. Flocone ça va être tout le mois de novembre tous les soirs
à 18h on a un parterre de speaker assez incroyable tous les soirs à 18h tout le mois de
novembre c'est gratuit ou contribution ouverte en fait cette année comme on n'est pas dans des
locaux physiques donc voilà flocon.io et Tech Rock ça va être le 10 décembre la vieilloterie
pas encore ouverte mais ce sera le 10 décembre toute la journée et on a aussi full remote non ?
Full remote aussi ouais. Ok bah écoute ça c'est génial ça permettra à tout le monde de profiter
merci Dimitri d'être venu aujourd'hui. Merci beaucoup. Et bien cher auditeur j'espère que ça
t'a plu si c'est le cas je t'invite à nous rejoindre tu auras artisandeveloper.fr inscrit-toi
pour recevoir tous les prochains conseils tous les prochains emails que je pourrais t'envoyer
pour te donner des conseils et booster ta carrière c'est sur artisandeveloper.fr je te remercie je te dis à bientôt