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 soit disante 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 tous le monde”. Ce n’est pas de leur faute si tous 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.

Digressons une petite minute
Que faut-il pour que les développeurs le fassent ?

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.

Mais nous digressons

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 TEC1, 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”2

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.

Qu'est-ce que nous pouvons faire à ce sujet, Ron ?

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 inadvertence 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 Agile3 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

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


Licence Creative Commons
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.


  1. TEC = travail en cours ou en anglais WIP = work in progress - NdT 

  2. Malheureusement, ce n’est pas limité uniquement à l’Ohio. 

  3. Sera peut-être traduire prochainement ;)  2 3 4