Idée principale

Quand l'obligation de corriger tout de suite s'applique, l'équipe ralentit, parfois beaucoup. La conclusion immédiate est que la règle est trop dure.

La cause est ailleurs : le système de production fabrique trop de défauts, ou les détecte trop tard. La file de défauts jouait le rôle d'amortisseur — elle étalait ce taux dans le temps et le rendait illisible. La règle retire l'amortisseur ; le taux devient une contrainte quotidienne.

La réponse porte donc sur la production : tests, QA, TDD, automatisation, clarification des spécifications, responsabilité des développeurs sur ce qu'ils livrent. Pas sur le rétablissement de l'amortisseur.

Pourquoi c'est important

La douleur créée par la règle est un instrument de mesure, et c'est son intérêt principal. La lire comme un échec conduit à réinstaller la file, c'est-à-dire à remasquer ce qu'on vient de découvrir.

Nuances et limites

La règle ne dit rien du délai admissible de correction, ni de ce qu'une équipe peut absorber. Une équipe qui découvre un taux ingérable a besoin d'une transition, pas d'une application immédiate.

Questions ouvertes

• Combien de temps une équipe peut-elle tenir un taux de défauts que son système ne sait pas encore réduire ?