Aujourd’hui, je vous propose de partager une histoire de coach dans laquelle s’est parfaitement illustrée une phrase qui revient souvent dans mes articles :

Être doux avec les personnes et dur avec les situations

Quand on accompagne une équipe en Lean Management, on essaye d’avoir une vision la plus claire possible de la situation au travers différents prismes :

• La satisfaction du client
• Les délais
• La productivité
• La qualité

Et pour communiquer et partager cette vision, nous utilisons la mesure (les KPI). Ces indicateurs nous permettent non seulement de donner le challenge aux équipes (leurs conditions de réussite), mais nous apportent également une vision très claire sur la situation dans laquelle on évolue. Mon histoire de coach se passe lors du coaching classique d’une équipe avec laquelle nous avions justement mis en place des mesures permettant de visualiser sa situation par le prisme de la qualité. Un des indicateurs m’indique un problème lors d’une revue.

Cette équipe était divisée en deux : les experts, et les novices. Et pour faciliter le tout, experts et novices étaient distants physiquement. Les experts avaient pris pour habitude de revoir le code proposé par l’équipe novice. Chaque retour était comptabilisé afin de 1/ identifier les éléments d’amélioration du côté de l’équipe novice et 2/ mesurer de manière tangible la progression de cette dernière dans le temps. Cette notion de qualité à chaque étape est une notion clé du Lean qui vise à former chaque personne à :

• Ne pas recevoir de non-qualité de l’étape précédente
• Ne pas créer de non-qualité à son étape
• Ne pas transmettre de non-qualité à l’étape suivante

Grâce à cet indicateur, nous avons vu que de la non-qualité avait été créée quelque part dans le processus. SUPER !! L’équipe avait quelque chose à apprendre sur ses pratiques.

Voyant cela, j’ai décidé d’aller voir Matthieu*, l’expert qui a remonté ce problème dans le code de Romain* (le « novice »). Matthieu* m’explique le problème rencontré : « Dans le code source, il y avait une condition « if » inclue dans un bloc qui contenait déjà cette condition. »

En gros pour faire simple, le code était comme ceci :

if (a == b) {

  …

  if (a == b) {

    …

  }

  …

}

Matthieu* me précise alors : « La raison est simple, Romain n’a pas le niveau !! »

Ok ok Matthieu, c’est ton point de vue, mais je vais tout de même aller voir Romain*. Être doux avec les personnes et dur avec les situations signifie qu’à ce moment-là, je suis persuadé que Romain* a fait du mieux qu’il pouvait, et que c’est la situation dans laquelle il évoluait qui l’a poussé à faire cette erreur.

Une fois avec Romain*, voici notre échange :

Moi : « Romain, peut-on discuter du ticket RB-521 et du retour de revue de code KO ? »

Romain : « Bien sûr ! »

Moi : « Tu peux me dire ce qui s’est passé ? »

Romain : « J’ai fait une erreur de débutant, c’est une étourderie stupide… »

Ce moment est assez perturbant pour moi. Romain* avait été convaincu lui-même que c’était lui le « coupable ». Il se blâmait lui-même. Mais convaincu de mon adage, je continue la discussion :

Moi : « Peux-tu me montrer le code ? »

Romain : « Oui regarde ! »

« Montre-moi ». Plutôt que partir sur des hypothèses et des opinions qui ne reposent sur rien, montre-moi, donne-moi des données, des informations qui nous permettront de mieux comprendre la situation. Ce moment-là est déjà magique car le premier « if » dont on parle ne faisait pas moins de 800 lignes… Bien avisé celui qui pourrait le voir ! Mais pas grave, je continue la discussion :

Moi : « Du coup, ce « if » est déjà en haut c’est ça ? »

Romain : « oui »

Moi : « Pourquoi est-ce que tu ne l’as pas vu ? »

Romain : « Bah, je n’ai pas vérif… HAAAA attends, je me souviens! En fait, j’ai eu un retour sur ce dev, et du coup j’ai fait un copier / coller du code d’une autre fichier vers celui-là. »

Moi : « Ha ok. Et te souviens-tu pourquoi tu as eu ce retour qui a nécessité ce déplacement du code ? »

Romain : « Oui, c’était un retour de l’équipe Finance. Que j’ai corrigé en déplaçant le code. »

Moi : « L’équipe Finance ? Pourquoi c’est elle qui t’a remonté ce retour ? »

Romain : « Parce que c’était un développement pour elle. »

Moi : « Ha ok, et comment ça se fait que tu n’aies pas détecté ce bug toi-même avant de livrer le dev ? »

Romain : « Parce que je ne savais pas comment tester, vu que c’était sur le produit Finance. »

Moi : « Et si on t’avait montré, tu aurais pu le faire ? »

Romain : « Bien sûr. »

Moi : « Comment aurait-t-on pu te montrer ? »

Romain : « Il aurait fallu qu’une personne de l’équipe Finance vienne me montrer… Lors de notre réunion où on planifie les points que l’on va traiter par exemple. »

Romain* a alors proposé cela à l’équipe qui a accepté. Dorénavant, lorsque l’équipe doit planifier des développements concernant une autre équipe, un membre de cette dernière sera invité pour donner les conditions de réussite du développement (i.e. les tests permettant de valider le développement). Ce type de développement (concernant une autre équipe) étant fréquent, l’équipe a donc amélioré son processus grâce à Romain* (le « novice incompétent »).

L’équipe a donc appris :

• comment ne pas recevoir de non-qualité en demandant la manière de valider les développements à l’équipe destinatrice
• comment ne pas transmettre de non-qualité en mettant la personne en situation de savoir si son développement est ok en testant comme l’a défini l’équipe Finance.

Et c’est grâce à ce type de pratique que l’équipe, petit pas par petit pas, a multiplié par deux sa qualité (i.e. divisé par deux ses retours).

Ce qui a eu pour effet (entre autres) de multiplier à 2,5 le nombre de tickets livrés par l’équipe.

Aller à la source est un réflexe à maitriser quand on cherche l’amélioration. Mais cette pratique ne peut pas fonctionner sans l’élément fondamentale du Lean : le respect des personnes. Seul le fait de regarder la situation en face peut faire progresser l’équipe. En partant du fait que la personne n’est pas compétente, on s’arrête à une opinion souvent fausse avant même d’avoir cherché d’éventuelles causes factuelles. Cela a l’avantage d’être rapide, à un inconvénient près : celui de ne pas être actionnable et donc de ne pas pouvoir mener à une amélioration tangible.

En cherchant le pourquoi de la situation jusqu’à trouver la cause racine, on trouve des éléments structurants qui mènent à de réelles améliorations.

* Les noms ont été modifiés pour des raisons d’anonymat.

Cet article a inspiré un chapitre de Culture Kaizen – La transformation des petits matin, livre blanc d’OCTO Technology.