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