Comment j'ai divisé un temps de cycle par deux

Sur une de mes missions, le délai moyen entre la prise en compte d’un besoin et son achèvement était de 28,5 jours. Achèvement au sens développement : développé, testé, prêt à partir en production (la mise en production elle-même suivait son propre processus, groupée et coordonnée avec les autres équipes). Trop long, et surtout imprévisible. Quelques mois plus tard : 14,7 jours. Voici comment, sans recette magique.

1. Cartographier le flux avant de toucher quoi que ce soit

On a posé sur un mur chaque étape entre “un besoin arrive” et “c’est terminé, prêt à livrer”. Pas les étapes théoriques du process, mais les vraies, avec les temps d’attente entre chacune. Surprise classique : l’essentiel du délai n’est pas dans le travail, mais dans l’attente entre les étapes.

2. Remonter aux causes racines

Avec un diagramme d’Ishikawa, on a listé tout ce qui ralentissait : dépendances mal anticipées, incidents sur le système historique qui mangeaient la capacité, Go/No-Go décidés au cas par cas. On a classé par impact, pas par facilité.

3. Attaquer les 3 leviers les plus impactants

• Anticiper les dépendances en amont des comités de planification, plutôt que les découvrir en cours de route.
• Traiter les incidents legacy de façon proactive pour libérer de la capacité.
• Formaliser le release management : périmètre, Go/No-Go, reporting. Fini le cas par cas.

Ce que je retiens

Le gain n’est pas venu d’un outil ou d’une cérémonie en plus. Il est venu de rendre le flux visible, de mesurer, et de concentrer l’énergie sur les 2-3 causes qui pesaient vraiment. Le reste, c’est de la discipline.

Vous vivez le même problème ? Écrivez-moi, j’aime ces sujets.