SAFe : Réconcilier les enjeux métiers du LPM et le pilotage du delivery avec le Lean

Nous sommes fréquemment sollicités pour intervenir auprès de directions tech pour améliorer l’efficacité opérationnelle de programmes agiles. Si la mise en place de SAFe peut apporter un cadre de travail agile à l’échelle de l’entreprise, nous constatons que les clients qui nous demandent de l’aide rencontrent de nombreux sujets pour ce qui est du delivery (i.e. du pilotage de ce qui est livré) mais aussi, dans le cas qui nous concerne aujourd’hui, dans la connexion entre, d’une part, le portefeuille des projets métiers (LPM) et, d’autre part, le pilotage du delivery des équipes qui composent ce ou ces trains SAFe.

Dans ce contexte précis, au terme des PI (Incréments Produits), l’équipe pilotant le train (RTE, PO, PM, SA, Scrum Masters) présente des chiffres qu’elle estime plutôt satisfaisants en termes d’engagement alors que les métiers ont la perception, de leur côté, que leurs projets ne progressent pas. Ils avouent au terme des PI Planning (sessions de planification trimestrielles des incréments produits) qu’ils ne comprennent pas ce que le train doit réussir lors du prochain incrément pour faire avancer leur projet.

L’objectif de cet article est de montrer comment, avec le regard et les outils du Lean (i.e. du TPS - Toyota Production System), nous allons parvenir à réconcilier ces deux visions, clarifier les conditions de la réussite pour les uns comme pour les autres, et obtenir à la clé des résultats spectaculaires.

Contexte

Un train SAFe d’une quinzaine d’équipes Produit et de 150 personnes au sein d’une DSI des services financiers travaillant sur 17 projets métiers en parallèle.

Les 15 équipes produit sont dédiées à un produit logiciel ou un composant technique ; les 17 projets s’appuient quant à eux, sur ces produits ou composants pour livrer la valeur métier attendue sous la forme opérationnelle de Features (i.e. fonctionnalité : un projet est composé de plusieurs Features). Enfin le “cockpit” (Release Train Engineer – RTE- , Product Owners -PO- et Scrum Masters) pilote le train avec à chaque incrément produit des cibles pour les trois engagements suivantes :

1. La mise en production (MeP) ;
2. La recette métier ;
3. La recette IT

Problème

Afin de donner une vision claire et partagée de la situation nous commençons par dresser un état des lieux pour ce qui est de la satisfaction client et de la performance.

Clients

Pour les clients (métiers) il existe une certaine frustration car la perception est que les projets ne sortent pas et ne sont pas maîtrisés : sur les 17 projets, aucun n’a atteint son engagement. Le Net Promoter Score (NPS) obtenu au terme de ces entretiens est de -14, une évaluation plutôt médiocre. Quelques verbatims pour illustrer cette frustration :

● “Les projets ne sont jamais terminés, sur le sujet ZZZ ce sont les équipes terrains qui sont obligées de reprendre les opérations à la main depuis 2016 (60 personnes)”

● “On manque de vision, on rajoute des rustines et des rustines … et on est devenus des experts Excel”

● “On est incapables d'analyser le business malgré l'argent dépensé”

● “Nous en sommes à 5 reports de trimestre.”

● “J'ai attendu 4 ans pour une tâche évaluée à 0,75 j/h”

● “J'ai posté ma demande en 2019 et on m'a relancé en juin 2024.”

● “Je pense qu'il y a un blocage collectif. Ils n'ont jamais le temps de s'occuper des petites tâches.”

● “Ce que je souhaite, c'est que les livraisons soient bonnes du premier coup et faites dans un délai raisonnable. Il faudrait aussi savoir à qui parler, sans être perdu derrière un ticket.”

Performance

D’une manière plus chiffrée, sur les 5 précédents incréments produits (PI), chaque PI durant environ 3 mois :

● L’engagement est à 26% en moyenne sur les 3 objectifs (MEP, Recette Métier ; Recette IT), c’est à dire que le train a livré chaque trimestre en moyenne le quart de ce qui était prévu ;

● Le nombre de features livrées en moyenne est de 33,4 par incrément.

Analyse des causes

Collaborateurs

De leur côté, les collaborateurs expriment une grande insatisfaction liée au processus de réalisation des demandes externes ainsi qu’à un sujet qui nous intéresse tout particulièrement, illustré par ce verbatim d’un PO en réponse à la question : “Qu’est-ce que selon vous un PI réussi ?” : “Un trimestre réussi, c'est lorsque nous avons réussi à lancer de nouveaux projets”.

Comme nous allons bien vite le constater, le problème principal est que ce train fonctionne en flux poussé (avec un focus sur les nouveaux sujets qui sont démarrés), plutôt qu’en flux tiré (comme le préconise le Lean, avec un focus sur ce qui est termin**é).

Le second point clé remonté par les collaborateurs est celui des dépendances qui est le principal obstacle que nous rencontrons dans les organisations en mode produit dans lesquelles nous intervenons (ce qui nous fait nous questionner sur la pertinence de l’organisation des équipes) : comment s’assurer que les dépendances sont bien livrées lorsque c’est prévu et qu’elles sont bonnes du premier coup ? Comme toujours, les changements incessants de priorité (qui s’accroissent de façon exponentielle à mesure que le work-in-progress augmente) ont bien vite raison de la planification en flux poussé.

Pilotage

La notion de flux poussé apparaît de façon flagrante lorsque l’on construit l’histogramme par incrément produit des features en cours de réalisation Vs. les features terminées sur le PI :

Pour une moyenne de 33,4 features terminées par PI, il y a un encours moyen de 211 features (un work-in-progress qui représente alors 19 mois de travail (!)).

Cela a un impact direct sur l’engagement du train (i.e. nombre de features terminées Vs. prévues) :

Nous cherchons à comprendre si le pilotage quotidien du train permet réellement d’éviter ces écueils en lien avec les retours des métiers. En particulier, nous voulons vérifier si ce pilotage aide les équipes à terminer leurs sujets régulièrement.

Las ! toutes les features sont planifiées de façon à être terminées les deux dernières semaines du trimestre. Lors des points de synchronisation hebdomadaires du train (Scrum de Scrum), nous constatons que les discussions portent essentiellement sur les fonctionnalités qui n’ont pas encore démarrées et sur des divergences de mise en œuvre de pratiques agiles au sein du train. Nous observons qu’il y a très peu d’attention portée aux sujets concrets à terminer cette semaine. De plus, nous voyons peu d’échanges sur la manière dont les équipes s’organisent entre elles pour finir ces travaux.

Causes de non-finalisation des features

Plutôt qu'une analyse déclarative basée sur les seuls entretiens, comme dans les diagnostics classiques, nous complétons ces échanges d’une analyse factuelle. L’analyse déclarative reste souvent au niveau des opinions et permet rarement d'atteindre un consensus. L'approche Lean, elle, est data-driven avec des éléments spécifiques. Nous examinons des échantillons de features non terminées et cherchons à comprendre les causes de ces échecs. À titre d’illustration, nous avons analysé les résultats du dernier incrément (PI).

Sur les 92 features embarquées lors de ce dernier incrément, 67 disposaient d’un engagement clair (mise en production, recette métier ou recette IT), tandis que 25 features étaient sans engagement défini. Parmi ces 67 features engagées, 18 ont été livrées en production (26 %) et 10 en environnement de recette métier, soit un total de 28.

Parmi les 49 (67-18) features non terminées, 27 d’entre elles (55 %) sont au terme du PI en phase de validation (Tests IT, Tests Perf et Recette). 13 autres features (26 %) restent en cours de développement.

Ce constat illustre clairement une dynamique de flux poussé : les développeurs envoient le code terminé vers la QA, puis enchaînent immédiatement sur une nouvelle feature.

Statut des Features non terminées

Concernant les causes des non terminées, 36 features (73%) ont été décalées suite à des dépendances non résolues dont 19 ont rencontré des problèmes d’environnement de qualification et 11 des sujets de non disponibilité de la donnée.

Causes des Features non terminées

Quelques exemples pour illustrer les problèmes rencontrés par les équipes :

● FEATURE-1 :

Cette feature comprend 8 User Story (US) dont 5 terminées. Parmi les 3 US non terminées, une est en attente d’une dépendance avec l’équipe A pour une liaison de données sur une table.

Il aura fallu plus de 120 jours entre la demande effectuée le 9 juillet et la fin de la recette le 4 novembre.

Nous constatons également que 7 features non terminées (14,3%) ont été reportées suite à des retours en arrière du besoin métier. Exemple :

● FEATURE-2 :

Cette feature créée le 9 juin 2023 comprend 39 User Stories, dont seulement 11 sont terminées 464 jours après sa création. Sur les 27 US restantes, 26 % n’ont pas encore démarré leur développement.

Après analyse des raisons du décalage, nous avons remonté deux causes principales :

Un changement de conception concernant la gestion d’une application de CRM, couplé à une dépriorisation côté métier, a généré un surcoût de 6 heures par sprint, dédié au maintien des versions des branches.

Un manque de données a freiné l’avancement d’une équipe tout au long d’un PI : présence de tables vides en environnement de recette, besoin de données variées (adresse, durée du projet, etc.).

● FEATURE-3 :

Cette feature comprend 4 US dont 3 terminées. Une US non terminée clôture le PI en état de test de recette après 126 jours dans cette phase. La cause est due à une évolution du besoin pour correspondre à un autre projet.

Qualité des Features

Dans le Lean, nous regardons en tant que critère de qualité, les pièces qui sortent bonnes du premier coup (Right First Time - RFT). Voici l’analyse de qualité d’un échantillon de 11 features, sachant qu’une Feature est Right First Time à la condition que toutes les US qui la composent le sont aussi.

Nombre d'US Right First Time par feature

Sur cet échantillon, seules 2 Features sont bonnes du premier coup parmi les 11 analysées.

Parmi les 9 Features ayant eu des retours en arrière, 4 s'expliquent par des évolutions en raison d’un manque de maturité des besoins métiers, il s’agit de la cause principale observée ici.

Causes de retard des features

Concernant les causes des délais, le lead time moyen des 11 Features analysées est de 269 jours. Le délai s’explique principalement par des attentes en phase de recette de qualification.

6 Features sur les 11 analysées ont aussi des attentes suite à des évolutions du besoin.

La feature “FEATURE-20” illustre les causes des retours en arrière et les causes des délais d’attente les plus importants : avec 3 décalages de la mise en production. Le besoin a été revu entre-temps par le métier. Il n'était pas au bon niveau de maturité et de cohérence avec un projet concourant.

Ce que nous avons mis en place

Réconcilier le portefeuille projet et le delivery avec le management visuel

Après avoir posé le diagnostic grâce à l’immersion, et après l’avoir partagé avec les équipes, nous lançons la phase de mise en œuvre. Lors de celle-ci, un des premiers sujets est de lancer le pilotage de la production. Dans l’ouvrage collaboratif “Apprendre à Apprendre”, les auteurs (Michael Ballé, Jacques Chaize, Régis Médina et Anne-Lise Seltzer) expliquent que :

“La spécificité du Lean est d’intégrer l’apprentissage dans le temps de travail. Pour “amorcer la pompe” de cet apprentissage, il faut mettre une organisation simple en partant du tempo des livrables*. Ce tempo permet de s’attaquer en même temps à la réalisation du travail et à son exploration.”*

Nous allons donc construire notre plan de production pour clarifier notre “tempo des livrables” et découvrir chaque semaine ce que nous devons apprendre pour nous améliorer.

Pour cela nous posons clairement la nomenclature des projets pour comprendre ce que nous devons réussir chaque semaine. Cette nomenclature à trois niveaux (des Projets composés de Features, elles-mêmes composées de User Stories) peut sembler simple à comprendre a priori, mais la piloter de manière à conserver une vision claire et partagée de l’avancement avec chacun est un tout autre sujet. Par ailleurs nous devons en parallèle piloter trois engagements différents : ceux qui concernent la mise en production ; la recette métier ; et enfin la recette IT (des équipes de réalisation).

Nous décidons donc d’utiliser un management visuel qui va représenter dans trois tableaux (un par engagement)

1. les projets (en ligne) ;
2. les semaines du PI (en colonnes) ;
3. les Features qui composent ces projets sous forme de post-its positionnés sur la bonne ligne (du bon projet) et la colonne (de la semaine de livraison).

Pour chaque projet, on rappelle la cible du nombre de features à livrer sur les 12 semaines du PI ainsi que le nombre de features livrées à date. Enfin, nous avons explicité le nombre d’US cibles Vs terminées par feature. Nous avons ainsi créé les conditions pour identifier les dérapages de périmètre fonctionnel.

L’illustration ci-dessous représente ce management visuel avec les éléments clés :

1. Le suivi des features terminées
2. Le pilotage des features terminées dans chacun des projets (un projet par ligne)
3. Le suivi des features prévues par semaine
4. Le pilotage visuel des dépendances
5. Le pilotage hebdomadaire (voir section suivante)

On pourra nous objecter qu’il existe déjà un tableau standard, le “ART planning board” que propose SAFe mais (le diable est dans le détail) celui-ci présente de nombreux inconvénients pour ce qui est de piloter le delivery durant le PI. Tout d’abord il n’y a pas de lien visible entre les features et les Epics du portefeuille (LPM). Ensuite, on ne pilote pas avec cet outil, comme ici la production, avec le nombre de features terminées vs. à terminer, d’US terminées vs. à terminer. Il s’agit là de l’élément clé du management visuel Lean pour définir les conditions de réussite, et créer ainsi les conditions de l’auto-organisation des équipes. En outre, cela permet aussi de voir les écarts et d’arrêter la dérive en travaillant sur les causes.

Exemple de résolution de problème sur le delivery

Lors de notre synchronisation hebdomadaire en Scrum of Scrum sur notre management visuel, nous avons constaté que la Feature-28 a dérivé à deux reprises. Afin de comprendre les causes de ce décalage et d'apporter une amélioration, nous avons initié un PDCA.

Le décalage est de 14 jours par rapport à l’engagement. En utilisant la méthode des 5 Pourquoi avec le PO côté métier, nous découvrons que l’ajout de nouvelles User Stories (US) était dû à une évolution du besoin.

Nous avons défini deux actions correctives pour répondre à la cause du problème :

1. Action court terme : Regrouper les nouvelles US dans une nouvelle feature pour le prochain PI, afin de permettre la livraison en production des US de la feature 1148 comme prévu.
2. Action long terme : Lancer un chantier d’amélioration des découpages de Features en créant un standard de découpage pour éviter ce type de problème à l’avenir.

Les nouvelles US ont été regroupées dans une nouvelle feature, et la Feature-28 a été livrée en production sans les ajouts. Nous avons organisé un atelier avec l’équipe pour définir un standard de découpage des Features, garantissant une granularité qui permet de limiter les changements en cours de PI.

Suite à l’atelier, nous avons identifié la nécessité d’utiliser des enablers en amont, afin de construire un socle, permettant ensuite un découpage des features aligné sur les différents besoins métiers, tout en assurant une livraison progressive de valeur.

Cette pratique a permis de stabiliser les besoins en cours de PI et d’augmenter nos engagements sur 3 autres features qui se sont retrouvées dans ce cas. Le second bénéfice est d’avoir permis de faire basculer la culture des PO par la pratique, les faisant passer d’un mode "tout livrer pour être sûr de répondre à tous les besoins possibles dans une même feature" à une logique de livraison progressive d’incréments de valeur pour favoriser l’apprentissage tout en sécurisant le delivery.

Piloter les dépendances

Enfin, comme toute organisation produit, le pilotage des dépendances est un sujet clé. Nous décidons donc de rendre ces dépendances visibles sur le management visuel et cela devient un sujet d’échange hebdomadaire : l’équipe A va-t-elle bien livrer telle dépendance à l’équipe B dans les temps pour que la feature XYZ soit livrée la semaine 8 du PI comme prévu ?

Pilotage hebdomadaire

Avant la mise en œuvre du Lean, l’équipe “cockpit” du train (les rôles encadrants : Scrum Master ; Product Owner ; Chefs de Projets) se voyait déjà chaque semaine lors de la cérémonie SAFe du “Scrum de Scrum” pour discuter des projets mais avec une vision flux poussé (c’est à dire en commençant par les nouveaux sujets qui viennent d’entrer). Un autre sujet traité était les risques avec un pilotage de la gestion des risques avec un bon vieux fichier Excel comme le préconise le PMI.

Les sessions de pilotage changent alors du tout au tout. Plutôt que se demander quel est le nouveau sujet que nous avons fait entrer dans notre processus de livraison, la question va être, semaine après semaine : Quelles sont les US que l’on doit terminer cette semaine pour terminer quelle feature pour atteindre l’objectif de notre portefeuille projet (LPM) ? Quels sont les statuts des US non terminées, par feature ? Afin de se concentrer sur celles les plus proches du “done”. Ainsi, la question “qu’est-ce qui pourrait nous en empêcher ?” prend un tout autre sens.

Il s’agit de questions particulièrement fertiles, qui, en outre, créent les fameuses conditions de l’auto-organisation. Les risques sont ainsi pilotés non plus dans une feuille Excel mais sur notre tableau de production, en temps réel. Il n’est plus question de changer de priorité pour ne pas livrer telle dépendance et lui préférer un autre sujet car l’ensemble de l’équipe Cockpit s’est engagée et mobilisée pour livrer telle feature cette semaine-là. Durant cette heure de synchronisation, les trois tableaux sont parcourus avec ce questionnement et ce travail collaboratif de haute intensité.

Au début, les Scrum Master et PO ne sont pas très à l’aise avec ce suivi qu’ils peuvent identifier à du micro-management. L’engagement sans faille de la sponsor, avec qui nous échangeons chaque semaine pour lui remonter les avancées et les points de blocage, a permis de gérer ces sujets assez rapidement et de trouver les bons leviers pour mobiliser les équipes. Et, alors que l’équipe constate qu’elle livre régulièrement et que son indicateur de suivi de Features livrées avance lui aussi de façon régulière, elle réalise le caractère vertueux de la démarche : nous ne sommes plus dans la situation où toutes les features sont à livrer en dernière semaine (même si une partie le demeure).

Résultats

Même si nous sommes plutôt satisfaits du management visuel et du nouveau pilotage, le Lean reste une démarche empirique et ce sont les résultats sur la performance opérationnelle qui vont nous dire si cela fonctionne dans le contexte de ce train.

Nous comparons donc la moyenne des résultats des 2 PIs ayant bénéficié de l’accompagnement Lean avec celui de la moyenne des 5 PIs précédents. Les résultats sont spectaculaires :

· Delivery : nous sommes passés d’une moyenne de 33,4 features livrées par PI à une moyenne de 62,4 – soit un gain de 85% de valeur livrée en plus par trimestre pour ce programme de 150 personnes. On pourra nous objecter qu’il ne s’agit pas de productivité en tant que telle, car nous ne connaissons pas l’impact sur le coût unitaire de chaque projet, mais dans le Lean, on se concentre sur le pilotage de la valeur livrée (et pas celui des coûts) et celle-ci a effectivement augmenté de 85%. On retrouve ainsi les principes énoncés dans un précédent article lié au regard Lean sur le delivery des programmes agiles.

· Engagement : nous sommes passés de 26% d’engagement (features livrées Vs. prévue) à 78%, un gain de 56 points et un engagement multiplié par trois*.*

· Satisfaction client : le NPS est passé de -14 à +75 – un gain de 89 points

· Satisfaction Collaborateurs : pour cette mise en œuvre du Lean, le eNPS est de +50

Enseignements

L’équipe du « Cockpit » du train a bien appris à piloter les objectifs de son portefeuille projet avec, d’une part, la mise en place du management visuel, et, d’autre part, l’animation du Scrum de Scrum concentrée autour du pilotage des features que l’on termine chaque semaine.

Les Scrum Master de leur côté ont compris comment bien embarquer les bonnes US pour terminer les bonnes features semaine après semaine. Une Scrum Master nous a partagé un retour qui illustre bien la valeur apportée par notre pilotage visuel. Je la cite : “Au début, j’avais peur que l’on suive l’avancement des sujets un par un, mais en réalité, cela nous permet de nous projeter à la semaine et de nous organiser sur l’essentiel.” Par la suite, elle est devenue l’une des personnes les plus engagées dans l’alimentation du management visuel, ayant pleinement compris l’intérêt de ce type de pilotage.

Les PM et PO métier ont appris à ne plus perturber la phase de delivery avec de nouvelles demandes dans des features déjà lancées. Un travail a été réalisé pour mieux découper les Features et introduire la notion d’Enabler pour mieux anticiper les prérequis techniques et fonctionnels concourant entre projets. Ce découpage rend ainsi plus modulaire les fonctionnalités livrées par incrément. L'objectif est de garantir, avant chaque PI, que les Features soient totalement prêtes à entrer en réalisation.

Les collaborateurs ont appris à se concentrer sur la finalisation des bonnes Features afin de respecter leurs engagements, en évitant la mauvaise habitude de démarrer plusieurs sujets simultanément dans l'unique but de rassurer par un avancement apparent. La mise en place du management visuel au sein du cockpit a permis d'identifier clairement les problèmes de nivellement de la production, ce qui facilite le lissage des engagements et favorise la réalisation complète des sujets prioritaires.

Enfin, en tant que coachs, nous voyons une fois encore la formidable puissance du pilotage de la valeur opérationnelle qu’apporte le Lean. En clarifiant les objectifs de réussite chaque semaine, en créant les conditions de l’auto-organisation et en analysant les écarts rencontrés de façon hebdomadaire, le Lean apporte des pratiques de pilotage et d’apprentissage qui permettent de revenir aux sources de l’agilité comme nous l'évoquions dans cette série d’articles. L’impact direct ici aura été de créer un lien beaucoup plus actionnable entre le delivery opérationnel des équipes et la vision portefeuille projets des métiers.