Transformation Agile SAFe · LPM

Vos trains SAFe sont-ils bien connectés à vos LPM ?

... Ou est-ce plutôt "je t'aime moi non plus" 🥴 ?

Jean-Paul DUFOUR · 13 juin 2024 · Transformation Agile SAFe

🎦 Contexte

Lors du déploiement de SAFe, quid du lien entre les décisions LPM et leur implémentation dans les trains ?
Faisons un focus sur les décisions LPM concernant la maturation du besoin dans les EPIC et ENABLER de même granularité :
— Une activité à 70% en mode projet clients (RFP et Change Request), très peu d'initiatives internes provenant du marketing produit
— Une large solution avec plusieurs trains

☢️ Problématiques majeures observées

— Manque de lien cohérent entre ce qui est lancé dans le LPM "GO for implementation" et le backlog des trains
— Les cérémonies pre/post PIP et Sync large solution manquant d'engagement et d'utilité
— Pas ou trop peu d'industrialisation des tests E2E, sinon à l'arrache, rarement anticipés

💩 Impacts

— Un delivery entaché de dette technique qui alimente les coûts de non-qualité
— Un défaut permanent d'alignement et synchronisation malgré la large solution qui est de fait considérée comme inutile par les trains
— Un post PIP qui n'est qu'une chambre d'enregistrement des sujets reportés au prochain PI et des désalignements manifestes entre trains
— Un contenu de backlog des trains surprenant, non priorisé par la valeur pour certains trains
— Pire : des Capabilities constituées à la volée dans la large solution par agrégat de features provenant des trains : démarche bottom-up incohérente et inquiétante
— Tensions permanentes dans les équipes dans les trains, car on ajoute de nouvelles features sans en arbitrer d'autres à enlever ou reporter de manière cohérente avec les objectifs business

🛠️ Proposition de solution (la plupart sont des trous dans la raquette du framework SAFe)

— Fluidifier les flux entre les décisions LPM (Continuous Exploration) et leur implémentation dans la Large Solution et les trains (CI/CD)
— Réconcilier le rythme (ad hoc en amont, PI en général sur 3 mois en aval) et la complexité des artefacts manipulés
— Mise en œuvre entre le GO de décision et la préparation du prochain PI Planning : durant la phase de backlog/ready du kanban du LPM
— Découpage de chaque EPIC en capabilities puis features pour les capabilities les plus prioritaires
— Roadmapper les capabilities et leurs impacts macro sur les trains concernés, en lien avec une stratégie incrémentale d'implémentation
— Analyser l'équilibre entre charge et capacité disponible dans les trains pour réduire la tension dans les équipes
— Renforcer les rôles clés des BO et architectes et l'esprit de collaboration LPM/Trains

🏆 Bénéfices

— Une large solution qui retrouve sa légitimité, dans la préparation des PI Planning comme dans le suivi de l'atteinte des objectifs
— Une meilleure préparation dans les intentions de la solution de chaque EPIC, intégrant les tests et la roadmap des incréments de valeur
— La recherche de l'utilité et légitimation des system démo et large solution démo, et non plus seulement par composant en silo
— Une meilleure définition et prise en compte des priorités business du LPM, tenant compte de la capacité disponible dans les trains
— Une meilleure répartition de la capacité dans les trains selon les prévisions macro de charge dans chacun

🤜🤛 Partageons

Et vous, avez-vous observé de telles difficultés et/ou d'autres non évoquées ici ?
Comment avez-vous résolu cette difficulté, comblé les manques de formalisation du framework SAFe ?

#SAFe #LPM #LargeSolution #PIPlanning #AgileAtScale