Quand les managers deviennent architectes de la transformation Lean à l’échelle (Partie 2)

Dans le premier article, nous avons montré comment les managers, dans le but de comprendre en profondeur la situation actuelle, ont mené les actions suivantes : clarifier leur problème en le définissant sous forme chiffrée ; confronter leur perception aux faits du terrain en regardant les pièces et le processus ; analyser les données pour comprendre en profondeur la situation actuelle.

Disposant d'une compréhension aiguisée de la situation, les managers peuvent maintenant s’engager sur une cible claire et mesurable. C’est le moment où le raisonnement évolue : on pourra formuler des hypothèses, expérimenter, mesurer et apprendre : l’A3 cesse alors d’être un cadre d’analyse pour devenir un moteur d’action maîtrisé.

Nous vous proposons, dans cette deuxième partie, de voir comment le manager devient alors un vecteur de diffusion du Lean.

S’accorder sur la cible

Dans cette partie, on définit la cible à atteindre, l’objectif chiffré qui donnera une réponse claire à la question : “notre problème est-il bien résolu ?”. Ici, pas de phrase interprétable, mais un objectif chiffré.

Voici les challenges que se sont donnés les managers dans notre retour d’expérience :

• Yasmina sait pouvoir diminuer de 25 % les tickets d’incidents en réduisant de moitié les incidents liés à des problèmes de “build”, de mauvaise qualification et de paramétrage.
• L’analyse de la situation actuelle a permis à Jérôme de pouvoir afficher une cible de 100 % d’Epics inférieurs à 120 jours de Lead Time, et une amélioration du delivery de 30 %.
• Christian, lui, propose de diminuer de 30 % la charge de RUN en travaillant spécifiquement sur la réduction de 50 % des temps passés sur l’ajout de métriques, et en améliorant la qualité entrante des demandes.
• Enfin, Mathieu annonce pouvoir diminuer de 45 % le nombre de tickets entrants en diminuant les demandes de création de base et de gestion de droits, et en divisant par 2 les demandes d’exécution de scripts.

Définir une cible claire et chiffrée, basée sur une compréhension parfaite de la situation actuelle, permet d’orienter la recherche de causes racines, de cadrer les contre-mesures à envisager et de donner un critère clair de réussite. Cela permet aussi quelque chose de plus grand : donner au manager la capacité de guider le changement de manière intentionnelle, ce qui devient un acte de leadership Lean. Le manager ne subit plus la performance : il formule une ambition mesurable et engage, de façon transparente, un objectif auprès des équipes et de l’organisation.

Identifier les hypothèses de causes

La situation est maintenant claire, nous allons maintenant pouvoir faire des hypothèses de causes. Dans cette étape de l’A3, l’idée est d’imaginer les causes pouvant mener à la situation observée, pour aller les valider sur le terrain. Cette partie est le pivot entre la définition du problème, l’analyse de la situation et les propositions de contre-mesures.

L'hypothèse de causes est l’ossature du raisonnement PDCA. On cherche ici à répondre à la question “pourquoi le problème existe ?”, pour nous protéger de la “solutionnite”. Pour réaliser cette étape, on va devoir 1/ imaginer les causes possibles, 2/ les confronter aux faits du terrain (observation directe, mesures, entretiens), et 3/ utiliser des outils pour aller chercher des causes racines (5 Pourquoi, diagramme d’Ishikawa, Pareto, etc.).

Une hypothèse non testée n’est qu’une opinion.

Yasmina

Ainsi, Yasmina a fait les hypothèses suivantes :

• Les clients internes ne sont pas formés aux outils de paramétrage. Après interview de 3 d’entre eux, cette hypothèse est donc validée ⇒ ✅
• Il n’y a pas de documentation : vérification faite, les documents existent bien ⇒ ❌
• La documentation n’est pas à jour : vérification faite, il se trouve que la documentation est à jour ⇒ ❌
• La documentation n’est pas connue : quelques interviews ont montré qu’en effet, aucun des demandeurs ne connaissait la documentation ⇒ ✅
• Le paramétrage est fait directement en production, et peut donc engendrer des problèmes : un vis ma vie avec un collaborateur montre en effet que cette pratique est courante ⇒ ✅
• Les règles métiers ne sont pas suffisamment bien décrites en entrée : cette hypothèse est rejetée car pas assez significative. Un seul ticket était touché sur les 30 analysés pendant le Gemba ⇒ ❌
• Les critères de qualité en entrée et sortie ne sont pas définis : en effet, lors d’un Gemba avec l’équipe, cette dernière n’a pas pu nous montrer de DOR ou DOD ⇒ ✅
• Livraisons trop volumineuses, difficiles à tester : en effet, la dernière MEP regroupait une trentaine d’évolutions ⇒ ✅

Jérôme

Pour améliorer son lead time et son delivery sur ses Epics, Jérôme, de son côté, a fait les hypothèses suivantes :

• Manque de pilotage : on commence le mûrissement avant de savoir si on a du temps pour enchaîner le build (flux poussé). Hypothèse validée par l’analyse de 14 Epics longues dont 6 ont passé plus de 40 jours entre la phase de mûrissement et le début de la réalisation ⇒ ✅
• Il y a beaucoup d’Epics abandonnées : hypothèse rejetée après le Gemba montrant qu’une seule Epic a été abandonnée sur les 3 derniers mois ⇒ ❌
• Le mûrissement est parfois fait trop en profondeur par rapport aux besoins réels de l’équipe : l’interview des équipiers a montré que cette hypothèse n’était pas vérifiée ⇒ ❌
• Les nouveaux développeurs offshore de l’équipe peinent à monter en compétence : l’analyse des tickets traités par ces équipiers montre que c’est le cas ⇒ ✅
• Absence de stratégie pour la montée en compétence des équipiers offshore : le Gemba pour comprendre ce qui a été mis en place pour leur intégration montre qu’il n’y a, en effet, pas de plan pour les aider sur ce sujet ⇒ ✅

Christian

Concernant Christian et sa charge de RUN trop élevée, les hypothèses étaient les suivantes :

• Pas de documentation pour les utilisateurs : invalidée, nous l’avons trouvée ⇒ ❌
• Documentation non exploitable : la documentation semble être un peu longue à lire, quelques interviews ont permis de confirmer le fait que les demandeurs préféraient faire une demande de mauvaise qualité, quitte à y avoir des allers-retours, plutôt que de “lire cette doc imbuvable” comme l’a qualifiée l’un d’entre eux ⇒ ✅
• Les utilisateurs n’ont pas connaissance de la possibilité de tester localement leurs métriques avant de lancer la demande à l’équipe : hypothèse validée là aussi par une interview ⇒ ✅
• Les utilisateurs ne savent pas comment nous contacter pour poser leurs questions en amont des demandes : quelques interviews de personnes ayant réalisé des demandes KO ont montré qu’ils savaient comment contacter l’équipe, mais qu’ils pensaient leur demande OK (donc pas besoin de contacter l’équipe) ⇒ ❌
• Le template de demande n’est pas suffisamment compris : hypothèse validée à l’unanimité ⇒ ✅

Mathieu

Enfin, Mathieu a pris pour hypothèses :

• Manque de maîtrise de la techno par les équipes clientes : hypothèse largement validée par la présence régulière d’anti-patterns sur les bases de dev et de test ⇒ ✅
• Les équipes n’ont pas moyen d'exécuter elles-mêmes les scripts : oui, les scripts sont sécurisés et soumis à des droits fins ⇒ ✅
• Les équipes n’ont pas envie de le faire elles-mêmes et préfèrent déléguer : hypothèse rejetée par quelques interviews montrant l'intérêt pour les équipes de pouvoir être autonomes et aller plus vite sur ces demandes ⇒ ❌

La partie “hypothèses de causes”, dans l’A3, est une activité demandant de la rigueur personnelle et collective. Elle montre l’intérêt de comprendre en profondeur un sujet avant de lancer des actions. À ce moment-là de l’accompagnement, il n’est d’ailleurs pas rare d'entendre des managers nous signaler qu’on n’a “toujours rien fait”, montrant ainsi la propension des personnes et des organisations à vouloir faire vite plutôt que de faire bien. C’est justement là tout l’enjeu de l’A3 : éviter les contre-mesures décidées à la hâte, qui s’avèrent souvent inefficaces ou superficielles, laissant de côté les causes profondes.

En impliquant les équipiers dans le raisonnement plutôt que leur donner des solutions, les managers entraînent leurs équipes et leur organisation vers une culture où les problèmes sont explorés en profondeur. En cela, ils deviennent les architectes de la transformation Lean.

Définir et appliquer les contre-mesures

Cette partie du A3 est (enfin, diront certains) le point de bascule entre l’analyse et l’action. C’est à ce moment-là que l'on transforme la compréhension profonde du problème en expérimentations concrètes.

Les contre-mesures que nous allons décider d’expérimenter sont des actions ciblées sur les causes racines rigoureusement identifiées. Elles participent à la philosophie d’apprentissage structurée du PDCA.

Yasmina

C’est ainsi que Yasmina a décidé de s’attaquer à ses causes validées :

• En travaillant sur la formation de ses clients via des formations et la simplification et la diffusion de la documentation.
• En standardisant le fait de tester les paramètrages sur un environnement de pré-production.
• En standardisant la DOR et la DOD afin d’améliorer la qualité des demandes de RUN
• Mettre en place un suivi précis des MEP pour vérifier que les pipelines sont livrés régulièrement, et permettre des livraisons plus petites de 2 ou 3 fonctionnalités maximum.

Jérôme

Jérôme a décidé :

• De mettre en place un pilotage opérationnel des unités d’œuvre en flux tiré, ce qui a engendré naturellement l’abandon de Scrum pour Kanban
• De standardiser les gestes de l’équipe les plus courants, de créer une matrice de compétences pour mettre en place la stratégie simple / complexe et piloter la montée en compétence des équipiers Offshore
• De standardiser la DOR d’Epic pour identifier clairement celles que l’on peut en effet réaliser

Christian

De son côté, Christian a travaillé sur :

• La documentation pour synthétiser les éléments importants et la rendre plus accessible pour les clients
• La réalisation d’une vidéo tutorielle pour montrer pas à pas comment faire une demande d’ajout de métrique de qualité, et comment pouvoir tester la métrique localement avant de faire la demande.
• La mise en situation des clients pour réussir à faire des demandes bonnes du premier coup en retravaillant le template en appuyant sur l’exposition, le nommage et la cardinalité (qui, pour rappel, représentent 58 % des demandes KO)

Mathieu

Mathieu a, lui, lancé des interviews pour vraiment comprendre et a décidé :

• De mettre en place des API pour rendre les clients autonomes sur l’exécution des scripts de manière sécurisée.
• De mettre en place un outil permettant d’offrir des services de modification des bases Mongo, en offrant d’abord les services de création d’index, puis de création d’utilisateurs, de collections, de bases.
• De créer un rôle de référent Mongo dans chaque direction, devant suivre une formation spécifique.
• De mettre en place un mentoring pour accompagner ces référents

Toutes ces actions sont des expérimentations que nous, coachs Lean, encourageons à tester rapidement, à moindre coût. Ces actions ne sont pas uniques et doivent être analysées afin d’apprendre et d’ajuster rapidement si besoin.

C’est ainsi que, par exemple, lorsque Mathieu a proposé un outil simple pour permettre aux autres équipes de créer des index MongoDB, la mesure du nombre de tickets n’a montré aucun impact. Des Gemba ont montré que les personnes n’étaient pas à l’aise et préféraient créer un ticket plutôt que de prendre le risque de mal faire. Quelques formations et démonstrations ont permis de passer cette étape.

Mais deuxième surprise : on a constaté une augmentation du nombre de tickets. Après un Gemba dans l’équipe, il s’avère que les personnes de son équipe ayant développé l’outil en question ont voulu mettre une limite à l’outil : si le nombre de lignes de la table est supérieur à 100 000, on ne fait pas l’action automatiquement et on crée un ticket à l’ancienne pour pouvoir vérifier.

La question de Mathieu : “Combien a-t-on de tables avec moins de 100 000 lignes ?”, réponse de l’équipe : “Heu… aucune ?”.

Après un moment de gêne, l’équipe a corrigé le tir, et a finalement relevé le niveau à 10 millions de lignes, ce qui était plus en phase avec la réalité du contenu des tables. Ils ont également découvert que l’outil créait un ticket par environnement, alors qu’auparavant, les utilisateurs créent un ticket unique regroupant les demandes pour les différents environnements. Ce qui multipliait encore les tickets.

Sans mesure et vérification sur le terrain, cette bonne intention aurait généré du gaspillage.

Quand un manager travaille sur cette phase du A3, il co-construit des contre-mesures avec son équipe et documente leur lien avec les causes pour les tester et les ajuster en s’appuyant sur des données. C’est là une phase indispensable de la résolution de problème et de la philosophie PDCA : chaque action est le fruit d’un raisonnement, pas d’une impulsion. Une pratique qui participe à faire du Lean, un langage commun dans l’entreprise.

Mesurer les résultats

Cette partie est en quelque sorte la gardienne de l’apprentissage, le juge de paix du processus de résolution de problème, l’ingrédient indispensable à la création de la connaissance validée. C’est le moment où on passe au Check du PDCA. On compare les résultats obtenus avec la cible souhaitée, on observe les écarts résiduels.

Cette phase "résultats" permet de mettre en avant la rigueur du Lean dans l’apprentissage et l’approche orientée données. On ne peut apprendre des efforts d’amélioration que si leur résultat est mesuré. Et cet apprentissage se fait, que le résultat soit celui attendu, ou non. C’est ce qui est précieux : dans tous les cas, on a quelque chose à apprendre.

Yasmina

Après 3 mois, Yasmina a pu faire le check de ses contre-mesures :

Le constat est sans appel :

• -56 % du nombre de tickets de RUN
• -70 % du nombre de tickets d’incidents

Jérôme

De son côté, Jérôme a mesuré une amélioration de 12 points des Epics livrées en moins de 120 jours, mais a surtout noté une évolution significative de son delivery, passé de 10 Epics par trimestre à 15, soit une amélioration de 50 %. À 18 personnes, cela représente 900 000 euros de valeur en plus par an.

Christian

Quant à Christian, il a observé une amélioration de 26 points de la qualité entrante, qui est passée de 42% de PR correctes à 68%. L’impact direct a été une diminution de 60 % du temps passé sur les sujets d’ajout de métriques, qui était son sujet principal. Le résultat financier a été mesuré, passant de 61 600 € par an à 28 400 €, soit une diminution de 54 %.

Au dela des 33 000 euros d’économie par an, c’est aussi 83 JH qui sont libéré pour pouvoir avancer plus efficacement sur la partie BUILD. Le délai médian pour ajouter une métrique a été divisé par 2, passant d’un peu plus de 2 jours à moins de 1 jour.

Mathieu

Enfin, Mathieu a constaté une chute de 65 % des demandes de lancement de script, et une baisse de 33 % du nombre de tickets de RUN.

Mathieu avait pour objectif de diminuer de 45 % les demandes. En analysant les données, Mathieu a décelé une information intéressante : la hausse des demandes de suppression d’index. Un effet de bord du fait d’avoir facilité leur création. Un nouveau sujet intéressant 🙂

Pour l’histoire, quelques mois plus tard, Mathieu nous a demandé d’accompagner l’ensemble de ses managers. La diffusion du Lean était en route.

Les résultats ne sont pas une conclusion. Ils sont une validation. Dans un A3, ils permettent de savoir si les actions ont eu un impact mesurable vis-à-vis du problème que l’on souhaitait résoudre. Lorsqu'un manager produit cette étape, il montre l’intérêt d’aller au-delà des actions. Il montre l’intérêt de la mesure de l’impact de ces actions. Une action mise en place n’a aucune valeur si on ne mesure pas son impact. Le manager incarne ainsi une exigence qui irriguera peu à peu toute l’organisation.

Enseignements

On entame ici la phase finale de l’A3. L’objectif ici est de transformer un exercice de résolution de problème en outil de capitalisation des apprentissages. C’est le moment où on crée le lien entre les actions menées, et les résultats obtenus. C’est la construction de ce qu’il y a de plus précieux dans le Lean : la connaissance validée.

Cette session a pour objectif de réfléchir à ce qu’on a appris :

• Si on atteint la cible : comment nous y sommes-nous pris ? Qu’en apprend-on ?
• Si on a réduit l’écart : qu’est-ce qui a empêché d’atteindre l’objectif totalement ? Quelles hypothèses sur ce que nous n’avons pas vu ? Qu’allons-nous expérimenter pour continuer ?
• Si on n’observe pas d’amélioration : pourquoi ? Quelles sont les fausses croyances qui nous ont induits en erreur et que les expérimentations et le manque de résultat mettent en avant ? Quelles nouvelles expérimentations devons-nous tester ?

Yasmina a principalement appris l’importance de la standardisation des décisions plutôt que de laisser les développeurs prendre des décisions sans aucun guide sur la réflexion. L’importance de passer du temps pour se mettre en situation de réussir, avant et après, avec des DOR et DOD pour améliorer la qualité des demandes.

Elle a également appris, avec Christian, l’importance de former ses clients pour diminuer le nombre de demandes ou améliorer la qualité de celles-ci.

Jérôme a été surpris par l’efficacité du pilotage opérationnel pour focaliser le champ d’attention de ses équipes. Il a également appris l’intérêt du flux tiré pour permettre la clarification des conditions de réussite de chaque sprint, chaque semaine, et chaque jour. Il a compris comment faire monter en compétence ses équipiers, et comment piloter cette montée en compétence avec une stratégie simple / complexe. Et lui aussi a compris l’intérêt de passer du temps sur le fait de se mettre en situation de réussite via des DOR d’Epic.

Enfin, tous les managers, et Mathieu en particulier, ont appris que mettre une action en place n’est pas suffisant, et que faire le check apporte une opportunité de rebondir sur de nouvelles connaissances pour aller réellement chercher l’impact. À ce stade, le problème initial a presque disparu. Ce qui a grandi, c’est la capacité à apprendre.

Ancrer le Lean dans le management quotidien

Diffuser le Lean dans une large organisation ne consiste pas à déployer des outils supplémentaires, mais à installer une culture exigeante de résolution de problème. Cela commence par une clarification essentielle : qu’est-ce qu’un problème ? Non pas une plainte, ni une opinion, mais un écart mesurable par rapport à une performance attendue. En s’appuyant sur la rigueur du raisonnement analytique (le système 2 de Kahneman), le manager apprend à ralentir, à questionner et à engager ses équipes dans un véritable apprentissage plutôt que dans une réaction immédiate. C’est ainsi que la culture Kaizen prend racine : par la compréhension, pas par l’agitation.

L’A3 devient alors bien plus qu’un support : c’est un cadre de structuration de la pensée managériale. Il oblige à formuler les faits, à rechercher les causes profondes, à tester des contre-mesures et à vérifier les résultats avant de standardiser. En raisonnant selon la logique PDCA, le manager développe une discipline intellectuelle qui sécurise les démarches d’amélioration. Il ne “lance” plus des actions ; il conduit des expérimentations. Ce changement de posture est déterminant : il crédibilise la transformation et installe un leadership par l’exemple. Un manager qui mène ses propres A3 incarne l’apprentissage continu et encourage, par son comportement, ses équipes à faire de même.

Enfin, l’A3 crée un langage commun qui relie le terrain à la stratégie. Parce qu’il rend explicites les hypothèses, les décisions et les résultats, il facilite l’alignement vertical des priorités et évite le Kaizen isolé, déconnecté des enjeux business. Lorsque chaque niveau hiérarchique s’approprie cet outil, la ligne managériale devient le moteur du changement. Le Lean ne repose plus sur quelques experts ; il s’ancre dans le management quotidien. Et c’est à ce moment-là que l’amélioration continue cesse d’être un programme… pour devenir une culture vivante.