Flux tiré, standards, PDCA : comment le Lean a permis à une équipe Agile mature de s’améliorer

La vraie richesse du Lean (dans sa définition originelle du Toyota Production System) ne réside pas dans l’ajout d’outils ou de rituels, mais dans sa capacité à relancer l’amélioration continue là où les dispositifs organisationnels existants (tels que l'Agile) semblent avoir atteint leurs limites. Car oui, même les équipes les plus aguerries peuvent avoir l’impression de stagner.

Dans cet article, nous proposons de vous raconter ce que le Lean a apporté à une équipe Scrum mature, accompagnée depuis plusieurs années par un Scrum Master senior, qui nous confiait avoir l’impression d’avoir atteint un “plafond de verre”. Nous vous montrerons comment le Lean a ouvert un nouveau champ d’expérimentation et d’apprentissage, là où l’équipe pensait avoir déjà tout exploré.

Contexte

La mission

Notre client est la DSI d’un grand groupe bancaire français. L’organisation a vécu une transformation agile quelques années auparavant qui s’est bien déroulée. Dans l’ensemble, l’agilité est bien diffusée et l’écrasante majorité des squads dispose d’un scrum master et/ou d’un coach agile pour poursuivre leur progression. La DSI cherche maintenant à franchir une nouvelle étape, un pas de plus vers l’excellence opérationnelle, et a sollicité OCTO pour expérimenter la démarche Lean. Stratégiquement, pour comprendre ce que le Lean peut apporter à l’agilité déjà mise en place, la DSI souhaite travailler avec une équipe reconnue comme très mature dans son appropriation de l’agilité. C’est précisément cet accompagnement que nous vous proposons de partager avec vous ici.

L’équipe

L’équipe travaille sur deux composants techniques utilisés par 150 équipes, qui leur adressent régulièrement des demandes d’évolution et/ou de correctif. L’exploitation de ces composants est en forte augmentation. En effet, l’utilisation du premier composant a plus que doublé entre 2022 et 2024, et l’équipe s’attend à ce qu’elle soit encore multipliée par 2 ou 3 d’ici la fin d’année 2025. Quant à l’autre composant, son utilisation a été multipliée par 45 entre 2021 et 2024 !

Les demandes et les interlocuteurs se multiplient. La pression monte pour les équipes. On nous informe que l’une des deux squads a connu un turnover de 100% en un an… Le challenge est donc identifié avec le sponsor :

1. Stabiliser le flux de production des squads pour créer un environnement propice à l’amélioration.
2. Accélérer le delivery pour faire face à la montée en charge et aux futurs défis, en supprimant les gaspillages qui empêchent la valeur de circuler plus rapidement dans le flux de production.

Diagnostic

Que disent les clients ?

On peut entendre, dire et imaginer tout ce que l’on veut sur l’efficacité d’un processus. Tant que nous ne sommes pas allés voir celles et ceux qui utilisent ce qui en sort, cela reste des opinions. Pour nous faire une idée concrète du point de vue des clients, nous interviewons huit clients sur des évolutions ou des versions qui leur ont été récemment livrées, afin de comprendre les écarts entre ce qu’ils attendaient et ce qu’ils ont eu. Nous complétons ces interviews en demandant une note sur 10 nous permettant de calculer un NPS (Net Promoter Score) qui est de 0.

Les principales remarques remontées par les clients sont le manque de visibilité sur les dates de livraison, les délais parfois un peu longs (entre un et six mois par rapport à l’attendu), un questionnement sur la qualité et des relances pour accélérer le traitement des demandes.

L’équipe semble avoir du mal à tenir les délais annoncés ou à communiquer les délais réalistes, ce qui nous montre un problème de pilotage. On comprend ainsi le lien direct avec les enjeux identifiés autour de la stabilité, pour être en mesure d’annoncer des dates fiables, et de l’accélération, pour être capable de livrer plus rapidement.

Que disent les collaborateurs des squads ?

Après avoir compris la perspective des clients, nous nous intéressons au point de vue des utilisateurs du processus : les collaborateurs des squads. Quatorze d’entre eux sont alors interviewés. L’enquête a abouti à un eNPS de –7, avec pour principales remarques de nombreux sujets en parallèle, des user stories trop longues, un engagement en PI (roadmap trimestrielle) flou, des pair-reviews longues, des retours qui tardent à être traités, et un mûrissement (conception) de qualité variable.

Ces retours mettent en avant des problèmes d’alignement sur les objectifs, de pilotage, de gestion de l’encours et de mûrissement. Là aussi, on perçoit clairement le lien avec les enjeux de stabilisation et d’accélération. Ces verbatims nous permettent également d’identifier des causes potentielles, qu’il nous faut valider sur le terrain.

Analyse du delivery

Nous avons entendu les clients, puis les collaborateurs. Nous avons fait le lien entre ce qu’ils constatent et les enjeux de la mission. Nous allons maintenant confronter ces informations à la réalité du terrain. Pour faire cela, nous allons nous appuyer sur l’outil de ticketing utilisé par l’équipe pour suivre sa production et ses projets : Jira. Ce type d’outil est une mine d’or pour comprendre les difficultés de l’équipe et identifier des opportunités d’amélioration. Nous allons donc nous en servir pour analyser le delivery des Epics et des US (user stories), les temps de passage dans chaque étape du processus, les lead Times des Epics et des US (durée totale de traversée du processus de production), l’engagement des sprints et des PI, ainsi que la non-qualité à travers les bugs et les allers/retours dans le flux de production.

Le but de cette analyse est double. Faire le lien entre les problèmes remontés par les clients, les irritants des équipes, le challenge business de l’entreprise et la réalité du terrain, puis clarifier la situation de manière factuelle, concrète et actionnable par l’équipe.

Voici ce que nous observons :

• Stabiliser le flux : l’analyse du delivery des 6 derniers mois met en évidence une forte variabilité :
  • Épics : 79 EPIC livrées avec une variabilité de 875% (entre 4 et 35)
  • US : 108 US ajoutées en cours de sprint, et 48 tickets retirés, soit une variabilité de 100% (156 / 155)
  • Les anomalies représentent 26% du delivery de l’équipe.
• Accélérer le delivery :
  • 58% des US ont un lead time supérieur à 1 sprint (21 jours) (43 / 74)
  • 90% des Épics ont un lead time supérieur à 1 PI (90 jours) (35/39)
  • Taux de réussite des sprints entre 43% et 70%, celui des PI entre 38% et 50%

Nos observations mettent également en lumière l’absence de standard sur les gestes de production, ce qui empêche l’équipe de maîtriser son activité et induit une forte variabilité dans le flux comme dans la qualité.

Analyse des causes

Lors de l’analyse du delivery, nous avons identifié des « pièces KO », comprenez : des tickets ajoutés en cours de sprint, des tickets retirés après avoir été partiellement traités, des tickets bloqués, ou encore des anomalies. Tous ces tickets ont des choses à nous apprendre. Nous analysons donc la cause de ces dysfonctionnements en proposant aux équipiers de courtes sessions de travail de 30 minutes pendant lesquelles nous montrons les écarts (delivery, qualité, etc.), nous identifions les causes racines en examinant les tickets un par un, pour obtenir finalement un Pareto de causes (classement des causes par ordre décroissant d’occurrence).

Un sujet nous saute alors aux yeux : le mûrissement. Il est en cause dans 24% de la variabilité, 23% de la non-qualité, 21% des tickets bloqués, 10% des tickets non terminés sur le sprint. Un constat qui appelle une attention particulière.

Recommandations

Le diagnostic réalisé, nous proposons à l’équipe de passer à l’action sur 3 axes :

1. Le Pilotage :
   1. S’engager sur un nombre d’Epics en PI et sur un nombre de Stories en Sprint. Corollaire : les Epics doivent donc tenir sur un PI, et les US sur un sprint.
   2. Piloter de manière volontariste, en flux tiré, la réalisation de ces unités d’œuvre, en limitant l’encours et en focalisant l’attention sur le « terminer » à chaque sprint planning et à chaque daily.
   3. Analyser et comprendre les écarts de délai et qualité à chaque PI, sprint, et daily.
   4. Utiliser les rétrospectives d’équipe pour analyser les écarts, ticket par ticket, afin de créer ou faire évoluer les standards de l’équipe.
2. Travailler sur les causes de variabilité :
   1. Analyser systématiquement les causes des tickets ajoutés ou retirés dans les sprints lors des rétrospectives.
   2. Standardiser les sprint plannings et travailler sur le « juste à temps » afin d’éviter de passer du temps à préparer des tickets qui ne seront finalement pas traités dans le sprint.
3. Amélioration du mûrissement :
   1. Identifier et analyser systématiquement les écarts dus à un mûrissement insuffisant.
   2. Standardiser le processus de mûrissement pour capitaliser les apprentissages et améliorer le geste.

Nous comprenons les difficultés de l’équipe, nous établissons alors nos recommandations, et nous passons à l’action.

Accompagnement

Mise en place du pilotage

Pour commencer l’accompagnement, il nous faut mettre en place le pilotage en flux tiré. C’est cela qui permettra à l’équipe de constater les problèmes au quotidien et donc d’identifier des opportunités d’amélioration chaque jour.

Par chance, le début de l’accompagnement coïncide avec un PI Planning. Lors de ce PI Planning, l’équipe fait en sorte que l’objectif du PI ne soit plus formulé en phrases interprétables, mais exprimé en nombre d’Epics à livrer. Le PI Planning passé, nous appliquons la même logique aux sprints en définissant l’objectif de chacun d’eux en nombre d’US à terminer.

La redéfinition des critères de réussite du PI permet maintenant de piloter les Epics en flux tiré lors des sprint plannings. Pour aider à cela, nous créons un management visuel de PI, offrant une vue claire sur les Epics engagées, leur statut, ainsi que le détail des US qui les composent (et leur statut) :

Le sprint planning change alors de forme, avec des questions orientées flux : quelles Epics devons-nous terminer sur ce sprint pour réussir notre PI ? Comment pouvons-nous nous organiser pour réussir ? Cela implique de terminer combien d’US sur ce sprint ? Lesquelles choisissons-nous ? Comment pouvons-nous nous organiser pour réussir ? Par ces questions simples, l’objectif du sprint devient naturellement un nombre d’US à terminer.

L’animation du daily a naturellement suivi ce changement. Chaque jour, l’équipe se pose la question du nombre d’US à terminer et de l’organisation à mettre en place pour y parvenir. Pour permettre à l’équipe de maîtriser et d’améliorer ce rituel, crucial pour la réussite du pilotage en flux tiré, nous rédigeons un standard d’animation de daily. Cela change du format d’avant où les personnes parlaient à tour de rôle pour raconter leurs journées (1).

Mise en place des KPI (Key Performance Indicators)

"Ce qui ne se mesure pas, ne s'améliore pas", cette citation de W. Edward Deming nous rappelle l'importance de la mesure dans l'amélioration de la performance. Sans mesure, difficile de savoir ce que l’on doit apprendre et sur quoi. Et surtout, si nos actions apportent réellement des améliorations ?

Nous allons donc proposer à l’équipe de mettre en place des KPI pour mesurer ce que l’on souhaite améliorer, c'est-à-dire l’engagement des Epics par PI, celui des US par sprint, le lead time des Epics et des US ainsi que le eNPS (Employee Net Promoter Score). Ce dernier indicateur est précieux pour contrôler que l’amélioration de la performance ne dégrade pas la satisfaction des collaborateurs.

Premier petit pas

Grâce à tout ce qui a été mis en place pour voir les problèmes, l’équipe ne tarde pas à mettre en évidence que leur DOR (Definition of Ready de leurs US), mise en place depuis longtemps en tant que « bonne pratique agile », est insuffisante. En effet, l’analyse de 5 tickets non terminés en phase de test a révélé que les porteurs de ces tickets pensaient ne pas pouvoir les tester. Ils les abandonnaient alors en attendant la solution qu’ils imaginaient pour les débloquer, ce qui crée du délai. Quelques échanges ont montré qu’en fait, d’autres équipiers avaient des idées pour débloquer la situation. Voici quelques exemples :

• Un développement jugé non testable car il devait l’être sur un environnement client spécifique qui n’était pas joignable. Un équipier connaissait un autre environnement similaire, ce qui a permis de poursuivre les tests.
• Un ticket que l’on pensait non testable faute de droits suffisants sur le serveur. Un développeur connaissait un autre compte avec des droits suffisants pour tester l’US.
• Une US considérée comme non testable à cause d’une dépendance à une autre livraison… Sauf en modifiant un paramètre, que l’équipier en charge du test ne connaissait pas, et qui permettait de s’affranchir de cette dépendance.

Cela a mis en avant un point important pour l’équipe. Lors des sprint plannings, l’équipe se demande si elle peut développer l’US en question… mais jamais comment la tester, la valider, sur quel environnement, avec quel compte, etc. Leur DOR n’a pas bougé depuis longtemps, et prend la poussière dans un coin de Confluence. L’équipe souhaite alors la reprendre en main et la mettre sous la forme d’un standard Lean pour mieux identifier les situations leur permettant de terminer les US, et celles qui ne le permettent pas (et pourquoi). Ce précieux standard leur permet non seulement de se mettre en situation de réussite, mais aussi de disposer d’un support d’apprentissage vivant, qu’ils feront évoluer à chaque fois qu’un problème se présentera. De quoi éviter les classiques : « la prochaine fois, on fera plus attention ! » .

Cette contre-mesure permet désormais à l’équipe de refuser les US qu’elle ne peut pas terminer, et d’engager uniquement celles ok d’un point de vue de leur standard DOR. Résultat : le nombre d’US bloquées dans le flux diminue rapidement, ce qui génère une vraie motivation pour poursuivre ce geste d’amélioration. La première squad à avoir expérimenté est rapidement passée de 13 US terminées par sprint à 17. Une première victoire importante, car dans notre démarche, nous ne cherchons pas à motiver l’équipe pour qu’elle réussisse, mais à la faire réussir pour la motiver. Après tout, qui sommes-nous pour exiger leur motivation ? C’est à nous de leur montrer que ça fonctionne, et c’est maintenant chose faite.

Continuer dans l’amélioration

Forte de cet apprentissage validé par la mesure, l’équipe continue de trouver une multitude d’opportunités d’amélioration (appelez cela des problèmes) grâce au pilotage en flux tiré, aux analyses des sprints, des PI, des tickets ajoutés, refusés, bloqués, etc. En voici trois exemples concrets :

• Un écart de qualité à la suite d’une livraison à un client qui n’a pas réussi à utiliser l’API livrée à cause d’une documentation non mise à jour. À l’image de la DOR, la DOD (Definition Of Done) a également été mise sous forme de standard, que l’équipe s’est rapidement approprié.
• Un écart de qualité lors du test par le PO qui n’a pas eu le résultat souhaité d’un développement « pourtant bien décrit dans l’US ». Après un Gemba, au cours duquel on a ouvert le ticket avec le PO et le développeur, on découvre qu’une maquette avait bien été fournie, mais que la PO avait ajouté un texte complémentaire en dessous. Mathieu, le développeur, avait bien réalisé le développement en phase avec la maquette, mais n’avait pas vu le texte en dessous. Cela s’explique car lorsqu’il a un développement à réaliser et que celui-ci est décrit par une maquette, il affiche cette dernière sur son écran de droite, et réalise le développement sur son écran de gauche afin de pouvoir comparer les deux. Le texte en dessous n’a donc pas été vu. Grâce à cet apprentissage très spécifique, le PO a compris la cause du malentendu. Un standard a ensuite été créé par la PO pour cadrer l’affinage et les questions à se poser lors de la conception d’une US.
• Un écart de délai lié à une attente concernant la mise à disposition des composants techniques sur les environnements de pré-production, a mis en avant une forte variabilité de qualité et de délai en fonction de la personne chargée de faire la release. La standardisation a permis à l’équipe de préciser le geste, de pouvoir l’améliorer, et même de permettre à Maxence, jeune recrue dans l’équipe, de réaliser sa première release : « La standardisation permet d’homogénéiser les pratiques, et les gestes, et en tant que nouveau, c’est très appréciable » (Maxence)

Stéphane, le Scrum Master, a tout de suite vu l’intérêt de se focaliser sur les tickets pour s’améliorer. Il change rapidement le format de ses rétrospectives pour y apporter une dimension plus factuelle et lean dans son approche de résolution des problèmes. L’équipe regarde donc les problèmes en analysant les tickets, et lance des expérimentations pour faire évoluer ses standards en fonction des résultats obtenus.

Résultats

La pugnacité du scrum master et de l’équipe, leur capacité à s’accrocher à chaque problème identifié ont permis d’obtenir des résultats remarquables. Ces résultats obtenus pour une équipe, qui rappelons-le, est une équipe très avancée dans son appropriation de la démarche agile, montre à quel point le Lean permet d’apporter aux pratiques agiles déjà en place.

Voici quelques chiffres qui illustrent cette amélioration significative :

• Engagement sur les Epics : +16 pts
• Lead Time des Epics : -58% (de 434 jours à 181)
• Engagement des US : +24 pts
• Delivery d’US : +18% (de 27,2 US par sprint à 32) (soit un gain de 360 000 € / an sur une équipe de 20 personnes)
• Satisfaction Clients (NPS) : de 0 à 100
• Satisfaction Collaborateur (NPS) : de -7 à +64
• Satisfaction Sponsor (NPS) : +100

Feedbacks des équipiers :

• « Je me focalise maintenant plus sur le fait d’écouler les tickets en limitant les stocks »
• « Je suis plutôt satisfait, ça porte ses fruits sur l’organisation de fluidifier les tickets. Ça permet de faire en sorte que les tickets ne trainent pas dans les colonnes merges et tests »
• « Le fait de tirer les US et ne pas les pousser, c’est vraiment le point que je retiens. On a un daily plus pragmatique »
• « Les standards permettent de décrire les processus et uniformiser »
• « L’outil standard est vraiment pas mal. Ça nous a poussé à clarifier des procédures qu’on n’avait pas et qui nous faisaient souvent trébucher »
• Stéphane - Scrum Master : « Le mouvement que ça a créé dans les équipes. Ça a déstabilisé un peu, mais pour beaucoup de bien »

Feedback des managers et sponsors

• Directeur de la plateforme - Sponsor Local : « Je suis très impressionné. Bravo, vraiment bravo !! L’équipe est en avance, elle est mature dans les méthodes d’agilité à l’échelle et elle arrive encore à trouver beaucoup de choses »
• Manager de l’équipe : « Très promoteur. Je ne m’attendais pas à ce niveau de détail. Une très grande amplitude dans les actions. Très précis, et très concret »

Enseignements

Stéphane, le Scrum Master, nous confiait en début de mission avoir l’impression d’avoir atteint un “plafond de verre” avec son équipe. Cette mission a prouvé le contraire. La mise en œuvre du Lean a ouvert de nouvelles perspectives, de nouveaux leviers, pour continuer à progresser encore et toujours.

Quand on pose la question : « Qui fait de la résolution de problème ? », presque toutes les mains se lèvent. Mais si on ajoute : « C’est quoi, un problème ? », le silence s’installe. Le Lean, c’est avant tout un système d’apprentissage complet, qui commence par montrer les problèmes en en donnant une définition claire : un écart de performance chiffré depuis la perspective du client.

Par la mise en place du flux tiré, du pilotage hebdomadaire et quotidien de la valeur opérationnelle, et du suivi de la performance, l’équipe a soudain pu voir les problèmes qu’elle ne voyait pas jusque-là. Les pratiques de la résolution de problèmes, c'est-à-dire le PDCA portant sur les sujets spécifiques et les standards pour maîtriser les gestes et capitaliser les apprentissages, ont également été de puissants révélateurs pour l’équipe… et pour le Scrum Master.

Ces pratiques ont transformé le déroulement des daily, des rétrospectives, et la manière même d’aborder le travail. L’amélioration continue s’est invitée dans le quotidien de l’équipe. Et elle est là pour rester. Dans notre expérimentation, le Lean n’est pas venu remplacer l’agile. Il est venu lui donner un second souffle.

« Oui, le Lean et l’Agile sont appelés à avoir de beaux enfants »

Ludovic Cinquin, ex CEO OCTO Technology, dans la préface de notre livre blanc Culture Kaizen

(1) : Article dédié au sujet de la transformation de l’équipe grâce aux trois questions du daily.