L’IA : Un levier stratégique et un outil opérationnel pour augmenter l’agilité à l’échelle. Quelques cas d’usages pour le prouver !

 
Je vous invite a retrouver mon article publié sur medium ici: 

https://medium.com/@fcmg23/lia-un-levier-stratégique-et-un-outil-opérationnel-pour-augmenter-l-agilité-à-l-échelle-d2d9c03a82ff

Créer un backlog transverse piloté par la valeur : l’ossature d’un train agile

Dans le premier article ( Une transformation agile vue de l'intérieur – récit d’un an de bascule collective), nous avons exploré les fondations de la transformation agile menée sur huit trimestres, en mettant en lumière les dispositifs humains, les rituels collectifs et l’importance du leadership incarné. Cette vue d’ensemble posait les bases d’un changement en profondeur.

Dans ce deuxième article, je vous emmène dans les coulisses de l’un des piliers structurants de notre transformation : la mise en place d’un backlog transverse de MMF et Enablers.

---

Un funnel unique, partagé, pour structurer la demande

L’une des premières difficultés rencontrées était celle-ci : trop de demandes, trop de formats, pas de filtre. Chacun avait ses urgences, ses arbitrages, ses tickets. Résultat : les équipes passaient leur temps à naviguer entre des priorités mouvantes et mal définies.

Nous avons donc mis en place un funnel de gestion de la demande, porté par plusieurs rôles clés :

• Les Business Owners (BO), représentants de leur métier, garants de l’usage pertinent des moyens IT pour répondre aux priorités business,

• Les Product Owners (PO), porteurs produits,

• Les Managers, acteurs du delivery et du pilotage,

• Les architectes ou sachants techniques et métiers, qui apportent un éclairage sur la faisabilité et les impacts techniques.

Le rôle des BO est central. Ils incarnent leur métier, valident les orientations et arbitrent les décisions liées à leur domaine. Ce sont eux qui, avec les PO et les architectes, alimentent le backlog avec des demandes à fort impact.

Trois sources principales alimentent ce funnel :

• Les demandes locales, portées par les équipes, les PO ou les architectes,

• Les demandes métiers, formalisées par les BO,

• Les initiatives stratégiques, issues de la roadmap de l’entreprise. Ces dernières sont déclinées en MMF et Enablers, puis prises en charge par des PO.

---

Un rituel spécifique : l’Entrance Gate

Pour traiter ces demandes, nous avons institué un rituel dédié, que nous avons appelé Entrance Gate. Ce rituel n’est pas un simple point d’échange : c’est un espace d’analyse, de clarification et de validation.

Chaque semaine, les parties prenantes (BO, PO, managers, architectes, UX...) y pitchent leur besoin, MMF par MMF. Les demandes sont challengées, reformulées, parfois fusionnées. On y vérifie la valeur, les risques, la faisabilité, les dépendances.

Pour qu’une MMF soit validée, elle doit :

• Avoir une description claire de la demande,

• Contenir des hypothèses de valeur chiffrées (euros, économies, efficacité… ),

• Proposer les premiers critères d’acceptation,

• Fournir les éléments nécessaires au chiffrage WSJF.

Quand une MMF est jugée complète, elle passe au statut "Ready" dans le backlog transverse. Elle devient alors visible pour le PI Planning à venir.

---

Un PO Sync pour piloter la vision et la roadmap

En parallèle, un PO Sync hebdomadaire réunit les PO, BO, architectes, managers... Il ne s’agit pas ici de traiter les demandes une à une, mais de piloter l’ensemble :

• Où en est la roadmap ?

• Quelles sont les priorités du prochain PI ?

• Quels éléments sont mûrs ?

• Quels sujets doivent être arbitrés au LACE ?

Ce PO Sync donne de la hauteur. Il structure la préparation des PI Planning à venir. C’est aussi là que l’on suit la maturation des MMF, métier par métier, et que l’on alerte sur les points bloquants.

---

Un backlog pour préparer, pas pour consommer

Une fois les MMF prêtes, elles alimentent le backlog transverse, en vue du prochain PI Planning. Ce backlog n’est pas un réservoir infini. C’est un instrument de pilotage : il permet de cadrer les engagements, d’anticiper les dépendances, de préparer les arbitrages.

C’est lors du PI Planning que les équipes décomposent les MMF en User Stories et en Enablers techniques. Elles construisent leur plan sprint par sprint, en lien avec les PO, les architectes, et les autres équipes.

Par ailleurs, certains sujets émergent directement du terrain : irritants techniques, besoins UX, chantiers transverses. Ces éléments viennent enrichir le backlog, avec le même niveau d’exigence sur la valeur et la clarté.

---

Conclusion : un backlog comme catalyseur de maturité

En un an, ce processus a changé la donne. Fini les demandes floues, les surprises de dernière minute, les tickets qui tombent du ciel. Le backlog est devenu un outil de convergence. Il structure le dialogue entre métiers et équipes. Il donne de la visibilité. Il cadre les engagements.

Mais surtout, il crée une dynamique collective. Car derrière chaque MMF validée, il y a un dialogue, un arbitrage, un engagement. Et c’est cette maturité-là qui fait la force d’un train agile.

Dans les semaines à venir, je publierai des zooms thématiques sur trois piliers majeurs de cette transformation :

1. Créer un backlog transverse piloté par la valeur
2. Organiser un PI Planning qui crée de l’alignement réel
3. Piloter une transformation par le ressenti, pas par les slides

Une transformation agile vue de l'intérieur – récit d’un an de bascule collective

Introduction : comprendre avant de transformer

Une transformation agile commence rarement par des outils ou des cérémonies. Elle débute par une réalité plus crue : des tensions, des dysfonctionnements, des douleurs. Des femmes et des hommes qui essaient de collaborer, mais qui se heurtent à des silos, à de la défiance, à de la fatigue. Avant d’imaginer des solutions, il faut écouter. Comprendre. Cartographier les irritants et les besoins. C’est par ce chemin que nous avons engagé une transformation à grande échelle.

Pendant plusieurs semaines, nous avons mené un travail d’observation et de diagnostic. Entretiens avec les équipes, ateliers de verbalisation, audit de l’existant : pratiques, outils, documentation, processus, flux de demandes. Nous avons notamment analysé les boards JIRA, les méthodes de priorisation, les interactions entre équipes, les points de friction avec les métiers. Nous avons confronté les ressentis avec des éléments factuels. Et ce travail de diagnostic a permis d’ouvrir les yeux collectivement.

Des verbatims forts ont émergé :

• « Le meilleur moyen d’obtenir quelque chose de l’IT, c’est de ne rien leur demander. »
• « On n’a pas de roadmap, pas de vision, tout arrive en vrac. »
• « Il y a des dépendances non gérées et personne pour les arbitrer. »
• « On est en silos, chacun optimise son coin. »

Le Heart of Agile, une approche simplifiée et puissante

 

Le Heart of Agile selon Alistair Cockburn : Une approche simplifiée et puissante

Alistair Cockburn, l'un des signataires du Manifeste Agile en 2001, a développé le "Heart of Agile" après avoir observé que les méthodologies agiles devenaient de plus en plus complexes et s'éloignaient des principes fondamentaux. Face à cette "inflation agile", il a proposé en 2015 un retour aux sources avec un concept remarquablement simple articulé autour de quatre impératifs.

Les quatre impératifs du Heart of Agile

1. Collaborer (Collaborate)

La collaboration est la pierre angulaire de l'agilité. Elle implique :

• Le travail d'équipe basé sur la confiance mutuelle
• La communication directe et transparente
• L'élimination des silos organisationnels
• La création d'un environnement psychologiquement sécurisé où chacun peut s'exprimer librement
• L'alignement des intérêts individuels avec les objectifs collectifs

La collaboration efficace requiert des compétences interpersonnelles fortes et une volonté sincère d'œuvrer ensemble vers un but commun.

Le Scrum Guide analysé par l'IA

 

Le Scrum Guide analysé par l'IA - Les axes d'améliorations proposés !

Voici les faiblesses / axes d'améliorations proposés par l'IA.

Attention, il faut garder en tête que le scrum guide est volontairement incomplet (c'est écrit dans le guide).

1. Généralité et manque de spécificité contextuelle

Le Guide Scrum présente un cadre délibérément minimaliste, ce qui constitue à la fois sa force et sa faiblesse. Par exemple, pour une équipe de développement de logiciels médicaux soumis à des réglementations strictes, le Guide n'explique pas comment intégrer les exigences de documentation et de validation dans les sprints. Une organisation financière pourrait se demander comment adapter les événements Scrum lorsque les parties prenantes sont dispersées à l'international et que les contraintes réglementaires imposent des cycles d'approbation complexes.

Amélioration possible : Le Guide pourrait inclure des annexes sectorielles ou des études de cas montrant comment les principes Scrum s'appliquent dans différents contextes comme la santé, la finance, l'aéronautique ou les services publics, avec des exemples concrets d'adaptation réussie.

 

Le Scrum Guide augmenté par l'IA

La Référence de Scrum : Les Règles du Jeu

Version Augmentée (et non retouchée) - Mars 2025

D'après l'œuvre originale de Ken Schwaber & Jeff Sutherland

Définition de Scrum

Scrum est un cadre léger qui aide les individus, les équipes et les organisations à générer de la valeur par des solutions adaptatives pour des problèmes complexes.

En résumé, Scrum nécessite un Scrum Master pour favoriser un environnement où :

1. Un Product Owner hiérarchise le travail pour un problème complexe dans un Product Backlog.
2. L'équipe Scrum transforme une sélection de ce travail en un Incrément de valeur pendant un Sprint.
3. L'équipe Scrum et ses parties prenantes inspectent les résultats et s'ajustent pour le Sprint suivant.
4. Ce cycle se répète.
   
   

PI Planning : un investissement stratégique pour l'efficacité et l'alignement des équipes

Justifier le coût/investissement du PI Planning : une perspective SAFe 6.0

En tant qu'Expert en Tranformation des Organisations,  Coach Agile, RTE ou consultant certifié SAFe 6.0, nous sommes souvent sollicités pour convaincre des managers et investisseurs de l’importance d’investir dans un PI Planning, un événement clé du framework SAFe. 

Par exemple, il y a quelques années lors de la transformation d'une grande tribu chez un assureur du CAC 40, la responsable de la tribu m'a beaucoup challengé sur la pertinence de faire le PI Planning et de l'optimiser (1 jour à la place de 2). Sa question était  : "Pourquoi mobiliser une centaine de personnes pendant deux jours ? Quel est le retour sur investissement (ROI) d’un tel événement ? Je ne peux pas me permettre d'avoir 100 personnes improductives aussi longtemps."

Afin d'y repondre j'ai scénarisé les diverses situations en fonction de l'observation des equipes et de l'excès de coordination inefficace en place. J'ai pu obtenir les indicateurs qui ont permis l'argumentation que je vous presente ci-dessous.

Pour répondre de manière claire, il est essentiel de comprendre ce qu’est un Agile Release Train (ART) et un PI Planning, ainsi que les bénéfices qu’ils apportent. (Cet accompagnement avait d'ailleurs débuté par une formation sur ces elements theoriques pour bien aligner le manager sur la finalité).

Et si le vrai moteur de l’agilité et de la transformation, c’était le leadership ?

 

Cette citation illustre parfaitement le rôle essentiel du leadership dans les transformations agiles. Dans un contexte de transformation digitale, le coach agile joue un rôle fondamental pour intégrer tous les acteurs du changement, y compris les managers, souvent laissés de côté. Pourtant, leur implication précoce et active est déterminante pour le succès du processus.

 

Cet article explore comment, en tant que coach, j’intègre efficacement les managers dans le cadre d’une transformation agile avec le train SAFe, en adressant les différentes situations et en assurant une adoption progressive et consolidée en m’appuyant massivement sur le manager. Ce manager devient Sponsor et dans certaines situations co-coach. Nous ne développerons dans cet article l’accompagnement vers l’agilité des équipes qui est un travail en parallèle de l’accompagnement du coach (charge principale des Scrum Masters et RTE). L’idée est d’avoir un accompagnement unifié, cependant lors du lancement d'une transformation le manager présente un défi important, à résoudre dès les premières semaines.

 

 

---

Le rôle du coach dans l'intégration des managers

Un acteur clé dès le départ

Un manager ne peut être un simple spectateur dans une transformation agile. Il doit devenir un véritable acteur de la dynamique. Le coach agile a pour mission de l’accompagner pour qu’il passe d’un rôle d’observateur ou de décideur à celui d’acteur clé. Cela implique de comprendre ses motivations, ses résistances et son environnement.

Pourquoi est-ce crucial ?

• Structurer la transformation en alignant les équipes sur les objectifs stratégiques.
• Faciliter les échanges entre les différents acteurs de l’organisation.
• Agir comme sponsor du changement, en montrant l’exemple.
• Pour le coach : s’assurer que le manager ne distillera pas des messages contraires pouvant planter la transformation, les équipes écoutant naturellement leur manager.

 

 

Release Train Engineer (RTE): Postures, défis et réalités du terrain

Les responsabilités du SAFe RTE : Mon retour d'expérience et ma vision après plus de dix implémentations

Après avoir joué le rôle de Release Train Engineer (RTE) dans plus d'une dizaine de transformations ces dernières années, je souhaite partager mon expérience et ma vision de ce rôle clé dans le cadre du Scaled Agile Framework (SAFe). Cet article présente à la fois les éléments canoniques du rôle tels qu’ils sont définis par SAFe, mais aussi mes propres observations et constats tirés du terrain. Le rôle de RTE va bien au-delà des théories et des certifications et c’est à travers cette perspective que je vous propose de l’explorer ici.

Product Vision Canvas : l'outil pour une Vision Produit alignée et agile 2/2

Product Vision Canvas

Dans le premier article, nous avons vu à quel point une vision produit claire est cruciale pour l'alignement des équipes et la réussite des projets agiles. Dans cette seconde partie, nous allons plonger dans l’utilisation pratique du Product Vision Canvas, un outil spécialement conçu pour structurer et partager une vision produit alignée. Cet article vous expliquera comment utiliser cet outil pour aligner les parties prenantes, clarifier les objectifs et booster la collaboration au sein de vos équipes.

Commençons par une présentation détaillée des composantes clés du Product Vision Canvas et des bonnes pratiques pour l'implémenter efficacement.

Comprendre l’outil “Product Vision Canvas”

Comme vu précédemment, le manque de vision est problématique pour les équipes et l’Entreprise. Dans la suite de cet article, nous allons analyser un outil: Le Product Vision Canvas. Cet outil est utilisé pour définir et aligner la Vision d'un Produit. Créé par Roman Pichler, cet outil est libre d'utilisation et est particulièrement utile dans un contexte agile. Il permet de simplifier la vision du produit pour la rendre facilement partageable avec toutes les parties prenantes.

Product Vision Canvas : l'outil pour une Vision Produit alignée et agile 1/2

Pour les Product Owners et Product Managers soucieux d'aligner toutes les parties prenantes sur une vision produit claire et agile, le Product Vision Canvas s'avère être un outil indispensable. Découvrez comment il peut transformer votre approche produit et sécuriser la collaboration, le discovery, le développement et le delivery.

Comprendre l’utilité de la  Vision Produit

Dans le contexte d'une Entreprise agile passé au mode produit, la Vision Produit est un élément essentiel qui joue un rôle clé à plusieurs niveaux. Voici pourquoi elle est particulièrement importante :

1. Alignement des équipes

Une vision produit claire permet de fédérer toutes les parties prenantes (équipes techniques, marketing, commercial, direction) autour d'un objectif commun. En agile, où les équipes sont souvent autonomes, la vision produit sert de boussole pour orienter les décisions à long terme, même dans un cadre de développement itératif.

2. Cohérence des priorités

Avec une vision définie, il devient plus facile de prioriser les fonctionnalités et les initiatives. Les Product Owners et les équipes de développement peuvent mieux déterminer ce qui apporte le plus de valeur à long terme, en s'assurant que chaque itération va dans le sens de la réalisation de cette vision.

Gérer la dette technique agile : bonnes pratiques pour maintenir la qualité du code

 Dans le monde de l'agilité, la dette technique est un défi constant. Ce guide offre des astuces pour les développeurs et les Scrum Masters souhaitant maintenir un code de qualité tout en répondant aux exigences agiles.

Comprendre la dette technique agile

Définition et concepts fondamentaux

La dette technique est une métaphore qui décrit le coût futur de choix de conception ou de développement à court terme. Dans un contexte agile, elle peut avoir un impact significatif sur la qualité et la maintenabilité du code. Souvent négligée en raison de la pression pour livrer rapidement, elle peut entraîner des conséquences coûteuses à long terme.

Atelier de Story Mapping : guide complet pour une facilitation agile et efficace

 

 

Introduction

La story mapping est un outil incontournable pour les équipes agiles. Découvrez dans cet article comment j’enseigne aux Product Owner ou Product Manager à animer un atelier de Story Mapping étape par étape pour permettre aux équipes de collaborer efficacement et de transformer vos projets en succès. Cela permettra de partir avec un backlog exhaustif pour un Cas d’Usage donné, ainsi qu’une roadmap de delivery prévisionnel.

 Ce guide détaillé, étape par étape, vous permettra  d’assurer une facilitation rigoureuse et productive.

L’attaque des titans : une leçon d’agilité à grande échelle à travers le bataillon d’exploration (Vidéo)

 

Le monde du manga et celui des méthodologies agiles peuvent sembler très éloignés. Pourtant, en observant de près certaines œuvres, comme L’attaque des titans, on y trouve des parallèles étonnants avec les concepts agiles, notamment le Scaled Agile Framework (SAFe). Ce manga, devenu une référence mondiale, illustre à travers le bataillon d’exploration des principes similaires à ceux utilisés dans la gestion de projets IT complexes. Cet article explore ces analogies et montre comment une opération militaire fictive peut refléter les fondements de l’agilité à l’échelle.

Cet article illustre l'analyse que je fais dans cette video, que je vous recommande fortement:

(cliquer sur l'image pour lancer la video)

Dans cette video on peut voir: 

• le recueil d'information par le instance du bataillon (refinement)
• l'explication des élèments, enjeux, etc... (alignement PI Planning)
• le plan, la roadmap,
• chaque équipe prévoit ses actions (Team Breakout)
• l'évaluation des risques (ROAMing des risques
• et pour finir l'exécution du plan étape par étape.

Le rôle central de l'architecture dans l'agilité à l'échelle : clés et pratiques

L'Architecture est souvent un élément méconnu mais crucial dans la réussite de l'agilité à l'échelle. Dans un monde où la transformation digitale est la norme, comprendre le rôle de l'architecture peut faire toute la différence pour les entreprises souhaitant évoluer efficacement. Cet article explore les rôles clés des System Architect et Enterprise Architect, et comment ils peuvent devenir des moteurs de l'agilité dans votre organisation.