02. Le travail en cours est l'ennemi de la livraison

Être occupé c'est pas livrer

Chez JPSoftWorks, on rencontre souvent des équipes surchargées… mais curieusement bloquées.

Des tableaux de travail pleins à craquer.
Des sprints saturés.
Des gens qui jonglent avec tout en même temps.

Et pourtant, la livraison souffre. Elle est d'arrache.

Le problème c'est pas l'effort. C'est le travail en cours: le WIP (Work in progress). Trop de WIP ralentit tout, masque les risques et empêche l'apprentissage. Attendez, je vous explique.

Le "flux" avant l'occupation

Dans un système, le flux est plus important que l'occupation maximale. Imaginez un peu de la plomberie. L'importance n'est pas combien d'eau tient dans le système, mais combien d'elle aboutit à sa destination!

Le WIP, c'est de l'inventaire. Et l'inventaire cache les problèmes.

Plus il y a de travail en cours:

• Plus chaque item prend du temps
• Plus les goulots sont invisibles
• Plus le multitâche explose
• Moins la livraison est prévisible

The Phoenix Project (bouquin de référence) l'explique très bien: tout le monde travaille fort, mais le système bloque.

Le travail invisible fausse tout

Les tickets visibles ne racontent jamais toute l'histoire.

Le travail invisible inclut:

• Les interruptions constantes
• Les correctifs manuels
• Les dépendances humaines
• Les revues tardives
• Les reprises inutiles
• Tous les items non planifiés ou non documentés

Ce travail consomme de la capacité sans être planifié. Résultat: on surengage et on ouvre encore plus de travail.

Quand le travail contourne le tableau

Un anti‑pattern très courant: le superhéros.

Compétent.
Rapide.
Bien intentionné.

Mais aucun ticket. Aucune carte. Aucune trace.

Conséquences:

• Le PO ne peut pas valider l'intention
• Les risques sont invisibles
• L'acceptation devient subjective
• La confiance devient un enjeu

Le travail devient une boîte noire. Et une boîte noire, ça ne se gouverne pas.

Les items sont des contrats d'alignement

Chez JPSoftWorks, un ticket n'est pas de la bureaucratie. C'est un contrat léger d'alignement.

Il clarifie:

• Pourquoi on fait le travail
• À quoi ressemble la définition de "terminé" (DOD)
• Qui doit accepter
• Quel risque est assumé (et non présumé)

Contourner cette étape, c'est exclure: souvent sans le vouloir: les parties prenantes. Et c'est un risque important.

Taille ou nombre: choisir consciemment

Il n'y a que deux leviers, seulement, pour gagner à ce jeu:

• Réduire le nombre d'items
• Réduire leur taille

Les "gros tickets" rassurent au début et explosent plus tard. Les petits items forcent la clarté.

Si un ticket ne bouge pas en un jour ou deux, il est mal découpé. Point.

Gouvernance et sécurité

Beaucoup de WIP signifie:

• Risques prolongés
• Décisions tardives
• Sécurité appliquée trop tard
• Surprises coûteuses

Un bon flux rend la gouvernance et la sécurité naturels, intégrés et calmes.

L'automatisation rend l'amélioration visible

Quand le travail aune cadence régulière:

• Le temps de cycle diminue
• La variabilité baisse
• La valeur devient mesurable

C'est ainsi que DevOps démontre son impact réel. Cela va de soi.

Anti‑patterns clairs

Si quelqu'un livre régulièrement sans tickets, le système n'est pas rapide: il est aveugle.

Mot de la fin

DevOps ne meurt pas par manque d'effort, mais par excès de travail inachevé.

Si le travail est visible et limité, il circule.
S'il circule, il enseigne.
S'il enseigne, il s'améliore.

Si vos tableaux débordent mais que rien ne se ferme, parlons‑en.

Références