Amélioration continue Vs. rétrospective agile : éloge d’une approche concrète

Dans le billet précédent, je propose un cas réel avec la journée d’une équipe agile qui :

1. le matin rencontre un problème de production, le type de problème opérationnel le plus important que peut rencontrer une équipe de développement informatique,
2. et fait l’après-midi sa rétrospective (session de travail liée à l’amélioration continue), sans évoquer l’incident du matin ni les conditions de réussite du sprint.

L’idée était de montrer avec cet article que l’approche inclusive de l’agile (“tout ce qui est nouveau et créatif est sympa, essayons-le” – ce que Nassim Nicholas Taleb appelle la neomania) peut conduire à des dérives qui mènent les équipes aux antipodes des principes de l’agilité.

Ce second article propose aussi un retour de cas sur une équipe qui mène une session d’amélioration avec l’approche concrète et factuelle de l’agile, héritée du lean. Cette session sera probablement jugée comme étant moins “créative” et plus prosaïque. Mais elle apporte des résultats, voyons plutôt …

Le contexte

Nous sommes dans une ESN avec une équipe qui fait de la maintenance évolutive pour un gros client institutionnel. Ce client propose un processus lourd de livraison de logiciel et il se plaint que les bons de livraison délivrés par l’équipe sont très souvent incorrects. Il s’agit d’une grande source de frustration pour ce client car cela lui fait perdre beaucoup de temps et crée de la confusion au niveau des équipes clients et système.

Le problème

Un travail préparatoire montre que :

• “très souvent” représente 21 bons KO sur les 45 des deux derniers mois. Soit 25/45 ou 53% OK. Génial ! On a un écart car le client veut 95% OK. On a donc un problème, un vrai.
• le processus est en effet très lourd. Une observation avec Philippe un des développeurs seniors montre que cela prend 48 minutes, 10 étapes et l’utilisation de 8 outils différents (pour une livraison qui sera KO …). Accessoirement, passer ce temps d’observation me permettra de mener un atelier avec la bienveillance et la crédibilité nécessaires.

Les causes

Nous organisons un atelier d’amélioration dans lequel nous allons étudier les 21 bons KO et essayer de comprendre leurs causes. En faisant ce travail on réalise que l’on a la distribution de causes d’erreur suivante :

• 6 bons sont KO car le mauvais environnement de développement y est spécifié (pre-prod au lieu de recette, intégration au lieu de pre-prod etc …)
• 6 sont liés à des corrections d’anomalies : le processus n’est pas convenablement suivi (une étape exécutée avant une autre ce qui rend le bon incohérent avec des champs qui n’ont pu être remplis)
• la description est incorrecte pour 5 d’entre eux. Comme il y a de nombreux outils, le titre doit être reporté dans plusieurs d’entre eux. Et parfois le titre est différent entre deux outils et donc reporté comme différent dans le bon
• pour 5 tickets, le numéro d’évolution ou le code de l’application modifiée est incorrect
• le numéro de ticket est incorrect pour 4 d’entre eux
• etc …

L’épiphanie

Mais la chose la plus intéressante se passe ensuite : je demande “Pourquoi avons-nous ces problèmes de numéro de ticket, de nom d’environnement ou d’intitulé ?” Pour comprendre cela, nous parcourons le standard de réalisation des Bon de Livraisons pour voir ce qui a bien pu se passer dans la réalisation des bons KO en cours d’analyse. En confrontant le standard existant et les pièces KO, Philippe réalise que le standard invite à copier le bon de livraison précédent pour en créer un nouveau et que les erreurs constatées dans ces tickets sont des scories des tickets précédents que l’on a dupliqués.

C’est un moment précieux, que nous cherchons sans cesse : cette épiphanie durant laquelle la personne voit sa fausse croyance à l’oeuvre. En l’occurrence que recopier un bon existant pour en faire un nouveau nous fait gagner du temps. Car cette pratique est une des causes principales (22/30) des problèmes de non-qualité qu’ils analysent ensemble durant cet atelier.

Actions

Philippe et l’ensemble de l’équipe décident alors de modifier le standard pour proscrire la recopie de bon existant et plutôt inviter la personne à utiliser le template vide. Ils précisent aussi deux trois autres choses dans le wiki du standard pour apporter des précisions et prévenir d’autres cas tels que ceux que nous avons vus.

Résultats

Un mois plus tard, il n’y a qu’un seul bon de livraison KO sur les 14 livrés : nous sommes à 93% de OK. Ce ne pourrait pas être une pochette d’album de rock progressif des années 70 (comme dans la rétrospective de notre équipe agile) mais cette illustration fait un bien fou à l’équipe et au client :

Enseignements

Alors bien sûr, dans cet atelier d’amélioration il n’y a pas d’imagerie à la symbolique poétique, pas d’espace dans lequel chacun peut broder inlassablement sur son état psychologique dans le projet.

Et cette résolution de problème ne va pas changer la face du monde. Elle va juste traiter un problème important pour le client et donner de la fierté aux équipes alors qu’elle apprend à voir l’obstacle mental (la fausse croyance) qui l’empêchait de réussir sur ce sujet. Ce faisant, l’équipe a développé la compétence la plus importante pour les organisations du XXIème siècle selon le World Economic Forum : la résolution de problème complexe. Ce n’est déjà pas si mal.

o o o

Cet article a été publié dans Culture Kaizen – La transformation des petits matin, livre blanc d’OCTO Technology.