Je vois souvent la même chose dans les organisations que j’accompagne.
Elles veulent devenir agiles à l’échelle. Elles entendent parler de SAFe®, elles regardent le Big Picture, et elles se disent :
“On va tout mettre en place.”
Le rôle de Scrum Master est souvent réduit à l’animation des cérémonies.
Mais en réalité, ce qui fait la différence dans une mission, ce sont les postures : la capacité à écouter, cadrer, recadrer, accompagner sans diriger, créer les conditions de la confiance, et faire émerger l’autonomie.
Fort de mes expériences sur le terrain, j’ai souhaité lancer cette série d’articles dédiée aux soft skills clés du Scrum Master : les dilemmes de posture, les petits ajustements du quotidien qui permettent aux équipes de grandir, et pas simplement d’“appliquer Scrum” ou l’Agilité à la lettre.
J’ai récemment assisté à une conférence sur notre rapport au temps. J’y ai réalisé à quel point nous sommes devenus prisonniers de Chronos, obsédés par le temps mesuré, au détriment de Kairos (le moment opportun) et Aion (le temps cyclique et évolutif).
Cette réflexion m’a inspiré cet article : comment l’Agilité peut-elle nous aider à réconcilier ces trois dimensions du temps, pour le bien des entreprises et des individus ?
L’Agilité est devenue une méthode de gestion de projet incontournable pour les entreprises cherchant à améliorer leur capacité d’adaptation et à maximiser la valeur pour le client. Cependant, alors que l’Agilité repose sur la flexibilité, la collaboration et le développement incrémental, le financement des projets reste souvent structuré autour des centres de coûts. Ce modèle n’est plus adapté dans un contexte Agile dans lequel les besoins évoluent rapidement, et les entreprises doivent être capables de réorienter leurs efforts en fonction des priorités changeantes du marché.
Introduction
Dans le framework SAFe les Features [1] sont conçues pour maximiser la valeur ajoutée. Lors de mes différentes interventions, j’ai observé certaines pratiques ou anti-patterns qui conduisent à des dérives, compromettant ainsi l’efficacité et la pertinence du développement produit.
Dans cet article j’aborde quelques-uns des anti-patterns rencontrés dans la gestion des Features et propose des solutions pour les aborder. Pour illustrer chaque point, j'utilise des exemples d’une application de téléconsultation médicale.
Dans un train SAFe, le suivi et l’optimisation du flux de travail sont cruciaux pour assurer la livraison continue de valeur. De nombreuses équipes se retrouvent noyées dans les métriques sans bien comprendre comment les utiliser pour des améliorations concrètes.
Les flow metrics de SAFe sont des indicateurs clés pour mieux gérer le flux de travail et identifier les zones d’amélioration, mais leur mise en place peut être complexe sans une approche structurée.
Ce guide présente chaque flow metric avec un exemple concret et des conseils pour les utiliser efficacement.
Une transformation agile peut perdre de l’élan. Voici quelques signes d’alerte que j’observe souvent dans mes interventions, et comment les adresser pour garder le cap !
Symptôme : Les dirigeants participent peu aux cérémonies agiles ou sont absents des rétrospectives stratégiques.
💡Solution : Encourager les leaders à s’engager activement. Organiser des sessions de formation et de sensibilisation sur l'importance de leur rôle dans l’adoption agile. Une culture de soutien commence par le haut.
Le PI Board, au cœur de la planification et de la coordination dans un Agile Release Train (ART), est un outil essentiel pour visualiser l’état d’avancement d’un Program Increment (PI). Voici à quoi ressemble un PI Board bien géré à la fin d’un PI et quelques conseils pratiques pour maximiser son utilité.
C’est avec grand plaisir que j’ai eu l’opportunité d’organiser et d’animer, en tant que Release Train Engineer (RTE) et Coach Agile, la toute première session Inspect & Adapt (I&A) de l'Agile Release Train (ART) "La Ruche" de la Banque des Territoires. Cet événement marque une étape clé dans le cycle de vie du premier Program Increment (PI) de cet ART et reflète l’engagement des équipes à s’améliorer en continu.
Dans cet article, je vous propose un retour sur cet événement marquant, ses objectifs, ses temps forts et les enseignements à retenir.
Après le succès du premier train expérimental, la Banque des Territoires a franchi une nouvelle étape dans son adoption des pratiques Agile à l’échelle. Le lancement d’un deuxième Train Agile, plus ambitieux et structuré, reflète la maturité croissante de l’organisation dans son déploiement du Scaled Agile Framework (SAFe).
Dans cet article, je vous partage les moments marquants de ce lancement, notamment l’organisation du PI Planning, ainsi que les enseignements clés pour réussir de telles initiatives.
Les 25 et 26 juillet 2019, j'ai eu le plaisir d'animer une formation SAFe for Teams pour 25 participants motivés chez Air France-KLM. Pendant ces deux jours, nous avons exploré ensemble les concepts clés de SAFe (Scaled Agile Framework) et travaillé sur la manière dont les équipes Agile peuvent s'aligner efficacement au sein d'un Agile Release Train (ART).
Voici un retour sur cette formation riche en apprentissages et en collaboration.
Dans le secteur bancaire, la collaboration entre les équipes IT et Métier est devenue une réalité stratégique. Ce travail conjoint permet de briser les silos, d’aligner les priorités et de maximiser la valeur livrée. Chez BNP Paribas, cette démarche a pris vie lors des ateliers de co-construction de la roadmap 2019 pour la digitalisation de l’offre de crédit immobilier.
Dans cet article, nous partageons les moments forts de cette collaboration et les enseignements clés pour réussir de telles initiatives.
Lors de la 8ème Foire Agile ITIM CAI de la Société Générale, j’ai eu l’opportunité d’animer un atelier intitulé "Mon Pire Cauchemar". Cet exercice ludique et collaboratif vise à améliorer une situation, un produit, un service ou encore la dynamique d’une équipe en identifiant les scénarios les plus négatifs (les cauchemars) et en élaborant des stratégies pour les prévenir ou les gérer.
Le Marshmallow Challenge est un exercice à la fois ludique et pédagogique, idéal pour introduire des concepts Agiles et favoriser la collaboration au sein des équipes. Lors de la foire Centre Agile ITIM organisée par la Société Générale le 29 janvier 2018, j'ai eu l'opportunité d'animer cet atelier. Retour sur une expérience amusante, riche en apprentissages et... légèrement gourmande !
Metrics and measurement are important in software development projects. They are needed for planning, budgeting, organizing and controlling the work. They are also necessary for continuous improvement.
Scrum provides three main metrics: Velocity, Sprint Burn down and Release Burn up. These metrics focus mainly on the development team and on the product. They don’t directly address the cost of the project.
In this article I present SPOC (Story POint Cost) as a metric to measure and track the cost of user stories and consequently the cost of Agile projects. I have developed the SPOC metric during my different interventions as an Agile/Scrum consultant. The metric has been used in several projects during the last three years. The main objectives of the SPOC metric are the following:
Provide the Scrum teams (and managers) with a simple means for measuring and tracking the development cost all along the project.
Having a concrete measure of story point cost will reinforce team awareness about the budget. This allows the team to register cost reduction among its objectives of continuous improvement.
Keeping a history of the costs will allow more accurate budget estimates for future projects (Estimation based on teams experience).
Dans Scrum chaque Sprint crée un incrément qui est un produit partiel potentiellement livrable à la production.
Pour qu’il puisse être déployé en production, l’incrément doit répondre à tous les critères d’acceptation et subir toutes les vérifications nécessaires.
Chaque Sprint doit donc inclure toutes les activités de tests permettant d’obtenir un incrément exploitable que l’on peut livrer à la production.
Ce post introduit l'acronyme PURIFF comme concept pour regrouper l’ensemble des activités de tests à mener durant le Sprint. Chaque élément de l'acronyme correspond à une catégorie de tests :
P : pour les tests de Performances
U : représente les tests Unitaires
R : désigne les tests de non Régression
I : couvre les tests d’Intégration
F : pour les tests Fonctionnels
F : représente les tests (Non) Fonctionnels