Lorsque j’ai découvert le Lean, de nombreux éléments m’ont clairement fait toucher du doigt ce que l’on appelle la dissonance cognitive. L’un d’entre eux concerne l’amélioration continue. J’étais très à l’aise avec mes rétrospectives à chaque fin de sprint, et sans aucun scrupule, j’appelais d’ailleurs cela de “l’Amélioration Continue”. Mais c’est bel et bien le Lean qui m’a appris ce que ce terme voulait vraiment dire.

Dans ce billet, je me propose de vous faire un retour d’expérience afin d’expliquer pourquoi, après avoir lutté corps et âme pour que les équipes fassent des rétrospectives, je lutte maintenant pour qu’elles s’en passent… ou du moins qu’elles distinguent ces réunions de l’amélioration continue apportée par le Lean.

C’est l’heure de la Rétrospective

Ce point régulier (chaque sprint pour les équipes Scrum) a tout d’un point réel d’amélioration. Sa structuration permet de se rappeler les événements passés sur la période, de générer des idées d’amélioration et de mettre en place un plan d’action pour les réaliser. Cependant, il y a des éléments qui me dérangent. Au-delà des dérives psychologisantes que dénonce Cecil Dijoux, un des points qui me chiffonne et que je rencontre régulièrement, est la définition de ce qu’est un problème. En effet, quand on entend une équipe parler de ses problèmes, on entend « difficulté de communication », « mauvaise vision », « on n’est pas assez nombreux » (mon préféré). On remarque d’ailleurs fréquemment une réelle confusion entre cause et problème (le « manque de communication » est un problème ou une cause ?).

L’expérience que je vais partager concerne une équipe ayant un goulot d’étranglement assez conséquent dans son flux. L’une des colonnes de leur board débordait d’ailleurs littéralement de post’it (qui finissaient collés sur le mur). Cette colonne était celle de la “validation” par l’équipe de test. Point de vue flux, cela est un point important car chaque ticket est une valeur pour le client qui est bloquée et sur laquelle l’entreprise a déjà investi (l’étape de développements étant « terminée »). Cependant, lors de sa rétrospective, l’équipe n’a pas du tout parlé de ce sujet (comme si le fait de produire de la valeur pour le client n’était pas la priorité ??). A la place, les problèmes soulevés sont stratosphériques, ou hors de portée de l’équipe. Celle-ci mélange régulièrement les problèmes et les causes (“L’équipe XXX n’est pas assez disponible” ?).

Les actions qui suivent sont alors du même acabit, et donnent alors lieu à un fichier Excel répertoriant l’ensemble des actions d’amélioration de l’équipe dont la plupart ne sont pas terminée, et pour celles qui le sont, aucune mesure atteste de ce qu’elles ont apportées à l’équipe. Certaines sont même terminées car “elles sont trop vieilles”.

Je me suis alors hasardé à les interroger sur leur stock de ticket à l’étape de validation. La réponse est alors claire :

– “Bah, notre problème c’est qu’il nous manque des personnes sur ce poste”.

Le « problème » s’étant emmêlé à la « solution », analyser le problème source (qui est, pour rappel, la non livraison de valeur à notre client), ne leur semble pas nécessaire.

Quand le Lean s’en mêle

L’approche Lean est un peu différente. Elle oblige à regarder la vérité en face et comme le dit Régis Medina avec beaucoup de poésie : “Il nous enlève la merde des yeux !”.

J’ai proposé à cette même équipe une autre vision, celle du Lean. Nous nous sommes tous tourné vers le management visuel et nous avons commencé par regarder les indicateurs.

– “Atteignez-vous tous vos objectifs ?”

– “ Non, le burnup de business value est clairement dans le rouge !”

– “ Ha !! Il manque combien de point pour être bon ?”

– “ 35 !”

– “ Super, nous avons donc notre problème ! ”

Le Lean apporte une définition extrêmement claire de ce qu’est un « problème » (sujet déjà abordé ici). A l’annonce de ce chiffre (« 35 »), l’équipe comprend son véritable problème et s’aligne instantanément dessus. Ce n’est pas un problème de communication, de puissance de PC, de disponibilité d’une équipe… C’est mesuré, chiffré, concret, tangible et dans notre cas, c’est « 35 ». La définition du problème est alors claire et partagée par l’ensemble de l’équipe qui regarde dans la même direction, celle du client. Et tout ceci en quelques secondes, pas besoin d’un atelier dédié. (A ce stade, on a déjà l’œil gauche propre :p).

– “ Qu’est-ce qui fait que nous avons 35 points de retard ?”

– “ Ba les US sont terminées, mais elles restent bloquées dans la colonne de tests !” (J’aime beaucoup cette perception de « Terminé »).

– “ Du coup, sont-elles vraiment terminées au sens de votre DOD ?”

– “ Ba du coup non”

– “ Pourquoi sont-elles bloquées ?”

– “ Parce que l’équipe de test n’est pas assez dimensionnée !”

– “ Est-ce qu’on peut tout de même regarder ?”

– “ Si tu veux !”

S’en est suivi une investigation sérieuse qui a montré que sur 32 tickets en stock à cette étape, 29 étaient bloqués selon les causes suivantes : 

J’ai alors posé la question à la personne en charge des tests :

– “ S’il n’y avait pas ces problèmes, ces 29 tickets seraient terminés ?”

– “ oui !”

– “ Quel est la somme des business value de ces 29 tickets ? ”

– “ 43 ! ”

Et je suis fier d’avoir assisté à ce moment précis où l’équipe a ressenti ce « Whahou !! ». L’équipe s’est rendu compte que ses problèmes n’étaient pas là où ils pensaient au départ. L’œil droit est maintenant propre, l’équipe a ouvert les yeux et en quelques minutes elle s’est alignée sur le problème et ses causes. En prenant le temps de définir ce qu’est le problème et d’analyser ses causes racines, on s’est abstrait de toute opinion pour se pencher sur des données tangibles.

« Sans données, vous êtes juste quelqu’un avec une opinion »
William Edwards Deming

Peut-être que l’équipe en charge des tests n’est pas assez dimensionnée, qu’ils ont des difficultés à communiquer ou une vision incomplète. Je ne suis pas là pour démonter ces arguments. Ce que j’ai fait, c’est regarder et questionner l’équipe sur leur véritable problème qui était le retard de livraison au client. En faisant cela, l’équipe a trouvé des contre-mesures à expérimenter et vous savez quoi ? Le stock est, à l’heure ou j’écris ces lignes, de 5 tickets et l’équipe a redressé son burnup.

Ce retour d’expérience n’est pas isolé dans la sphère du Lean. Jean-Philippe Douet (coach Lean et Agile) l’exprime très bien dans son article Et si on ajoutait du Lean dans la rétro de sprint. Cecil Dijoux (mon sensei) dont j’ai souvent parlé dans ce blog aborde également ce sujet dans Les dérives psychologisantes de l’Agile : étude de cas.

« In God we trust, all others must bring data »
William Edwards Deming