Diviser par 3 le Lead Time d'une équipe de delivery grâce au Kaizen

Nous avons souvent partagé des retours d’expérience sur le Lean, principalement axés sur des équipes ou des programmes agiles. Cependant, une question revient fréquemment : comment accompagne-t-on les managers dans cette démarche ? Dans toute transformation – qu’elle soit Lean ou non – l’alignement de la chaîne managériale est essentiel. Les managers, bien souvent, en constituent l’une des pierres angulaires.

Il y a deux semaines, nous avons terminé un accompagnement de managers au sein d’un acteur majeur du secteur du Retail en France. Dans cet article, nous allons partager avec vous le sujet d'amélioration d’un de ces managers, que nous appellerons François.

Présentation de la démarche

L’objectif de la démarche est de former des managers à la résolution de problème par la pratique sur des cas concrets, dans leur contexte, grâce à un outil Lean : Le A3. Cet outil permet de structurer la résolution de problème en entreprise autour de la démarche scientifique basée donc sur le PDCA de Shewhart et Deming.

L’approche consiste à accompagner le manager sur son projet d’amélioration, en explorant chacune des étapes du processus de résolution de problèmes : clarification du problème, collecte de données factuelles et chiffrées de la situation actuelle, définition d’une cible, analyse des causes (et validation sur le gemba), identification des contre-mesures et mobilisation des membres de l’équipe pour les mener à bien, mesure des résultats obtenus, standardisation des pratiques qui fonctionnent, et identification des prochaines étapes.

Cette méthode permet au manager d’adopter un nouveau regard sur les problèmes, en valorisant la perspective client, la culture de la mesure et des éléments tangibles. Par ailleurs, elle contribue à l’amélioration d’un enjeu clé pour l’entreprise dans le cadre de sa stratégie d’amélioration.

Présentation du cas de François

Contexte

Dans cette première partie de A3, nous allons décrire le contexte (l’équipe, les personnes, etc.) et préciser le problème à résoudre. Pour cela, il nous sera nécessaire de :

1. Fournir une définition Lean du problème, exprimée sous forme d’écart chiffré
2. Comprendre la nature du problème sur les 3 axes de performance opérationnelle (Qualité, Coûts, Délais) et / ou sur un des deux axes du « centrique » : Satisfaction Client, Satisfaction Collaborateurs
3. Évaluer son impact sur le triptyque Client, Entreprise, Équipe

Ces éléments permettront de nous éclairer sur l’importance de traiter ce problème maintenant du point de vue stratégie d’entreprise.

Retour au sujet de François : François est manager, il vient de prendre la responsabilité d’une équipe Agile composée de cinq développeurs (dont quatre séniors) et d’un Product Owner. L’équipe est chargée du build et respecte l’adage “you build it, you run it” au sein d’un grand programme Agile. Pour l'anecdote, nous avions déjà travaillé avec François par le passé dans le cadre d’un accompagnement d’équipe. Son équipe était alors constituée de 40 personnes et nous avions obtenu une amélioration du delivery de 24% des US, une amélioration du taux de réussite des sprints de 35%, avec un eNPS de +42. François part donc convaincu par la démarche, et s’est naturellement inscrit dans cette promotion d’accompagnement de manager proposée par son entreprise dans le cadre de sa transformation Lean.

François formule alors le problème avec ses mots :

“Le Lead Time est trop important dans cette équipe”

Cependant, cette formulation manque de précision d’un point de vue Lean. Nous allons expliciter le problème. Après avoir analysé les données issues de l’outil de gestion du build de l’équipe, nous faisons le constat suivant :

• Le Lead Time moyen des User Stories (US) de l’équipe est de 97 jours (de l’expression du besoin à la mise en production) ;
• Son taux de réussite des sprints est de 55 % (elle ne réalise que 55 % des engagements pris sur les sprints). Elle ne parvient jamais à terminer l’ensemble des User Stories engagées ;

Ces dysfonctionnements génèrent un sentiment de lassitude et d’impuissance au sein de l’équipe. François souligne qu’il n’y a pas de blocages liés à l’alimentation des sprints (l’équipe dispose d’un sprint et demi d’avance, “ready” et priorisé). Néanmoins, on observe que certains sujets peuvent rester stockés jusqu’à 50 jours dans un cycle.

Pour comprendre l’importance de travailler sur ce problème, nous clarifions les impacts qu’un Lead time long a sur le triptyque Client, Entreprise, Équipe :

• Client : moins de fonctionnalités et de valeur livrée ainsi que des retards de livraison ;
• Entreprise : des revenus en moins et une détérioration de l’image de marque auprès des clients ;
• Équipe : une frustration liée à l’impossibilité de terminer ses sprints et de satisfaire ses clients, entraînant une baisse de motivation et une perte de sens.

Analyse de la situation actuelle

Dans cette seconde partie, nous allons chercher à comprendre le standard de production de l’équipe afin d’identifier les étapes où des problèmes peuvent survenir. Nous procéderons ensuite à une évaluation de la performance opérationnelle pour comprendre où le temps est réellement passé.

Pour expliciter ce standard de production, nous modélisons le processus opérationnel de l’équipe. Cette analyse révèle un point critique : une dépendance significative à une équipe DATA, qui influence directement le flux de travail.

Notre sujet étant le Lead Time, nous allons chercher à comprendre où est passé le temps. Pour identifier les problèmes qui impactent le plus ce Lead Time, nous allons cibler les User Stories (US) avec les délais les plus longs et analyser les causes ayant généré ces durées.

L’objectif est de détecter les causes principales, là où l'équipe rencontre des difficultés. Une approche aléatoire, consistant à examiner toutes les US dépassant 30 jours, serait peu efficace, car elle inclurait un volume trop important, réduisant ainsi nos chances d’identifier rapidement des leviers d’amélioration significatifs. Nous devons donc établir un seuil d’analyse permettant de sélectionner un nombre suffisant d’US à étudier, tout en évitant d’être submergés par un excès de données.

Après avoir analysé les 100 dernières US livrées par l’équipe, nous constatons que 40% d’entre elles ont un Lead Time supérieur à 60 jours, soit un total de 40 US. Un nombre suffisant pour identifier les principaux problèmes sans perdre en clarté.

L’analyse des temps passés dans chacune des étapes montre du temps perdu aux étapes suivantes (voir icône “Warning”) :

Tout ceci peut paraître un peu long. Après tout, nous travaillons depuis un certain temps et n’avons pas encore défini de solution. C’est tout à fait vrai, mais c’est précisément le principe de l’exercice : prendre le temps de bien comprendre le problème afin de maximiser les chances d’avoir un impact significatif en lançant les bonnes contre-mesures (Et entre nous, il ne nous aura fallu qu’une petite heure pour réaliser tout ce travail d’analyse des temps passés à chaque étape).

Détermination de la cible

A l’aune de la situation actuelle clarifiée, nous pouvons désormais définir une cible pour notre A3. Ici, nous allons chercher une cible SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporelle).

Il ne s’agit évidemment pas de fixer une cible arbitraire, mais de l’établir sur la base des observations effectuées. Si nous parvenons à éliminer les causes des tickets ayant un Lead Time supérieur à 60 jours, nous devrions atteindre un objectif ambitieux : 100 % des tickets livrés en moins de 60 jours. En calculant cette hypothèse, nous obtenons un Lead Time moyen de 45 jours. Ce sera là notre cible.

Identification des causes

Nous procédons donc à l’analyse des User Stories (US) ayant un Lead Time supérieur à 60 jours. Cette étude, menée sur les 40 US, a permis d’identifier les causes suivantes :

• 43 % sont dues à des attentes à diverses étapes du processus ;
• 26 % résultent de dépendances avec l’équipe DATA, notamment pour les étapes d’IT Review (qui englobe les étapes de validation par l’équipe DATA ou par le DATA Owner, et celle de l’affinage technique sur le processus présenté en amont) et de validation (Validating) ;
• 20 % sont causées par des délais liés à la priorisation par le Product Owner ;
• 9 % sont imputables à un manque de réactivité à l’étape de livraison.

À cette étape, nous formulons des hypothèses de causes possibles à ces problèmes. Le point le plus important ici est d'aller confronter ces hypothèses au terrain pour les valider ou les invalider. L’objectif est de s’assurer que nous n’écoutons pas nos préconceptions et que nous ne nous jetons pas sur des « solutions ». Nous cherchons à garantir une bonne compréhension du problème et à valider les causes identifiées.

J'encourage alors François à formuler des hypothèses, tout en acceptant que certaines puissent être infirmées par les observations terrain. Par exemple, François pensait qu’il existait des problèmes opérationnels lors des étapes d’affinage. L’affinage métier et technique ne devrait pas dépasser 30 minutes, mais les données collectées montraient des délais de 4 jours. Un gemba auprès des équipes a permis de clarifier la situation : il n’y a aucun problème opérationnel. Cependant, une déconnexion organisationnelle a été identifiée : la réunion d’affinage métier se tenait le lundi, tandis que celle d’affinage technique était programmée le vendredi, créant un délai de quatre jours entre les deux. Ce décalage était la cause principale des délais constatés. Merci, gemba 🙂

Les causes suivantes, également proposées par François, ont cependant été validées sur le terrain grâce à des observations issues de leur outil de ticketing ou d’entretiens avec les collaborateurs :

• L’équipe a beaucoup d'en-cours, avec notamment un goulot d'étranglement sur la phase d’IT Review ;
• Des délais d’attente surviennent lorsque les validations sont réalisées par l’équipe DATA, notamment en raison d’une absence de coordination pour récupérer la disponibilité du testeur avant le développement ;
• Trop de Thème et d’Epic sont en cours simultanément, ce qui allonge significativement le Lead Time ;
• Les conditions de réussite ne sont pas clarifiées ;
• Pas de pilotage clair du flux de travail ;
• Certains membres de l’équipe ne sont pas totalement autonomes dans la validation des Pull Requests (PR) et la livraison en production (pas de standard et de challenge de montée en compétence)

Passer à l’action

Nous avons désormais une bonne compréhension du problème, de son importance et de ses impacts. Nous avons clarifié la situation actuelle en analysant le standard de production et les temps passés. Une cible réaliste a été fixée, et un ensemble de causes a été identifié et validé.

Il est maintenant temps de passer à l’action. L’objectif ici est de concevoir et tester des contre-mesures au plus vite, et d’éviter les plans d’action de 6 mois. Nous identifions donc des contre-mesures à expérimenter dès aujourd’hui ou cette semaine. Pour cela, nous cherchons à supprimer autant que possible les dépendances externes (personnes d’autres équipes, outils, etc.). L’enjeu est de lancer des expérimentations rapidement et efficacement. Certaines actions peuvent être réalisées manuellement si nécessaire, et nous sollicitons le soutien de nos sponsors pour obtenir les autorisations nécessaires, afin de mener les expérimentations dans les plus brefs délais.

“Plus on expérimente vite, plus on apprend vite et plus on développe un avantage concurrentiel”

Mary Poppendieck (écrivaine et oratrice, co-auteure de l’ouvrage “Lean Software Development”)

Pour faire en sorte de se mettre rapidement en mouvement, on complètera chaque contre-mesure avec deux informations essentielles : la personne responsable de la mise en œuvre de l’action et la date de son exécution. Cela responsabilise les parties prenantes et permet d’éviter que des actions soient oubliées.

Dans notre cas, nos actions ont été les suivantes. Chacune est évidemment liée à une des six causes validées. Elles ont été mises en place successivement par itération, et suivis dans le A3 :

• Cause 1 : L’équipe a beaucoup d'en-cours, avec notamment un goulot d'étranglement sur la phase d’IT Review
  • Mise en place de limites de travail en cours (WIP limits) sur l’ensemble du flux de production.
  • Suivi de ces limites lors des daily meetings pour maintenir le flux en dessous du seuil maximal et prévenir les goulots d’étranglement.
  • Augmentation de la fréquence des IT Review à une fois par jour, avec une durée limitée à 30 minutes pour fluidifier le flux.
  • Définition de standards pour les IT Review pour améliorer l’autonomie des personnes et permettre la rotation du rôle d’animation afin de réduire la variabilité du nombre de tickets traités à cette étape.
  • Identification visuelle de l’état des tickets via un code couleur pour éviter de travailler à nouveau sur les mêmes tickets lors des IT Review (retouches)
  • Synchronisation des étapes : définition d’un objectif de 2 tickets à traiter par IT Review (correspondant au débit moyen du système). L’objectif est ajusté en fonction du débit réel pour éviter le stockage excessif et prévenir la surproduction. Le PO pilote le rythme d’alimentation du flux.
• Cause 2 : Des délais d’attente surviennent lorsque les validations sont réalisées par l’équipe DATA, notamment en raison d’une absence de coordination pour récupérer la disponibilité du testeur avant le développement
  • Rédaction de standards pour rendre l’équipe autonome dans la validation de certains tickets DATA. Collaboration avec l’équipe DATA pour définir les tickets « simples » qui peuvent être validés en autonomie et ceux, plus « complexes », sur lesquels ils souhaitent garder la main.
  • Relances manuelles pour accélérer les validations ou débloquer les tickets en attente. Dans un second temps, exploration d’un système de relance automatique via l’outil de ticketing.
  • Mise à jour du standard de préparation du sprint planning pour demander la disponibilité de l’équipe DATA, en charge de la validation, avec un blocage du créneau pour garantir une validation « juste à temps ».
  • Objectiver à 2 jours maximum de délai le traitement de ticket DATA, pour permettre de déclencher des actions d’amélioration (PDCA) en cas de dépassement.
• Cause 3 : Trop de Thèmes et d’Epics sont en cours simultanément, ce qui allonge significativement le Lead Time
  • Sensibilisation du Product Owner pour ne pas surcharger les sprints
  • Limiter le nombre de THEME / EPIC en cours
  • Mise en place d’un board Kanban pour visualiser les Epic en cours.
• Cause 4 : Les conditions de réussite ne sont pas clarifiées
  • Définition de l’objectif de sprint en termes de nombre d’US
  • Définition des conditions de réussite de chaque jour (lors du daily) basées sur le nombre d’US à terminer, et calculé comme le nombre total d’US engagées divisé par 10 (pour un sprint de deux semaines).
• Cause 5 : Pas de pilotage clair du flux de travail
  • Mise en évidence du nombre de tickets en cours à chaque étape lors des daily meetings.
  • Sensibilisation de l'équipe pour terminer les User Stories sur les sprints chaque jour en s’appuyant des conditions de réussite du sprint et de la journée (induit la lecture du board par la droite)
• Cause 6 : Certains membres de l’équipe ne sont pas totalement autonomes dans la validation des Pull Requests (PR) et la livraison en production
  • Élaboration d’un standard pour la validation des Pull Requests.
  • Élaboration d’un standard pour la livraison en production.

Résultats

François a guidé son équipe à travers ces initiatives, qui, bien que déstabilisantes au début, ont été bien accueillies. Une chose est certaine : l’équipe ne reviendra pas en arrière. Pourquoi ? Tout simplement parce que cela fonctionne, et on sait le mesurer.

Car en Lean, l’efficacité des actions mises en place est démontrée par des mesures concrètes et non par les opinions. Comme l'explique Deming, “Sans donnée, vous n’êtes qu’une personne de plus avec une opinion”.

François a souhaité réduire le Lead Time en s’attaquant aux temps de cycle des étapes d’IT Review et de Validating. Pour valider l’efficacité de ces contre-mesures, nous mesurons donc ces temps :

• Les contre-mesures sur la phase d’IT Review ont réduit de 80 % le temps passé à cette étape.
• Les contre-mesures effectuées sur les validations, en particulier celles impliquant des dépendances avec les équipes DATA, ont permis de réduire de 80 % le temps consacré à cette étape.

Ces deux actions ont eu pour effet de faire chuter le Lead Time des User Stories de 67%, passant de 97 jours en moyenne à 32 jours. Notre objectif étant de 45, l’équipe a non seulement atteint sa cible, mais l’a dépassée.

Un “effet de bord” de la réduction du Lead Time, combinée aux autres améliorations menées par l’équipe, a été une augmentation de 46% du delivery des US, passant de 24 US par sprint à 35. Pour une équipe de cinq développeurs, cela représente un gain de 2,3 ETP, soit 230 000 euros par an.

Fun fact, lorsque l’équipe a mesuré les premières augmentations de son delivery, elle a douté de ses propres résultats. Elle n’a donc pas souhaité augmenter son engagement en termes de nombre d’US par sprint. Il a fallu 3 sprints pour qu’elle réalise qu’en effet, elle avait bel et bien amélioré son delivery de manière significative et qu’elle pouvait donc augmenter son engagement. Ce qui a impliqué qu’en fin d’accompagnement, l’équipe, qui ne finissait aucun de ses sprints, terminait maintenant 144% de ses sprints ^^.

Comprenez-vous pourquoi l’équipe ne reviendra pas en arrière ?

Enseignements

François et son équipe ont tiré de nombreux enseignements précieux de cette expérience. Ils ont découvert la puissance du flux tiré, l’importance de la synchronisation des étapes et des processus, la valeur de la standardisation pour réduire la variabilité liée aux goulots de compétence, ainsi que l’impact d’un pilotage quotidien de la production.

Ils ont également appris une chose essentielle : l'importance de la mesure. Comme mentionné précédemment, l’équipe a traversé une période de turbulences au départ, et le défi pour François a été de leur faire tester des actions sans les engager à priori sur le long terme. Ce principe est un objectif commun à tous nos accompagnements : réussir à obtenir de l’équipe le bénéfice du doute pour créer un espace sécurisé d’expérimentation.

En montrant le lien concret qui existe entre les actions menées et l’effet sur la performance opérationnelle, non seulement l’équipe a vu l’intérêt de ces actions et ne reviendra pas en arrière (c’est la définition de l’apprentissage validé), mais elle a également développé une envie d’avancer par l’expérimentation. Avec cette liberté nouvellement acquise, l’équipe sait qu’elle peut tester des idées en s’appuyant sur la mesure pour décider de conserver, d’adapter ou d’abandonner de nouvelles pratiques.

Et pour ceux qui se demandent à quoi ressemble un A3, voici donc celui de François. Les données ne sont volontairement pas lisibles pour des raisons évidentes de confidentialité :

Tout cela a été mené d’une main de maître par François lors de ce projet Kaizen. En portant cette transformation de l'équipe, il a perfectionné sa pratique du management Lean avec les 5 pratiques définies dans le Toyota Way :

• Le Gemba pour aller sur le terrain, dans l’espace de travail des équipes, afin d’observer la réalité, loin des opinions ou des idées préconçues, et de comprendre les véritables conditions opérationnelles.
• Le Kaizen pour permettre à chacun, chaque jour, d’approfondir sa compréhension de son métier en posant des questions ciblées sur des sujets d’amélioration précis.
• Le Challenge pour permettre à l’équipe d’identifier de nouveaux obstacles et de transformer ces défis en opportunités d’apprentissage pour enrichir leurs compétences métier.
• Le Respect pour encourager les équipiers à devenir acteurs de leur propre amélioration en leur posant des questions plutôt qu’en leur disant quoi faire (ce sont les équipiers sur le terrain qui savent).
• Le Teamwork pour lancer des actions d’amélioration en collaboration avec d’autres équipes, même en dehors de leur périmètre direct, pour optimiser le flux de valeur global (comme l’équipe DATA).

Et cette transformation n’est pas une fin en soi. Désireux de poursuivre au-delà de ces six mois d’accompagnement en autonomie après ce coaching, François a défini ses prochaines étapes :

• Suivre le débit à chaque étape afin d’améliorer la fluidité du processus, en appliquant les mêmes méthodes que celles utilisées pour l’IT Review et la validation, mais sur l’ensemble du processus.
• Adopter le Kanban, qu’il perçoit désormais comme la suite logique de Scrum. Avec des IT Reviews et des livraisons quotidiennes. Pourquoi ne pas imaginer des sessions d’affinage courtes, plusieurs fois par semaine, pour accompagner cette dynamique ?
• Synchroniser le processus de production avec le processus en amont, en alignant la stratégie pour piloter la livraison des Epics en juste à temps pour le delivery.

Et vous, comment avancez-vous avec vos équipes pour réduire le time to market de vos features ? Quelles causes avez-vous identifiées et validées ? Quelles contre-mesures sont mises en œuvre ? Pour quels résultats ?