Bienvenue sur le podcast Artisan Developer, l'émission qui combine technique et agilité
pour partager la passion du code.
Aujourd'hui, je suis avec J.P. Lambert.
J.P. bonjour.
Bonjour.
Juste avant, tu me challenge en me disant Benoit, ton article sur les 12 principes, c'est
cool.
Mais est-ce que tu savais qu'il y avait des choses nouvelles qui t'est sorti ? Et là,
tu m'as parlé de Modern Agile et effectivement, je dois t'avouer que non, je ne connaissais
pas.
Qu'est-ce que tu penses que apporte Modern Agile par rapport aux manifeste publiés
en 2001 ?
Modern Agile, je vous invite tous à aller sur ModernAgile.org.
Vous verrez, il y a une petite roue avec 4 grandes principes qui est disponible en plein
plein plein de langues.
Vous verrez, il y a des traductions.
On peut le lire en vitesse vu qu'il est très court.
Alors si je prends la version française pour pas m'embêter à le traduire, voilà.
Donc, il y a une forte dimension humaine.
On a à rendre les gens fantastiques.
On a un peu son complémentaire qui est faire de la sécurité un prérequis.
C'est qu'effectivement, pour que les gens s'expriment, etc., il faut qu'il y ait
une sécurité au sens sur tes psychologiques.
Il faut être libre de tester des choses, de parler, de dire ce qu'on pense.
On a apporté de la valeur en continu et on a expérimenté et apprendre rapidement.
Voilà.
Et ça, en fait, c'est...
Si on le compare par rapport justement au manifestagile, on peut noter un somme de
différence.
Déjà, la première différence, c'est que c'est pas du tout, du tout, du tout un TIT.
Voilà.
Dans les manifestagiles, on parle quand même de livrer des logiciels, etc.
Là, on parle juste de apporter de la valeur.
Ça, c'est une première chose parce qu'il y a quand même pas mal de gens qui s'inspirent
de l'agilité pour faire plein de choses.
Et souvent, d'ailleurs, avec beaucoup de succès, du coup, finalement, ils bricolent
naturellement.
Alors là, déjà, on commence par donner un framework où ils n'ont pas besoin de bricoler.
Ça parle directement à leur domaine parce qu'on est allés à l'essence même du manifeste,
de cette manière de travailler.
Ensuite, on a vraiment toute la dimension produit au sens moderne du terme.
Voilà.
Expérimenter, apprendre rapidement.
Voilà.
Moi, tout de suite, je vois le Lean Startup et c'est juste comme ça qu'on doit bosser
aujourd'hui, en fait.
Et c'est aussi se dire qu'apprendre des choses, ça a énormément de valeur.
La valeur, ce n'est pas que le code qu'on livre parce qu'il faut livrer le bon code,
en fait.
Il faut livrer le code qui est pertinent.
Et donc, effectivement, dans une démarche produit, parfois, trouver la bonne chose à
faire et après, si c'était juste trois lignes de code et c'est vite fait, ça a énormément
de valeur, beaucoup plus de valeur qu'être capable de livrer plein de choses tout le
temps, très, très vite.
Donc ça, c'est super intéressant.
Et la partie humaine me semble vraiment très intéressante parce que la grosse différence
entre l'agilité et ce qui existait déjà avant, quand je dis ce qui existait avant,
je ne parle pas du cyclan V.
Justement, entre le cyclan V et l'agilité, il y a eu les sorts des méthodes incrémentales
et littératives qui forment le socle de base de l'agilité, évidemment.
L'intératif, c'est essentiel.
Et en gros, on ferait au lieu de faire un seul cyclan V, on ferait tout un tas de mini-cyclan
V court et à chaque fois, très bien, on refait tout.
On spécifie, on développe, on teste.
Sauf qu'on va le faire plein de fois et à chaque fois, on va apprendre, on va avancer.
En fait, si on fait ça, on est vraiment dans du management traditionnel.
Ce n'est pas les gens d'en bas qui décident, il y a un architecte, etc.
Mais malgré tout, ça va suffire pour s'occuper de tous les risques projets traditionnels.
Globalement, on construira à peu près ce qu'on a besoin de construire.
On sera dans les temps, on sera dans le budget, etc.
Et la différence de l'agilité, c'est qu'on rajoute la dimension humaine.
C'est qu'on commence à dire, pas juste, il faut livrer souvent, etc.
Mais en plus, les gens qui savent, c'est ceux qui font.
Donc cette dimension humaine est vraiment très, très, très importante.
Pour moi, c'est la différence que je fais entre le développement incrementale et iteratif,
qui peut se faire encore une fois avec du management talentiel, pyramidal, etc.
et l'agilité, qui a tout un gros impact finance sur la dimension organisationnelle.
J'entends ce que tu dis.
Moi, je vais rebondir sur un point, sur le expérimenter et apprendre rapidement.
Ça, c'est clair que pour moi, ça a beaucoup de valeur et c'est toujours assez compliqué
de le faire comprendre aux clients que le fait d'apprendre, non seulement avait de la valeur,
mais avait un coût aussi.
Et qui va aller mieux livrer les bonnes choses plutôt que livrer beaucoup de choses.
Et ça, c'est une bataille quasiment permanente, surtout avec les start-upers.
Moi, je travaille beaucoup, pour pas dire essentiellement avec des start-upers.
Et les gars, ils ont l'impression qu'il faut aller conquérir un marché en apportant beaucoup de choses,
en apportant beaucoup de features.
Et moi, j'essaye de leur expliquer.
Non, ça sert à rien d'aligner 12 mecs pour sortir votre truc,
parce que sur les 12, sur toutes l'énergie que vous allez mettre,
on place au moins 50% de choses que vous allez jeter,
parce que ce n'est pas ce qu'il faut, en fait.
Et vous allez vous rendre compte que je suis mainfaisant.
Donc là, je te rejoins.
Là où j'ai peut-être un point de divergence,
c'est justement sur le fait que les trucs qui ne sont pas techniques,
moi, ça me rebute toujours un peu.
Sûrement que j'ai été traumatisé par ces âgiles tours,
où on venait parler d'agilité IT, quand même dans le secteur IT.
Et où tu avais une session technique qui se courait après, tu veux ?
Elle était parfois, même parfois à zéro.
Et moi, je t'avoue que ça m'a un peu fatigué.
Parce que je pense que si à un moment donné,
on ne s'intéresse pas à la technique,
ça devient très compliqué de faire l'agilité.
Et juste dire,
ça viendra par les rétros,
ça viendra laisser faire confiance,
j'ai du mal.
C'est-à-dire que si tu fais de la merde,
le problème, c'est qu'à un moment donné,
ça va mettre toute l'équipe sous pression,
ça va mettre tout le monde sous tension,
et ça va forcément mettre le management sous tension,
et donc créer un contexte qui sera défavorable à l'agilité.
Tu parlais de faire de la sécurité après Rocky.
Si tu n'es pas zen toi-même
sur ce que tu es en train de dire
ou si tu ne vas pas te prendre des bugs,
parce que quand tu corriges un truc, tu en as trois qui claquent.
Il y a personne qui est zen,
la sécurité pour personne.
Et donc, oui, à un moment donné,
je raccroche les choses à la technicité,
l'expertise technique,
l'excellence technique même, je serais dire.
Bah, tu as en ta raison,
je suis le premier à dire
que la technique
c'est super important.
Mais effectivement, je fais aussi
partie de ceux qui
le voient entre guillemets
comme quelque chose d'essentiel,
enfin, de secondaire.
C'est essentiel, on ne peut pas faire 100,
mais je le mets quand même à niveau en dessous
de tout ce qui va être vision,
produit, organisation,
dans le sens où je suppose que
ça se mettra naturellement
si on a la bonne organisation.
Après, ce que j'ai dit,
c'est là où j'ai envie d'insister.
T'as dit plein de choses qui se complètent.
Tu parles justement de cette case
expérimentée à prendre rapidement.
C'est celle-là que je vais parler.
Tu parles justement des startups.
Et en fait,
moi, je te parlais du Lean Startup,
et c'est vrai qu'en les gens,
ils te lisent le Lean Startup,
ils se posent toujours cette même question.
Mais comment je fais pour allier
le fait que je vais très vite,
j'expérimente plein de choses,
je pivote très très très vite
et en même temps,
je fais pas de la merde.
Et ça fait écho aussi aux échanges qu'on a pu avoir
quand tu te présentais lors du Scrum Life,
c'est ce que tu disais, c'est ce que t'as vécu
dans Lean Startup, etc.
Et c'est une question fondamentale
que les gens se posent toujours.
Je suis en agilité.
Comment je fais pour que d'un côté
je puisse changer de cap comme je veux,
être super flexible,
accueillir le changement avec bonheur
et de l'autre,
je fais pas de la merde.
Et en fait,
le truc qu'il faut réussir à comprendre,
c'est que c'est exactement le même objectif.
C'est que expérimenter et apprendre
rapidement,
c'est ça qui est écrit, rapidement,
tu peux pas si ton code c'est de la merde.
Et en fait,
il y a ça, c'est que
WIS n'est pas dit clairement dans Modern Agile,
du coup, faut être bon techniquement.
Mais sauf que tu peux pas apporter de la valeur en continu,
tu peux pas expérimenter et apprendre rapidement
si derrière
ton code, il est paniqué.
Et c'est toujours ça en fait.
Les gens, oui, ont fait des compromis,
ont jeté des choses, mais
le compromis, il est sur le périmètre.
Il n'est pas sur le niveau de qualité
de ce qu'on fait,
fondamentalement, ce qu'on doit faire
quand on regarde les Amazon et les compagnies,
les gars, ils livrent en prod toutes les 11 secondes.
Ben, je pense que, oui,
régulièrement, ils font des compromis,
mais ce compromis ne se fait jamais au
détriment de leur capacité à livrer
souvent et de manière soutenable.

voilà, souvent, les gens, quand on leur dit
c'est le classique, ah, j'ai 3 points,
j'ai plus le temps, comment je fais ma story,
ils le conclut par
bon, ben, faut que je fasse de la merde.
Ah non, la conclusion, c'est
et bah tu peux pas tout faire, il faut enlever du fonctionnel.
Mais tu ne fais pas de la merde.
Donc voilà, moi je le vois comme ça,
après, je te rejoins, effectivement,
si tu fais du ModernoJal mais que tu fais
dans la formatique, ça fait peut-être du sens
de l'accompagner par tout un tas de bonnes pratiques,
typiquement
le fameux package qui nous vient
d'experts, mais voilà, enfin plus,
il y a des gens même qu'on compilait, évidemment
derrière, il faut être bon techniquement.
Mais
le jaune, c'est rendre les gens fantastiques,
rendre les gens fantastiques, c'est
évidemment une dimension en tant que collègue,
mais pourquoi ça serait
pas aussi une dimension d'excellence,
les collègues sont bons techniquement,
c'est pas juste qu'ils sont pas bêtes
et qu'on s'entend bien et qu'on a un bon espace.
Merci,
je te propose que ce soit le mot de la fin,
merci pour cet échange et merci d'être venu.
Avec plaisir.
Quant à toi chère auditeur, j'espère que tu as apprécié
ce podcast. Si c'est le cas,
je t'invite à aller mettre 5 étoiles sur iTunes,
ça nous aidera à le diffuser
et à le faire connaître. Et si tu as envie d'en savoir
un petit peu plus sur ce que fait GP,
je te mettrai un lien dans la description pour aller
voir son blog et sa chaîne.
Je te remercie et je te dis à demain.