Merci de rendre au premier principe agile ce qui lui appartient

Lorsqu’il existe des tensions avec les équipes agiles que j’accompagne, je n’ai de cesse de revenir au premier principe agile. Il s’agit d’une « botte secrète » que m’a fait découvrir Marie-Pia Ignace alors que je maugréais sur le manque de focus valeur d’équipes agiles que j’accompagnais.

Elle me demanda : « Cecil, Quel est le premier des douze principes agiles ? » Ne sachant pas répondre et me présentant comme un expert agile, je me trouvais bien ballot. Après m’avoir laissé ruminé quelques minutes (nous préparions l’Obeya hebdomadaire de Operae Partners) elle me répondit avec un sourir malicieux : « Satisfaire le client en livrant rapidement et de façon continue du logiciel de valeur ».

Comme bien souvent avec les nombreuses sessions de coaching que j’ai eues la chance d’avoir avec Marie-Pia, je vis soudainement la lumière.

Douze principes agiles (en V.O)

Lors de leur réunion dans la station de ski de Snowbird en février 2001, les 17 participants ont défini leur manifeste en quatre points (que je n’utilise jamais pour présenter l’agile) ainsi que douze principes. Je vous invite très fortement à aller la voir la version originale car dans les versions traduites, j’observe qu’on a perdu pas mal de sens. [Pro-Tip : c’est exactement pour cette raison que je mène toutes mes recherches méthodologiques et professionnelles en anglais.]

Premier principe agile (en anglais)

Le premier principe agile est donc le suivant. Chaque mot a son importance :

« Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. »

Ce que l’on va traduire le plus fidèlement possible par :

« Notre plus haute priorité est de satisfaire le client avec une livraison rapide et continue de logiciel de valeur. »

Prenons maintenant un instant pour analyser les traductions françaises de ce premier principe.

Premier principe agile (en français)

Pour réfléchir à ce sujet, nous commençons comme d’habitude par aller sur le terrain, le fameux Gemba du Lean, pour y chercher des éléments factuels et spécifiques. En l’occurence il s’agit ici d’une recherche Google du 17 octobre 2022 aux environs de 09:00 du matin. Cette recherche des « douze principes agiles » retourne les exemples ci-dessous, dans l’ordre d’apparition de la première page de la recherche.

SoftFluent : « Prioriser la satisfaction client ». Suivent deux paragraphes comportant en tout 97 mots. Pas une seule fois logiciel (capture d’écran).

One2Team : « Satisfaire les clients en priorité ». Pas de détail supplémentaire (capture d’écran).

Blog gestion de projet : « Livrer de la valeur aux clients », suivi de 34 mots explicatifs, sans une seule fois parler de logiciel – même si on retrouve le terme “développement” qui évoque davantage un processus qu’une valeur opérationnelle (capture d’écran).

Réussir ses projets : « Satisfaire ses clients en priorité » : semble avoir les mêmes sources que One2Team. (capture d’écran)

Scrum League.org : « Satisfaire le client en priorité », on notera que l’on a perdu le pluriel de clients et on a gagné de nombreux encarts publicitaires pour des formations. (capture d’écran).

Agile Manifesto.org/fr : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. » Làs, nous.fr avons perdu, à la source, la notion de « Software » (capture d’écran).

Smartsheet.fr : « Satisfaction des clients grâce à la livraison précoce et continue des logiciels ». Hourrah ! Nous retrouvons enfin le mot “Logiciel” (capture d’écran). Ne nous enflammons pas, il semble s’agir d’une traduction automatique, l’autrice s’appelant Kate Eby.

TalentGarden.org : « Satisfaire le client grâce à une livraison précoce et continue ». Semble être inspirée de smartsheet et l’URL laisse aussi à penser qu’il s’agit d’une traduction automatique. Reste que contrairement au cas précédent, un être humain a manifestement modifé le contenu pour supprimer le mot logiciel de l’intitulé du principe, même si le terme « logiciel » apparaît dans le court texte explicatif (capture d’écran).

Wikipedia : reprend la définition de agilemanifesto.org : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

Ces neuf premiers exemples sont en tête du classement Google : on s’attendrait donc à ce qu’il s’agisse là des plus pertinents. Un seul énonce le terme « logiciel » et il semble manifestement s’agir d’une traduction automatique. Même la traduction officielle française (agilemanifesto.org) a traduit « software » en « fonctionnalités ».

1 sur 9 qui cite l’esprit originel, cela nous fait donc 11% de traduction OK. Je suis sûr qu’on peut mieux faire.

De quoi l’absence de « logiciel » est-elle le nom ?

Un collègue qui exerce dans une grande entreprise du CAC 40 m’a rapporté son étonnement de constater qu’un sein de l’équipe managériale qu’il accompagne, le logiciel est perçu comme quelque chose de “sale”, que l’on préfère éviter de toucher pour se consacrer davantage aux sujets “stratégiques”, organisationnels ou produits, qui semblent dans ce contexte rayonner de davantage de prestige.

On pourra retrouver ici un penchant prégnant de la culture d’entreprise française, décrit par l’ami Benjamin Pelletier dans son article inépuisable Culture du jugement et jugement de la culture.

« On retiendra essentiellement le contexte de très forte hiérarchisation des pratiques et des savoirs. Valorisation de l’intellectuel contre le manuel, du conceptuel contre le matériel, de l’idée contre la pratique, de l’esprit contre le corps, selon une rhétorique de l’élévation, d’un mouvement du bas vers le haut. L’homme qui se perçoit comme cultivé vivra souvent comme un rabaissement, voire une déchéance, s’il est obligé de se livrer à des tâches manuelles ou à des activités matérielles. On en arrive ainsi à cette absurdité de revendiquer son incapacité manuelle comme une forme de noblesse intellectuelle… »

Programmeur Jr

Cette négligence du « logiciel » pour les entreprises françaises qui veulent s’engager dans le numérique m’a toujours semblé très étonnante, un peu comme si les construteurs automobiles ne s’intéressaient pas à la mécanique pour ne consacrer leur effort de conception qu’à la carrosserie et l’habitacle.

Si cela m’agace, ce n’est pas seulement parce que j’ai démarré ma carrière en tant que programmeur junior ou parce que j’ai du mal à me contenir lorsque des managers parlent de “développeurs qui pissent du code”. C’est surtout parce que les modèles d’entreprises numériques (les géants du web) sont dirigés par des développeurs (Zuckerberg, Jack Dorsey, les frères Collison, Mullenweg et une centaine d’autres que j’oublie) ou des ingénieurs (Musk) [Note : nous parlons ici de modèles en termes de capacité d’exécution, pas en termes de contribution à la société] et que l’apriori stratégique qui consiste à penser sa transformation numérique sans prendre en compte la dimension d’ingénierie logicielle ne préfigure rien de bon (ce que nous constatons chaque jour sur le terrain ne tant que coachs).

Premier point dans l’Executive Summary

Le premier point de l’Executive Summary du State of Devops de 2014 explique ainsi que :

“Strong IT performance is a competitive advantage. Firms with high-performing IT organizations were twice as likely to exceed their profitability, market share and productivity goals.”

Il va falloir être très pédagogue pour m’expliquer comment on fait pour avoir des organisations IT très performantes (et très agiles) sans soulever le capot du logiciel. Chère communauté agile française, vingt ans plus tard, il est temps de rendre au premier principe agile ce qui lui appartient, et ce dont l’absence le fait souffrir (et nous avec).