Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Dans les approches classiques, il y a ceux qui pensent et ceux qui font.
Ériter des systèmes de management militaire, l'enjeu est de réduire le coût de synchronisation.
Et du coup, le système pyramidal est le système qui minimise le nombre d'interactions.
Pour qu'une information soit diffusée et transmise,
le système pyramidal permet de faire en sorte que ça coûte le moins cher possible en coûte transmission.
Donc, j'aurais capitulé. Il y a ceux qui pensent et mettent au point le plan.
Et puis ensuite, on transmite au développeur qui n'ont plus qu'à coder.
Enfin, on fait la recette et tout va pour le mieux dans le meilleur des mondes.
Sauf que tu sais comme moi que cette vision idéaliste est une pure chimère.
Un héritage de l'agence touriste peut-être.
Mais dans notre vraie vie, dans le quotidien, ça marche pas comme ça.
C'est une chimère, c'est un fantasme rassurant.
Du coup, certains essayent d'être encore plus précis quand ça marche pas bien.
T'es encore mieux anticipé, d'économiser le temps de chacun en limitant encore plus les interactions.
Sauf que, comme le précise le manifeste,
les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
Auto-organisation.
Une équipe auto-organisée s'organise elle-même.
Derrière ce trisme se cache une idée très puissante.
Ce sont les collaborateurs au contact du terrain qui sont les mieux placés pour savoir ce qui est à faire et comment le faire.
Fini les grands plans théoriques, on réfléchit à même le terrain.
L'auto-organisation implique d'ailleurs une autre idée.
La responsabilité collective.
Ce n'est plus un chef qui est responsable, mais toute l'équipe.
Ni le coup, s'il y a quelque chose à faire, juste fais-le.
Faut comprendre un point important.
Si je donne la responsabilité à quelqu'un, si je nomme quelqu'un responsable,
des facto, je déresponsabilise les autres.
Du coup, si je veux impliquer tout le monde, la première étape est de responsabiliser tout le monde.
Ces notions sont un peu perturbantes et flippantes surtout pour le manager d'avant.
Qu'est-ce qu'il va devenir dans cette nouvelle manière de voir le monde ?
C'est simple, il est au service de l'équipe.
Il met en place le contexte qui permet la performance, puis il laisse faire.
Émergence.
Autre point important, on laisse émerger les choses.
Le design, le fonctionnement de l'équipe, le produit.
Inutile de chercher à tout anticiper.
Mieux vaut adapter les choses au fur et à mesure.
De toute façon, l'environnement est devenu tellement changeant
qu'anticiper devient un gaspillage d'énergie.
Mieux vaut mettre son énergie à préparer le changement,
à se tenir prêt pour l'accepter quand il survient.
Ainsi, je ne cherche pas à concevoir tout en amont.
Grâce aux TDD, je peux concevoir au fur et à mesure de mes besoins.
Je conçois pour aujourd'hui et se faisant je prépare demain.
Grâce aux retrospectives, je collègue du feedback sur le fonctionnement de l'équipe
et elle s'améliore en continu.
D'ailleurs, c'est l'objet du prochain épisode.
Si tu as apprécié ce podcast, je t'invite à nous rejoindre sur artisan-dev.fr
Si tu l'as vraiment apprécié, si tu peux prendre 2 minutes pour mettre 5 étoiles sur iTunes,
ça sera super parce que ça permettra de diffuser le podcast et de le faire monter dans les rankings.
Je te remercie et je te dis à demain.