Connexions, 'Transformation', Développement agile de logiciels

Les transformations agiles n’ont rien à voir, ou alors très peu, avec le développement agile de logiciels. Permettez-moi donc de vous donner quelques tuyaux. Ce qui suit est une diatribe en quelque sorte …

Le message fondamental derrière cette phrase et les articles présentés en bas de page est, quand bien même, l’arrivée des idées “agiles” peuvent améliorer la performance d’une entreprise, elles ne vont sans doute pas transformer en profondeur l’entreprise, et elles n’amélioreront pas, de manière quasi certaine, ni la production logicielle ni les vies des développeurs informatiques.

L’article Connexions - de l’insuffisance du leadership en 15 phrases et quelques images souligne un élément clé qui va dans le sens de cette conclusion : tout message qui émane des dirigeants de l’organisation sera inévitablement corrompu lorsqu’il atteindra les opérationnels. C’est quelque chose de fondamental, d’inévitable et qui résulte de la théorie de l’information. Nous faisons tous de notre mieux pour éviter ce problème, en raccourcissant les lignes de communications, en soignant la rédaction de nos messages, et ainsi de suite, mais même en y prêtant la plus grande attention, cela se produit tout de même.

Ce qui est encore pire c’est le fait que quasiment aucune des personnes qui font de la formation ou du coaching en “Leadership agile” n’ont pas une compréhension réelle de ce qu’est le développement logiciel, et encore moins des pratiques relativement récentes à appliquer pour une Vraie Agilité™. Comme ces personnes ne les connaissent pas, elles ne peuvent pas infuser cette information au niveau des dirigeants de l’organisation, donc ces derniers n’essayent même pas de les diffuser.

Certaines soi-disant approches de “transformation” font la moue sur ce sujet. Par exemple, SAFe requiert l’utilisation de “Scrum plus XP” au niveau opérationnel, et indique sur un certain nombre de diapositives de leurs présentations la mention “Former tout le monde”. Ce n’est pas leur faute si tout le monde n’est pas formé.

Il y aussi en jeu le fait qu’il n’y a pas beaucoup de gens qui soient capables de montrer à des développeurs comment faire ce qui est nécessaire pour bien faire sous le parapluie “Agile”. Il y a des personnes compétentes ici et là, et du bon contenu sur le web mais c’est déjà un peu trop tard pour la plupart des développeurs.

Ce ne pas vraiment en lien direct, mais fondamentalement, pour arriver à la Vraie Agilité™, les développeurs doivent être organisés afin que l’équipe soit en mesure de produire un “Incrément” régulièrement, toutes les semaines ou toutes les deux semaines, qui puisse être compris par les gens du métier et les clients qui en ont besoin. Les développeurs doivent aussi posséder la compétence technique pour produire cet incrément, et cela inclus des pratiques techniques que la plupart des développeurs n’ont pas encore été confrontés.

Sans ce support organisationnel et éducatif, le développement ne sera jamais Agile, et par conséquent l’entreprise ne sera jamais Agile.

Dans cet intervalle, l’entreprise dans son ensemble en tirera tout de même profit. Cela viendra, tout d’abord, sous la forme de lignes de communications plus courtes, et en particulier en appliquant les principes Lean sur la production du produit. Ces principes vont limiter le TEC¹, ce qui va permettre de travailler uniquement sur les choses les plus importantes d’abord. Ils vont rationnaliser le processus de décision et ainsi de suite.

Il s’agit de bonnes choses, et même de grandes choses. Faites avec diligence, l’entreprise en bénéficiera, et souvent de manière radicale. Il est important d’y travailler davantage, et les processus de décisions seront plus fluides. De bonnes choses se passent.

Néanmoins, l’entreprise ne sera pas Agile. Une entreprise ne peut faire de la Vraie Agilité™ tant que ses équipes de développement n’en font pas.

Et parce que les équipes de développement ne sont pas formées à ce qu’est l’Agile ; elles ne peuvent pas par conséquent travailler en mode Agile, ce qui aura le plus souvent pour conséquence qu’elles seront soumises à davantage de pression qu’avant, c’est ce que j’appelle le Dark Agile™ et se retrouver dans les “Mines de Code de l’Ohio”²

Toutefois, je ne suis pas sûr que cela soit de l’ironie ou de la tragédie. Je ne sais jamais trop lorsqu’on parle d’ironie. Mais quoi que cela puisse être, je trouve cela triste que sous la bannière d’“Agile”, que de bonnes idées, souvent mais pas toujours emprunté à Lean, se traduisent par mettre les développeurs dans une mauvaise posture, et ne produisent pas les bénéfices que la Vraie Agilité™ promet et peut donner.

Un jour, un idiot a dit “Donnez-moi des solutions, pas des problèmes”. Il n’a plus jamais entendu parler des problèmes après coup, et j’espère qu’il est tombé par inadvertance dans des oubliettes. Plus probablement, il a dû se sauver à temps et commettre d’encore plus grosses bêtises par la suite.

Quoi qu’il en soit, je ne connais aucunes bonnes solutions. Mon article Abandon Agile³ est une vraie tentative pour répondre à la question. Les développeurs ont besoin de reconnaître cette chose appelée “Agile” qu’ils rencontrent, et qui très probablement ne les aidera pas, mais qu’ils peuvent néanmoins faire grandir de l’intérieur s’ils apprennent ne serait-ce qu’un chouia à propos de comment produire un Incrément, et sur les sujets connexes.

Il y a sûrement besoin de plus, de beaucoup plus. Je ne sais pas de quoi il s’agit, ou comment le faire. Le maximum que je puisse faire aujourd’hui est de crier un avertissement.

La quasi-totalité de ce site est dédié à ce sujet. Voici quelques liens sur quelques petites choses auxquelles vous voudriez jeter un coup d’œil.

Articles en relation

• « Le business Agile » : Construit sur du sable
• Connexions - de l’insuffisance du leadership
• Connexions - Du logiciel pour tous
• How to Impose Agile³
• Les développeurs devraient abandonner l’« Agile »

Catégories d’articles en relation

• Dark-Scrum (vo, vf)
• Pratiques (vo, vf)
• SAFe (vo uniquement)
• Nouveau cadre de travail de développement logiciel (vo, vf)

Auteur : Ron Jeffries
Source : Connections, ‘Transformation’, Agile Software Development
Date de parution originale : 27 Novembre 2018

Traducteur : Nicolas Mereaux
Date de traduction : 12/12/2018

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.