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

Dans l’ouvrage Culture Kaizen, nous faisons des retours d'expérience sur plusieurs missions d’accompagnement d’équipes et de programmes agiles, dans lesquels nous détaillons les moyens mis en œuvre pour améliorer la performance de manière significative. Cependant, nous ne parlons que peu de la diffusion de ces pratiques au sein d’une entreprise ou d’une organisation. Que se passe-t-il quand nous voulons non plus lancer une démarche sur une équipe ou un programme, mais sur un domaine, voire une DSI ou une entreprise entière ?

Quand nous réfléchissons à la manière de s’y prendre, l’attention va naturellement se poser sur la ligne managériale. Dans la démarche Kaizen, celle-ci a un rôle clé : celui de la chaîne d’aide. Elle est là non seulement pour aider à la résolution des problèmes, mais aussi pour créer un système dans lequel chacun, chaque jour, est mis en situation d’améliorer les produits ou les processus de l’entreprise.

“D'après mon expérience, je dirais que 94 % des problèmes et des possibilités d'amélioration relèvent du système (responsabilité du management)”

Deming, W. Edwards. Out of the Crisis.

Lorsque l’on parle de diffuser une pratique, le passage par le management nous semble indispensable. Si de nombreuses transformations rencontrent des difficultés à produire des résultats durables, c’est rarement faute de méthode. Notre conviction est que cela est plutôt en raison d'un manque d’implication managériale dans le système d’apprentissage. Non pas par manque d’envie, de compétence ou de méthode. Et non, ce n’est pas non plus la “résistance au changement”, souvent invoquée pour expliquer les difficultés rencontrées. Les obstacles sont souvent dûs à un manque de clarté sur le système de travail et de soutien. Or ce soutien, comme la conception même de ce système, implique directement la ligne managériale, dont le rôle est parfois resté flou lors de certaines transformations agiles. Ce flou a généré de la frustration et des tensions, mises en lumière en 2019 par l’étude IPSOS « The End of Management as We Know It? » dans laquelle 81 % des managers interrogés déclarent leur rôle plus complexe qu’avant, et identifient l’agilité comme un facteur de cette évolution. Beaucoup expriment alors le besoin de clarifier leur rôle.

Il nous est régulièrement proposé d’intervenir après des projets de transformation. Cela nous permet de constater une chose : les problèmes, et donc les opportunités d’amélioration constatées sur le terrain, ne sont pas là où ces transformations agissent. Ces dernières omettent souvent de transformer le système de management. Concrètement, sur le terrain, il est commun d’observer des rétrospectives pendant lesquelles les équipiers produisent beaucoup d’idées, pour ensuite dire : “cette action n’est pas chez nous !”. Ce cas peut s’avérer être représentatif d’équipes en manque de soutien managérial, et probablement de managers exclus du système d’apprentissage. C’est pour cela que Toyota a proposé le Toyota Way : le système de management qui supporte le système de production (le fameux TPS) pour créer un système d’apprentissage global, cohérent et d'une efficacité maintes fois vérifiée.

"Trop de dirigeants pensent que le Kaizen est un ensemble d'outils destinés aux opérationnels. Au contraire, vous devez commencer par les trois éléments les plus importants : premièrement, l'implication du management, deuxièmement, l'implication du management, et troisièmement, l'implication du management."

Masaaki Imai

Méthode

Image de livre pour représenter la méthode.

Toyota a commencé à évoquer le Toyota Way en 2001 (en même temps que l’agilité). Cette réflexion sur le rôle du management est issue de 40 ans d’amélioration empirique du système de production afin de supporter le système d’apprentissage. Lorsqu’on entend parler de Lean encore aujourd’hui, il est souvent réduit à un système de production, mais c’est une vision réductrice. Le Lean est la combinaison du système de production ET du système de management qui le soutient.

C’est autour de ce modèle que nous organisons nos accompagnements de managers, pour que chacun d’entre eux incarne les pratiques du management Lean telles que définies dans le Toyota Way, organisées autour de deux piliers :

  • Continuous Improvement
    • Genshi Genbutsu : aller sur le Gemba (i.e. sur le terrain en observant des pièces terminées ou des problèmes rencontrés) pour comprendre la situation et créer une réalité partagée ;
    • Kaizen : coacher les collaboratrices et collaborateurs sur un sujet d’amélioration (avec le PDCA) ;
    • Challenge : challenger l’équipe pour creuser de nouveaux sujets, et ce faisant, développer de nouvelles compétences et améliorer la performance ;
  • Respect for People
    • Respect : demander « Pourquoi ? » (Le fameux Go See, Ask Why de Fuji Cho) : on veut présenter du respect aux équipes en portant attention à des sujets spécifiques et en utilisant le questionnement ouvert. Et le manager utilise son sponsoring pour dénouer des sujets qui sont hors du champ d’intervention de l’équipe.
    • Teamwork : encourager la collaboration transverse sur l’ensemble de la chaîne de valeur pour traiter des sujets complexes.

Le Kaizen se vit sur le terrain et l’apprentissage naît de la résolution concrète des problèmes opérationnels. Nous embarquons donc les managers avec nous dans le Lean, en privilégiant l’analyse de problèmes opérationnels, traités pas à pas au travers d’un A3 (standard de résolution de problèmes de Toyota). L’A3 devient alors le support concret de ces cinq axes : il nécessite d’aller sur le Gemba pour comprendre la situation, de challenger les faits plutôt que les opinions, de pratiquer le questionnement Kaizen, de travailler en équipe et d’exercer le respect en laissant les opérationnels construire les contre-mesures. Apprendre en faisant devient le fil conducteur.

Pour permettre au Kaizen de se diffuser durablement dans les organisations, nous accompagnons ainsi les managers dans la pratique de ces cinq gestes clés, structurés par la logique PDCA incarnée dans l’A3. L’outil ne sert pas à produire un document, mais à transformer la posture. C’est précisément ce changement de posture qui rend la diffusion du Lean possible. De responsables hiérarchiques, ils deviennent architectes du système d’apprentissage et coachs des équipes. C’est ainsi que commence la diffusion réelle du Lean : quand le management apprend à apprendre, publiquement, au service de la performance et du développement des personnes.

Retours d’expérience

Image d'une fiole pour représenter l'expérience (scientifique)

Pour illustrer au mieux l’embarquement de ces managers dans le Lean, et pour sortir du piège de la théorie, je propose de partager avec vous 4 accompagnements de managers de différents domaines (retail et banque), allant du manager de proximité d’une équipe de 8 personnes à un CTO, manager de plusieurs directions techniques (Data, Architecture, Cyber, etc.).

Tous pensaient avoir un problème opérationnel. Aucun n’avait encore formulé un problème de management. Embarquons ensemble avec :

  • Yasmina, manager d’une équipe de développement de 13 personnes
  • Jérôme, manager d’une équipe de développement de 18 personnes
  • Christian, manager d’une équipe de 8 personnes spécialisée dans l’observabilité
  • Mathieu, CTO avec 8 directions techniques, dont la direction Data sur laquelle se portera notre attention

Vous pouvez également retrouver le détail de l’accompagnement de François, qui a divisé par 3 le Lead Time de son équipe de delivery grâce à ce type d’accompagnement, dans cet article déjà publié.

Définir l’objectif d’amélioration

Image d'un point pointé par une flèche pour définir l'identification de l'objectif d'amélioration.

Avant de se lancer de façon trop abrupte dans la résolution de problème et les premiers éléments du A3, on va commencer par en définir l’en-tête. Au-delà du nom du porteur (ici, le manager) et de la date de la dernière mise à jour, c’est surtout le titre qui va nous intéresser, car il guidera l’ensemble des questions et des réflexions tout au long de l’A3. Que souhaitons-nous réussir ? Le risque ici est de confondre solution et problème à résoudre. Ainsi, on va éviter le “Supprimer Scrum pour passer en Kanban”, ou encore “Améliorer la communication dans l’équipe”. On va chercher à formuler le problème avec un verbe d’amélioration mesurable. Par exemple : “Diminuer le RUN”, “Améliorer la satisfaction client”, “Améliorer la qualité” ou “Améliorer la performance opérationnelle d’un processus”, etc.

Derrière chaque formulation imprécise se cache souvent une solution déguisée. Or un A3 ne commence jamais par une solution.

La qualité du titre conditionne la qualité de l’apprentissage.

Après questionnement, nous avons réussi à trouver un sujet d'amélioration pour chacun de nos managers :

  • Yasmina veut réduire la charge de RUN de son équipe
  • Jérôme souhaite livrer plus d’Epics et diminuer leur Lead Time
  • Christian veut diminuer le coût du RUN pour investir plus dans le Build
  • Mathieu aimerait moins de sollicitation de RUN pour son équipe Data

Définir le contexte

Image d'une carte routière pour représenter la définition du contexte

Ici, on va définir le cadre de la résolution de problème, donner du contexte sur l’équipe, son écosystème, et bien sûr : notre problème, qui en Lean, est un écart chiffré. Nous allons donc poser le problème à résoudre sous forme de nombre, en décrivant sur quel axe de la performance opérationnelle nous travaillons (qualité, coûts, délais, satisfaction client, satisfaction collaborateur) et pourquoi il est important de le traiter, et maintenant. Cela permet de voir et de comprendre le lien entre ce problème et la stratégie de l’entreprise afin de pouvoir mobiliser les équipes et les éventuels sponsors.

Pour comprendre davantage le problème à résoudre, on va questionner les managers sur ses impacts sur le triptyque client, entreprise, équipe. Oui, car une bonne résolution de problème doit pouvoir faire gagner ensemble les équipes, leur client et leur entreprise.

On donne ici des éléments factuels et récents (ex : ce mois-ci, ce trimestre) et chiffrés. On préfère être précis sur un périmètre restreint que vague sur un périmètre plus global. On va chercher des sujets spécifiques et actionnables plutôt que de grands sujets génériques.

Ici, on va donc montrer au manager, et à l’organisation, la définition d’un problème : un écart de performance chiffré, impactant un axe de la performance opérationnelle, et ayant des impacts sur le triptyque collaborateur, client, entreprise.

Yasmina

C’est ainsi qu’on découvre que l’équipe de Yasmina a beaucoup changé ces derniers mois. Entre l’arrivée d’une nouvelle PO, d’un nouveau Tech Lead et la fusion de squad, l’équipe souffre d’une désorganisation et d’une hausse importante de sa charge de RUN avec un Change Failure Rate passé de 0 à 30 puis 60 % en moins d’un an.

Jérôme

On comprend également le sujet de Jérôme dont les Epics mettent plus de 120 jours à sortir du flux de production pour 30 % d'entre elles, avec seulement 10 Epics qui sortent par trimestre alors que les demandes clients augmentent significativement.

Christian

On apprend que l’équipe de Christian consacre un ETP à la gestion du RUN sous la forme d’un rôle tournant que prennent successivement l’ensemble des 6 techs de l’équipe chaque semaine. Pendant ce temps, la personne désignée ne fait rien d’autre, et certaines de ces tâches sont longues et répétitives, sans réelle difficulté intellectuelle, qui est une stimulation importante pour cette équipe de passionnés, et qui est donc mal vécue.

Mathieu

Enfin, Mathieu nous confie que son équipe spécialisée dans la data gère environ 20 tickets de RUN par semaine, et que cela représente 86 % de la capacité de l’équipe. Cette activité est également un sujet d’insatisfaction forte pour les équipiers.

Cette étape de questionnement autour des problèmes des managers peut parfois sembler un peu longue. Et pourtant, elle est nécessaire pour les accompagner dans la conception d’un système d’apprentissage efficace. Elle les amène à redéfinir la nature même d’un problème, et à comprendre la signification profonde d'un problème en Lean. En apparence simple, cette étape permet d'éviter la confusion fréquente entre la cause et le problème, qui constitue un écart majeur freinant considérablement l'amélioration continue.

Clarifier la situation actuelle

Image d'une loupe sur un graphique pour représenter la clarification de la situation actuelle.

Une fois que le contexte du problème est bien défini, il nous faut maintenant comprendre la réalité opérationnelle. Pour ce faire, on va récupérer quelques données pour confronter les idées du manager à la réalité du terrain. Je vous renvoie vers le paragraphe “Aider le sponsor à clarifier la vision” du livre Culture Kaizen pour appréhender ce que cela implique.

Yasmina

L’analyse de la situation de l’équipe de Yasmina, souhaitant diminuer son RUN, montre ceci :

Visualisation graphique de la répartition des jours passés et du RUN

Entre le 20 juin et le 8 août :

  • 39 % de la charge de l’équipe est passée sur 327 tickets de RUN
  • Les 327 tickets se répartissaient en 253 incidents et 74 demandes de services
  • 77 % des incidents portaient sur un seul asset (sur les 4 de l’équipe)
  • 50 % de ces tickets ont des causes actionnables par l’équipe (problème de build, mauvaise qualification, mauvais paramétrage)

Jérôme

Quant à Jérôme et ses Epics de 120 jours, voici ce que l’on a mesuré sur les 17 dernières Epics terminées par l’équipe.

Graphique montrant la répartition moyenne des temps passé à chaque étape du processus pour les 17 dernières Epics traitée par l'équipe.

On constate donc que :

  • 54 % du temps est passé en arbitrage
  • 19 % du temps est passé dans les étapes d’attente (besoin identifié, attente d’affinage, attente de dev)
  • En moyenne, l’implémentation, le moment ou on crée réellement la valeur, ne représente que 6 % du Lead Time total

Christian

Pour Christian et son ETP réservé au RUN, l’analyse des 4 dernières semaines d’activité de RUN de l’équipe montre les informations suivantes :

Graphiques montrant la répartition du temps passé par type de ticket de RUN (Ajout de métriques, Incidents, et RUN), et les causes des demande KO (Exposition, Nommage, Inconnu, Cardinalité, Syntaxe, Template, Range, PR manquante)

Autrement dit :

  • En moyenne, 3,5 jours sont passés sur le RUN dont 2 sur des tickets d’ajout de métriques (représentant 70 % des tickets), soit 57 % du temps de RUN de l’équipe
  • L’analyse des tickets d’ajout de métriques les plus longs montre que 58 % des demandes sont de mauvaise qualité pour les raisons suivantes :
    • 40 % sont des écarts d’exposition
    • 20 % sont des écarts de nommage
    • 12 % sont des écarts de cardinalité

Mathieu

Enfin, on est allé à la rencontre de l’équipe Data de Mathieu qui passe 86 % de son temps sur du RUN. Voici ce qu’on a observé :

Graphique montrant la répartition des tickets de RUn par type. On y voit 17 tickets de run scriupt, 10 d'incident, 8 de droits, 7 de build, 6 de création de base et d'index, 1 d'upgrade et 1 d'infra.

Ce qui met en avant les faits suivants :

  • 34 % sont des demandes de lancement de scripts, qui ne sont pas exécutables directement par les équipes demandeuses pour des raisons de sécurité (fix métier, modification de données, reporting)
  • 30 % sont des demandes d’évolution de base de données MongoDB (ajout de droits, création ou modification de table, upgrade, etc.)
  • 20 % sont des incidents
  • 12 % sont des demandes de création de base ou d’index

Il ne reste alors que 14 % pour le build, on comprend mieux la frustration des collaborateurs désireux de créer de la valeur.

Il est important pour nous de clarifier la situation de cette manière pour créer le consensus. C’est une manière de passer d’une situation floue et insaisissable à une situation claire et actionnable.

C’est pendant cette phase qu'apparaît l’un des points les plus importants de l’accompagnement : le Gemba. Les managers ont souvent des idées sur tout (ils ont surtout des idées, dirait Coluche). Donnez-leur un challenge, et ils vont avoir plein d'idées pour y contribuer. Le problème c’est qu’en restant dans leur bureau, ils prendront des décisions loin de la réalité opérationnelle. L’idée du Gemba est de confronter les idées du manager au terrain, et d’avoir une représentation fidèle de la réalité telle qu’elle est observée et non telle qu’elle peut être perçue.

La situation actuelle d’un A3 permet de voir la vérité sur les faits, sur nos biais, et sur notre capacité à écouter le terrain. C’est le moment où le manager cesse d’avoir une opinion pour commencer à s’intéresser à la réalité. C’est en regardant avec lucidité la situation telle qu’elle se présente que le Kaizen peut commencer. Il permet de préparer le terrain pour mobiliser les équipes plus efficacement autour de sujets plus spécifiques. Jérôme pourra aller voir ses équipes non plus en posant la question “Pourquoi notre Lead Time est si long ?” mais plutôt : “Pourquoi cette Epic a passé 54 % de son temps en arbitrage ? Et celle-ci ?”. Il sera également en capacité de définir, grâce à une compréhension claire de la situation, une cible atteignable et mobilisatrice pour l’équipe.

Comprendre la situation est une étape indispensable pour prendre les bonnes décisions. La suivante consiste à s’accorder sur une cible claire.

Dans le prochain article, nous verrons comment la définition de cette cible guidera l’analyse des causes, les expérimentations terrain, la mesure des résultats et les apprentissages, transformant progressivement le manager en concepteur d’un système capable de faire évoluer l’organisation vers une véritable organisation apprenante.