L’agilité ou la malédiction de la simplicité

L’organisation Vs. La valeur pour le client

Nous sommes dans une grande entreprise, dans une réunion assez tendue dans des bureaux feutrés à Paris. Participent le « Chief Digital Officer » (yeux au ciel), le responsable de la DSI, le responsable des développements logiciels, la responsable métier cliente de l’application, la directrice de programme MOA ainsi que votre serviteur, coach lean/agile de son état.

Le sujet est un projet stratégique pour l’entreprise (un extranet) et nous venons de terminer notre phase d’étude avec 3 mois d’avance et avec des niveaux de qualité et de satisfaction des collaborateurs inédits dans cette organisation (voir la présentation de l’étude de cas dans #hyperlean en action – le chapitre Obeya, Obeya, en route pour la joie). Le problème : le coût prévu de réalisation du projet est deux fois supérieur (disons 200) au budget prévu (disons 100). Enfin, le dernier projet équivalent avait un coût prévu de 100 et a effectivement coûté 300, pour un niveau de qualité qui a laissé la directrice de programme MOA plutôt circonspecte, et c’est un euphémisme.

Avec la directrice du programme MOA nous avons proposé auparavant au CDO de prendre le problème à l’envers pour la réalisation : constituer une équipe pluri-disciplinaire et autonome (une feature team en agile) qui présente un coût de 100 par an. On avance 3 mois et on fait un point d’étape avec l’ensemble des parties prenantes. L’approche du vénérable Taiichi Ohno selon laquelle on ajuste les coûts en fonction du prix et non pas le prix en fonction des coûts. Et on continue le cas échéant pour 3 mois de plus etc … Le CDO est emballé par l’approche et souhaite avec cette réunion, la « vendre » à la DSI.

Ce n’est pas si simple !

Le responsable des développements logiciel n’est pas très impressionné lorsque nous lui présentons l’approche :

• Ah mais ce n’est pas si simple !
• Et bien je ne sais pas, je réponds. Qu’est-ce qui nous empêcherait de tester cette approche ?
• Ah mais ce n’est pas comme cela que ça fonctionne ! Cela va complètement à l’encontre de la direction prise par la nouvelle organisation que nous avons mise en place.
• Oui mais cette organisation fonctionne-t-elle ? Le dernier projet qui devait coûté 100 et a couté trois fois le prix pour un produit dont la qualité est fortement discutable pose au moins la question coupe le CDO qui perd patience. Nos clients et partenaires n’en sont pas du tout satisfaits.
• Et qu’est-ce qui vous dit que ce que vous proposez fonctionne ? s’emporte le directeur du développement, soutenu par son DSI, que l’intervention du CDO a agacé
• C’est ainsi que fonctionnent les géants du numérique. Et j’ai mis cette approche en place chez un éditeur logiciel au niveau d’une équipe de 70 personnes. Nous avons divisé par 5 la non-qualité et par deux les délais (autre étude de cas de #hyperlean en action), ne puis-je m’empêcher de fanfaronner.
• Et puis avec cette approche, nous offrons chaque trimestre un espace de décision pour décider ensemble si on continue ou si on arrête, en fonction de la valeur livrée, ce pour un coût bien moindre et contrôlé renchérit la directrice de programme.
• Nous proposons simplement de cadrer les coûts pour rentrer dans le budget donné par Alice la responsable métier, j’ajoute.

En entendant son nom, cette dernière se réveille :

• Ah non moi je n’ai rien demandé de tel. Je m’alignerai sur le budget donné par la DSI !
• Mais cela ne marchera jamais ici, notre contexte est bien trop complexe ! coupe le directeur du développement
• C’est sûr que si on n’essaye pas, on ne saura jamais, je réponds du tac au tac, désabusé
• Cela suffit : vous n’avez aucune idée de la complexité et de nos contraintes. Nous n’avancerons pas avec cette proposition tranche le DSI.

Comme vous l’imaginez, la conversation ne s’est pas très bien terminée. J’en ai pris pour mon grade par la directrice de programme qui a fustigé, en partie avec raison, mon insolence et mon manque d’intelligence situationnelle. Bilan peu glorieux : j’ai été sorti par le client et le CDO a été remercié quelques semaines plus tard. J’ai appris par là-même deux-trois petites choses, notamment sur le besoin d’être davantage à l’écoute et moins brutal dans mes assertions ou encore sur le lien présumé que je faisais jusqu’alors entre avoir raison et capacité de conviction. Celui-ci semblait, tout à coup, beaucoup moins évident.

La malédiction de la simplicité

Très souvent, et comme dans l’exemple ci-dessus, je constate que lorsque l’on présente les principes et pratiques de l’agilité, notre auditoire est comme déçu. Celui-ci s’attend à des principes complexes qui vont challenger sa capacité d’abstraction et de projection.

Ils se retrouvent avec des grands projets complexes transformés en petits projets bien plus simples de 2 ou 3 semaines (les itérations) dans lesquels on se soucie bien moins de l’organisation que de la valeur client. Et ils ne comprennent plus dans quel but ni comment nous sommes parvenus à simplifier le champ d’attention. Réussir ensemble notre journée voilà un objectif qui leur semble bien trivial.

L’agilité nous montre que si on réussit nos 5 jours de la semaine, chaque semaine, on a des chances de réussir notre mois. Et si on réussit nos 6 mois on a des chances de réussir notre projet. En se concentrant en premier lieu sur la valeur livrée sur le client (premier principe agile), sur la réalité opérationnelle et les obstacles qui nous empêchent de réussir aujourd’hui plutôt que ceux qui pourront éventuellement apparaître dans 3 mois, en mettant en arrière-plan notre fascination pour l’ingénierie bureaucratique et organisationnelle et en clarifiant les conditions de réussite, on place l’équipe dans les conditions de la réussite.

The Knowing – Doing Gap

Dans The Knowing Doing Gap – How Smart Companies Turn Knowledge into Action, les professeurs de Stanford Jeffrey Pfeffer et Bob Sutton expliquent que, dans les grandes organisations, nous pensons que les idées simples sont des low hanging fruits, des fruits mûrs que chacun de nos concurrents a pu s’approprier. En conséquence, on estime qu’elles ne représentent pas de valeur ajoutée. L’objectif est alors de concevoir des idées complexes au niveau de l’organisation car celles-ci seront alors difficilement imitées, ce dans le but de développer un avantage concurrentiel.

Mais les auteurs expliquent qu’il y a une hypothèse incorrecte au cœur de cette fausse croyance : ce qui est difficile à imiter ce n’est pas ce qui est difficile à comprendre mais ce qui est difficile à mettre en œuvre. Et comme les managers travaillent chaque jour bien plus avec des idées qu’avec la réalité opérationnelle, ils perdent de vue cette évidence.

Agilité et réalité

Ainsi les pratiques de management agiles ne sont pas difficiles à comprendre mais elles sont difficiles à mettre en œuvre. Je donne toujours l’image d’arrêter de fumer. C’est très simple à comprendre (on arrête de porter des cigarettes à sa bouche) mais ce n’est pas parce que c’est simple que c’est facile. C’est difficile à faire : il faut arrêter à tous les moments de la journée (au café, après le repas, à l’apéro), à chacune de ces occasions où nous sommes tentés.

Avoir une vision claire sur les critères de réussite de la journée nécessite du travail et est difficile. Entendre pour comprendre les obstacles qui empêchent l’équipe de réussir et l’aider à les surmonter, chaque jour, est difficile. Mesurer l’impact de nos contre-mesures pour les valider est difficile. Définir ensemble des unités d’œuvre à la bonne granularité (quelques jours de développement), qui représentent de la valeur pour le client et pour lesquelles l’ensemble de l’équipe a une compréhension partagée est difficile. Intégrer l’ensemble des nouveaux développements et composants pour les tester chaque jour est difficile. Intégrer au plus près, chaque jour, les contraintes de tous les métiers qui contribuent à l’équipe est difficile. Valider au plus tôt auprès du client que les incréments de produit qu’on lui livre apportent de la valeur est difficile. Valider en continu les performances (temps de réponses, volumétrie) de notre système est difficile.

C’est difficile car cela nécessite de se confronter à une réalité revêche qui se moque bien de nos belles croyances et de nos belles idées. Voir ce billet « L’agilité : une confrontation quotidienne à la réalité » qui avance comme hypothèse que nous, professionnels du 21éme siècle, n’avons pas le pied marin pour la réalité. Et met en point d’orgue cette citation du philosophe Matthew Crawford, tirée de son ouvrage Contact – Pourquoi nous avons perdu le monde et comment le retrouver :

« La liberté et la dignité du moi moderne supposent qu’il soit isolé par rapport aux aléas du réel par plusieurs couches de représentation.»

Le festival SAFe

Qu’à cela ne tienne : il y a SAFe. La passion pour la complexité inutile peut à nouveau s’exprimer dans ce cadre que nous pensions préservé jusqu’alors : l’agilité. Lire à ce sujet ce bel article sur SAFe vu comme la « revanche des PMOs ».

En toute transparence, je ne connais que peu de choses de ce framework de passage à l’échelle de l’agilité (je connais bien mieux le modèle Spotify que j’ai mis en place chez un éditeur logiciel). J’ai assisté à une présentation d’une heure trente au terme de laquelle la consultante nous a présenté une étude de cas de mise en œuvre. Cette dernière était ravie de nous expliquer que la mise en œuvre avait réussie chez son client : SAFe était en place. Comme s’il s’agissait là de l’objectif du projet. Aussi s’est-elle rembrunie lorsque j’ai posé des questions sur le problème que SAFe devait résoudre, la valeur livrée au client ou encore la qualité de la solution livrée. Elle n’en n’avait pas la moindre idée. Ce que met en perspective cette conversation hilarante sur Twitter, lancée par John Cuttler. Il n’est pas interdit de penser qu’il s’agit là d’une des raisons derrière le recentrage de SAFe 5.0 (c’est tellement compliqué que ça a besoin d’un gestionnaire de version !) autour du client.

Si l’on regarde les retours des experts sur le sujet, tels que Dave Thomas ou Martin Fowler (qui le surnomme « Shitty Agile For Enterprise ») on ne peut pas dire que ce framework soit en odeur de sainteté auprès des signataires du manifeste. On identifie parfois cela à du conservatisme de vieillards dépassés. C’est une hypothèse. Une autre hypothèse est que, peut-être, ils savent de quoi ils parlent lorsqu’ils parlent d’agilité : ils en font depuis 20 ans.

Un autre élément qui pose question est le suivant : aucun géant du numérique n’a déployé SAFe dans son contexte. Ce que l’on nous répond alors (dans ce même article) c’est qu’ils n’en n’ont pas besoin, ils sont déjà agiles. Ils n’ont donc pas besoin de passer à l’agile. L’histoire récente nous a montré que si ces entreprises iconiques font le choix de ne pas s’engager dans une direction éminemment structurante, cela vaut le coup d’y réfléchir à deux fois avant d’y engager son entreprise.

Passer à l’échelle ce qui ne fonctionne pas

Cela m’évoque une conversation que j’avais eue au sujet des plateformes collaboratives il y a une dizaine d’années. Un des protagonistes (dont je ne retrouve pas le nom, désolé) demandait ainsi : « à quoi cela sert-il de passer la collaboration à l’échelle de l’entreprise avec ces outils, s’il n’y a pas déjà une culture de la collaboration au sein de plusieurs équipes ? Qu’allez-vous donc passer à l’échelle ? ». Une question salutaire en effet. Qui rejoint le point de Dan Jones, le père du management Lean, au sujet des systèmes d’entreprises qui inscrivent dans le marbre de solutions numériques coûteuses des processus qui ne fonctionnent pas.

Et s’il y a déjà une culture de l’agilité suffisante, alors on verra que l’ingénierie organisationnelle de SAFe est davantage un obstacle qu’un facilitateur. Car SAFe va à l’encontre du principe de simplicité de l’agilité.

On nous dit enfin que SAFe est un framework et que l’on peut y choisir ce que l’on souhaite. En ce cas ce n’est pas un outil de l’ère du numérique car ceux-ci ne proposent à leurs utilisateurs que ce dont ils ont besoin pour en faciliter l’adoption et l’utilisation et pour épargner une friction inutile. Ils ne proposent pas 816 pages de référence utilisateur.

Nul doute que les amoureux de la complexité dans les DSI y trouvent leur compte pour ce qui est de complexité. Nous échangions avec Yannick Grenzinger à ce sujet sur LinkedIn il y a quelques semaines. Il me demandait comment on pouvait expliquer le succès de SAFe. Je pense que nous avons ici des éléments de réponse.

La sous-culture de l’ingénieur

Dans Organizational Culture and Leadership, probablement l’ouvrage le plus important sur le sujet de la culture d’entreprise, le vénérable Edgar Schein (qui fut le premier à parler de corporate culture, dès 1952) avance qu’il existe trois sous-cultures génériques et transverses que l’on retrouve dans toutes les organisations : celle des dirigeants, celles des opérateurs et celles des ingénieurs. C’est cette dernière que nous voyons ici à l’oeuvre. Cette culture porte la vision de machines élégantes et de processus parfaits, la culture de l’abstraction et de la précision et un soupçon permanent envers les individus, qui représentent le problème. Dan Jones parlait ainsi au Lean Summit de 2016 de la volonté des entreprises de “engineer the people out of the process” .

Mon hypothèse est qu’avec le numérique et le besoin d’être au plus près des attentes des clients et de créer un contexte épanouissant pour les collaborateurs, les géants du web se sont éloignés de cette culture d’ingénieur pour se rapprocher de la culture des opérateurs. Même Elon Musk est en train d’y revenir pour son usine Tesla.

SAFE : the agillity billion dollar disaster ?

Cette culture de la complexité a représenté des coûts vertigineux dans le monde du numérique. Ainsi l’avènement des langages de programmation orientés objet, un eldorado pour les fans de l’abstraction, qualifié de Trillion Dollar Disaster par Ilya Suzdalnitski.

Ou encore ces aberrations d’architectes que sont les plateformes Java Entreprise et leurs composants logiciels EJB qui ont suscité, malgré (ou plutôt, en raison de) leur incroyable complexité un engouement spectaculaire au début des années 2000 : on ne compte plus les catastrophes industrielles développées autour de ces solutions (dont le précédent projet de l’entreprise évoquée au début de l’article). Pour vous donner une petite idée, la startup InFusio que j’ai rejointe en 2004 a décidé, pour résoudre des problèmes de performance, de se débarrasser des ces composants pour une architecture plus légère. Nous avons ainsi multiplié par 30 (TRENTE) les performances du système. Des dérives critiquées par l’ouvrage Bitter EJB de Bruce Tate dès 2003 et l’éminent Joel Spolsky en 2008 dans son célèbre article contre les Architectes Astronautes. Je vois bien SAFe devenir le agility billion dollar disaster.

Simplifiers and complexifiers

Nous avons chacun notre façon grossière de catégoriser les personnes. Je partage celle de Scott Berkun : il y a les simplifiers et les complexifiers. En ce qui me concerne j’ai choisi depuis bien longtemps mon camp.

Comment vendre la simplicité ?

En résumé, voilà la question principale. Comment convaincre des vertus de la simplicité dans un monde économique dans lequel on valorise la complexité ? Comment revenir à la simplicité de la valeur livrée au client, de la satisfaction des collaborateurs, de la suppression du travail inutile ? Comment revenir à ces principes agiles qui ont fait leur preuve et qui sont à la source de la formidable réussite des géants du numérique et de la transformation vertueuse des métiers de l’IT ?

Comment éviter de perdre le sens de notre travail et de nos missions dans cette complexité inutile et coûteuse ?

Comment faites-vous dans votre contexte pour remettre la simplicité à l’ordre du jour ?

Je conclus par cette magnifique citation de Edsger W. Dijkstra trouvée sur le profil LinkedIn de Kevin Lecouvey :

“Simplicity is a great virtue. But it requires hard work to achieve it and education to appreciate it. And to make matters worse : complexity sells better”.