Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Nicolas Verrino, Nicolas bonjour.
Salut bien, là.
Je pense que ce n'est pas passé inaperçu le 28 août dernier,
Uncle Bob, publié à un article The Tragedy of Craftmanship,
qui est une espèce de réponse ou de follow-up, on va dire, sur
la quina d'ouverture de Martin Foller sur Agile Australia.
Donc il y a, je pense, le jour même ou quelques jours avant.
C'était le 25 août, je crois.
Le 25 août ?
Qu'est-ce que tu as lu les deux ?
Moi, j'ai lu que le papier d'Uncle Bob.
Est-ce que tu as lu les deux ?
Ouais, moi j'ai lu les deux.
Alors si tu nous faisais un résumé,
déjà de la pensée initiale de Martin Foller,
qu'est-ce que tu as compris et retenu de cet article ?
Alors la première chose qu'il dit, c'est que le mouvement Agile
existait déjà bien avant 2001,
publication du manifeste Agile,
et que l'objectif, c'était de réconcilier
management et développement.
Donc il voulait réconcilier les développeurs avec leurs managers
ou les chefs de projet, etc.
Ça, c'est la première chose.
Et le business en général.
La deuxième chose qu'il dit, c'est que avant 2010,
donc entre 2000 et 2010,
de son expérience lui en tant que consultant,
il allait boire pas mal d'entreprises,
il rencontrait des boîtes qui,
quand on leur parlait d'agilité,
ils ne savaient pas ce que c'était.
Donc il avait du mal à faire passer ces idées
parce que c'était quelque chose de nouveau.
Et à partir de 2010 environ,
c'est devenu assez terrible,
puisque les gens, quand on leur parlait d'agilité,
ils disaient, c'est horrible,
l'agilité, ça marche pas chez nous.
Ou alors ils disaient qu'ils étaient agile,
mais ils n'étaient pas vraiment.
En fait, ils n'avaient pas compris.
Il y avait des petites sur les vitres.
C'est ça.
Ils gardaient une structure comme avant,
ils fonctionnaient comme avant,
du command & control,
voire du Taylorisme,
mais pas du tout d'agilité.
Ensuite, ce qui a été loupé,
donc il parle cette partie-là,
c'est la partie attention à l'agile industrielle complexe,
donc au complexe industriel agile,
qui n'est pas très bon.
Ensuite, il parle de l'excellence technique,
qui a été complètement oubliée
avec l'agilité.
Et enfin,
son dernier point,
c'est parlons de produits plus que de projets.
Dans le sens où les projets
ont une durée de vie très courte,
et les produits ont une durée de vie longue,
et quand on fait un logiciel de qualité,
quand c'est un réel investissement
qui rapporte de l'argent,
on veut non pas créer des projets,
plein de petits projets,
qui ont une durée de vie courte,
mais avoir une vision produit
qui est à long terme,
avec une équipe qui dure.
Voilà.
C'est un peu les trois points
de ça qui note.
Et toi, comment ça fait eco,
déjà, toi, ce que tu vois,
l'état du marché tel que tu le vois,
et tes opinions.
Ah oui, clairement,
j'ai commencé,
j'étais dans une entreprise,
on faisait du scrum,
mais les cas et des charges étaient figés,
donc il n'y avait que le développement,
qui était intératif.
Ça n'avait rien d'agile.
C'était juste, on ne sait pas ce que les dev font,
et du coup, on va leur demander
de nous livrer régulièrement des trucs
pour essayer de vérifier qu'ils font bien,
qui ne font pas n'importe quoi.
C'était un peu salide,
et c'était ce couvert d'agilité,
on va faire plus de contrôle,
en leur demandant de livrer plus régulièrement.
Ensuite, je suis intervenu
dans une grande banque aussi,
où la banque
était organisée en silo technique.
Il fallait parler
à 200 équipes différentes pour mettre un logiciel en prod.
Donc ça aussi,
ce n'est pas du tout agile,
après, il ne s'estampilé pas agile,
donc ce n'était pas plus mal.
Et sinon,
qu'est-ce que j'ai rencontré d'autres?
Ça a peu près tout.
J'ai coaché une start-up pour qu'elle devienne agile,
donc avec du scrum dedans.
Ça s'est plutôt bien passé.
Non, sinon,
de mon expérience,
de ce que j'en ai vu,
ça reflète plutôt bien
l'état de l'agilité aujourd'hui
avec ce qu'on dit sur Internet.
Deuxièmement,
des différents témoignages.
Effectivement,
l'agilité était censée ramener un peu de bonheur
et de paix
entre le business et les développeurs.
On ne peut que constater
que la plupart des développeurs sont malheureux
malgré le fait que ce soit de l'agilité.
Pour moi,
les cas que je vois,
c'est que ça a accentué certaines choses.
Je le dis,
j'ai cette croyance aussi,
c'est que
passer à l'agilité
par effet de mode,
ou par opportunité,
d'aller pervertir l'approche
en y espérant plus de command and control,
plus d'engagement.
En gros, tu ne réponds pas
à un problème de démotivation
d'une équipe par un passage à l'agilité.
Non, pas du tout.
En fait, c'est même l'inverse.
C'est-à-dire que ça va venir amplifier
ou pour moi,
les démarches agiles sont des accélérateurs,
sont des amplificateurs.
Donc si
la culture est déjà saine,
on va amplifier une culture saine.
Mais si on amplifie une culture
qui soit une culture mal saine,
soit, et c'est le deuxième point,
une équipe qui
n'est pas forcément
bien ancrée dans ses pratiques,
qui ne maîtrise pas forcément
son pot de code,
tu vas juste accélérer
un truc qui est ingérable.
Et là, tu mets
en lumière
des problèmes qui auraient pu
être gérés avec le temps long
sur des itérations d'un an,
sur des V1 et V2,
comme à l'ancienne.
Mais là, d'un coup, tu mets
un gros spot lumineux
sur ça.
Et ça peut avoir des effets assez pervers.
Ce qui m'amène,
souvent, quand je vois
des équipes dont le scrum est
défaillant,
il y a souvent une composante technique.
C'est-à-dire qu'il y a souvent
une composante où la technique est défaillante,
voire on s'en occupe pas du tout.
C'est la grande oubliée
de scrum, la technique.
C'est clair.
Et on se retrouve avec des PIOs
qui disent qu'ils ne savent pas estimer.
Mais si ils ne savent pas estimer,
je vais questionner
la manière de donner le besoin,
questionner la maîtrise qu'elle a
à l'équipe de son code
ou quand ils y réparent un truc, ils en
cassent deux autres.
Ah !
Il y a peut-être effectivement...
En tout cas, ça fait émerger
des problèmes par le rythme
intensif de livrer toutes les semaines,
même tous les 4 semaines.
Pour certaines équipes, toutes les 4 semaines,
c'est hyper violent.
Et ça vient faire
et mettre en évidence certains problèmes.
Clairement.
On va demander à une équipe
qui est de base, qui a l'habitude de
travailler sur des temps longs
où les specs
ne changent pas.
C'était la manière classique de faire.
Chaque changement de specs, ça nécessite
une nouvelle conception.
Ça va avoir un impact.
Si on est conscient de cet impact-là,
puisque l'équipe n'est pas capable de
concevoir pour le changement.
On va passer en mode agile, qui est
un mode où
le changement est accueilli à la brase
ouverte.
Sauf que quand on fait un logiciel
et qu'on ne sait pas concevoir
un logiciel flexible,
et qu'on vient toutes les 2 semaines,
3 semaines ou 4 semaines, avec des changements,
que ce soit de priorité ou carrément de fonctionnalité,
ça devient...
Ça fait l'effet boule de neige.
Ça devient très problématique.
Au début, on ne se rend pas compte si c'est
un changement, mais les premières
itérations se passent bien.
Au fur et à mesure, ça s'en vénime
très rapidement.
Ça nécessite une excellence technique
et c'est là où Martin Faulard
met bien l'accent dessus.
C'est que pour les faire de l'agilité,
vous voulez embrasser le changement.
Vous devez avoir de l'excellence technique,
puisque sans l'excellence technique,
vous n'êtes pas capables de concevoir
et de faire évoluer un logiciel de manière
incrémentale, iteratif, convenablement.
Vous ne pouvez pas répondre au changement
correctement.
Je te propose sur ces belles paroles,
que ce soit le mot de la fin.
Ça marche.
Merci Nicolas D'Advenu.
Si les auditeurs veulent en savoir plus, ils peuvent venir où ?
Sur mon site internet
refacto.fr ou sur les réseaux sociaux LinkedIn
et Twitter.
Avec mon nom et mon prénom.
Nicolas Verrino, ça marche.
Quant à toi, cher auditeur, merci de nous avoir
écoutés jusqu'au bout.
Viens t'inscrire sur artisansdeveloper.fr
pour rejoindre la communauté des artisans passionnés
et je te dis à demain.