RESOUDRE LES PROBLEMES

C'est bien bien sympa de voir les problèmes. Ceci dit, l'objectif reste de les résoudre!

Alors, ces problèmes identifiés et exposés à la vue de tous, sont-ils traités?

1. PETIT RAPPEL

Rappelez-vous: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit résoudre systématiquement les problèmes qu'elle rencontre.
Alors,

• on développe la détection systématique des problèmes;
• on affiche les problèmes pour les rendre visibles;
• on résout les problèmes de manière structurée.

Cette attitude et cette démarche sont décrit dans un précédant billet.

2. EST-CE PRATIQUÉ?

Afin de s'assurer que ces beaux principes sont devenus des pratiques, nous affichons un indicateur révélant le nombre de problèmes résolus (le bas des barres) et le nombre de problèmes non-résolus (le haut des barres). Cet indicateur est actualisé à chaque itération (voir photo ci-dessus).

3. EST-CE EFFICACE?

C'est bien joli de mettre en place de nouvelles pratiques - encore faut-il qu'il y ait un retour sur investissement ... Et là, il faut reconnaître qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.

Difficile n'est pas impossible: les burndown-chart et la courbe de non-qualité révèlent les gains en productivité et en qualité de cette démarche.
Notamment, la courbe de non-qualité révèle de sévères réductions de la non-qualité correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.
Puisque le burndown-chart ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.

4. EFFET SECONDAIRE

Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la standardisation.
En effet, la résolution d'un problème résulte généralement en:

• une contre mesure automatisée (scriptée dans le build, dans le commit, ...);
• une contre mesure manuelle décrite par une petite procédure textuelle;
• l'amélioration d'une procédure existante.

Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de petites procédures pragmatiques. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.

Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.