Des livraisons enfin prévisibles : le temps de cycle divisé par deux chez Floa Bank

Contexte

Floa Bank (groupe BNP Paribas) construit des produits de paiement et de crédit avec plusieurs équipes IT en SAFe. Sur mon périmètre (3 équipes, 20 personnes), un sujet mettait en moyenne 28,5 jours à être terminé (statut Done), et c'était surtout imprévisible : difficile de dire quand un sujet serait prêt. Les mises en production étaient groupées en fin de PI, coordonnées avec les autres équipes. La difficulté de fond : ici, une équipe ne porte pas un produit de bout en bout, mais une étape d'un produit. Tout dépend donc des autres.

Le problème

28,5 jours pour terminer un sujet, c'est l'effet cumulé de PI Planning surchargés, de dépendances inter-équipes découvertes trop tard et d'un périmètre qu'on n'arrivait pas à tenir. Le symptôme le plus parlant : mon équipe était celle qui ne remplissait pas ses objectifs.

Temps de cycle (jours pour terminer un sujet)

Ce que j'ai mis en place

Mon angle n'a pas été d'aller plus vite à tout prix, mais de rendre la livraison pilotable et prévisible. Quatre leviers :

• Un modèle de capacité d'équipe

  60 % features, 30 % bugs, 10 % imprévu, bâti sur la donnée des PI passés. Il sert à cadrer le périmètre P0 sur ce que l'équipe peut vraiment tenir, et à dire « non » au métier avec des arguments.

• WIP et dépendances

  Limitation du travail en cours et cartographie des dépendances inter-équipes, traitées au plus tôt. Vital quand chaque équipe n'est qu'une étape du produit.

• Reporting outillé et PMO de proximité

  Un reporting de release dans Jira, décliné par epic, feature et story. J'absorbe le reporting hebdo et mensuel pour que l'équipe reste concentrée sur la livraison.

• Faire constater la réalité

  Quand un PI a vu son périmètre doubler en cours de route, j'ai reconstruit l'historique dans Jira pour le démontrer au métier et crédibiliser le « on s'en tient à notre capacité ».

Compétences mobilisées