Jira : miroir de votre agilité ou amplificateur de vos travers ?

Par Pierre Medina – Coach agile Senior, SPC/RTE Senior, formateur (Nombre de mots : 2 230 / Temps de lecture estimé : 11 minutes)

Dans l’un de mes derniers accompagnements, je suis tombé sur un backlog Jira de 2 000 tickets. Des user stories, des bugs, des tâches techniques, des items qui traînaient depuis 3 ans.

Quand j’ai demandé au Product Owner s’il pouvait m’expliquer ce qui était encore valide, il a hésité, puis m’a dit : « Franchement, je ne sais plus. Je n’ose même plus ouvrir le backlog. »

Jira n’était pas le problème. Jira reflétait exactement ce qu’ils faisaient. C’est ça qu’il faut comprendre : Jira est un outil. Il montre ce que vous mettez dedans. Ni plus, ni moins.

Ce qu’on attend (ou espère) de Jira dans une équipe agile

• Un backlog structuré, clair, priorisé
• Une coordination fluide entre PO, SM, devs
• Des rituels outillés, basés sur des données fiables
• Un pilotage visuel des flux
• Des indicateurs utiles pour décider, pas pour contrôler

Du MVP en quelques semaines au prototype interactif en quelques minutes : Comment le "Vibe Coding" révolutionne le quotidien des Product Managers

Pour tout Product Owner (PO) ou Product Manager (PM), le mantra est le même : valider les idées rapidement, itérer et livrer de la valeur. Pourtant, le chemin de l'idée à un produit tangible, même une simple version minimale viable (MVP), est souvent long et semé d'embûches. Il implique des spécifications détaillées, des maquettes statiques et, surtout, une dépendance quasi totale aux ressources de développement.

Et si vous pouviez court-circuiter ce processus ? Si vous pouviez transformer une idée en une application fonctionnelle en quelques minutes, simplement en la décrivant ? Ce n'est plus de la science-fiction, c'est la promesse du "Vibe Coding", une nouvelle approche qui outille les PM comme jamais auparavant. Des outils comme Lovable sont à l'avant-garde de cette révolution, permettant de créer des maquettes et des MVP à une vitesse jusqu'ici inégalée.[1]

L'ancienne méthode : le parcours du combattant vers le MVP

Souvenons-nous du processus traditionnel. Pour tester une nouvelle fonctionnalité ou une idée de produit, un PM devait généralement :

COMPLIQUE ou COMPLEXE ?

Vous entendez souvent les termes "compliqué" et "complexe" utilisés de manière interchangeable ? 🤔
Si la nuance peut paraître subtile, elle est en réalité fondamentale pour aborder les défis professionnels.  cette distinction, au cœur du modèle Cynefin, n'a que peu à voir avec la "complexité" au sens mathématique.

Démystifions ensemble ces concepts pour une prise de décision plus éclairée !

Le Cadre Cynefin : Une affaire de prévisibilité

Développé par Dave Snowden, le modèle Cynefin est un outil d'aide à la décision qui distingue cinq contextes différents.[1][2][3] Penchons-nous sur deux d'entre eux :

"Le risque, c’est de ne pas les suivre" - retour d’expérience sur une pratique sous-estimée

    Depuis plusieurs années, je m'assure systématiquement d'intégrer le suivi des risques dans la gestion des trains Agile que j'accompagne. Ce n’est pas simplement un "bon réflexe" ou une "pratique recommandée" au bon moment - c’est un reflexe "mandatory", établi dès le PI Planning, suivi toutes les semaines, et intégré dans les rituels de gouvernance.

Ce qui est suivi de manière sérieuse, c’est ce qui est piloté. Et ce qui est bien piloté, c’est ce qui est livré de façon optimale. (Mantra d'un RTE Senior)

Le cadre : SAFe, Scrum et un peu de rigueur

Que l’on aborde Scrum ou SAFe, la gestion des risques ne doit jamais être considérée comme secondaire. Dans Scrum, il incombe au Scrum Master de mettre en lumière les obstacles, de les remonter et de les gérer. En SAFe, le cadre structure cette tâche à l'aide du tableau ROAM, qui est introduit dès le PI Planning pour établir une vision partagée des incertitudes au niveau du train.

Non, l’agilité n’est pas morte. Elle est simplement devenue adulte.

    Depuis quelques mois, de nombreux articles annoncent la “mort de l’agilité”. Pour certains coachs freelance, la baisse d’activité semble confirmer cette thèse. 

    J'aimerais vous partager mes observations et constats, après 25 ans à piloter des projets complexes dans plus de 30 grandes DSI (Renault, France Travail, Société Générale, Orange, Axa, BPCE, Tissot, Eaton, Dior, L'Oreal, Lacoste, EDF, General Electrics, RATP,…), je l’affirme : l’agilité n’est pas morte, elle est devenue mature.

    Dans mon experience en passant progressivement des roles - de développeur, chef de projet, architecte, directeur de projet (sur des projets de plusieurs années avec plus de 50personnes), manager de transition, coach agile/transformateur - j'ai pu voir un grand nombre de pratiques arriver, s'installer à travers des buzz-word, devenir virales et tirer tout le marché vers le haut, puis atteindre leur maturité et rentrer dans les moeurs, laissant place à d'autres nouvelles technos ou pratiques. J'ai appris avec le temps à lire ces cycles et à me positionner sur les nouvelles vagues montantes. Je vous partage ci dessous ces observations et recommandations.

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.

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.