(Article publié initialement en anglais sur InfoQ.com)

On peut définir le Lean de plusieurs façons mais la définition la plus motivante est celle proposée par le fondateur du Lean Enterprise Institute : John Shooke dans son livre Managing to Learn : « Le Lean management consiste à développer des produits en développant les employés ». Il y explique que le Lean consiste à développer les gens par la résolution de problème : travailler de façon à rendre les problèmes (et les opportunités d’apprentissage) visibles en utilisant une approche scientifique pour les résoudre, au fur et à mesure qu’ils apparaissent.

Quand je travaillais avec des équipes agiles de développement logiciel, je confondais bugs et  problèmes : je pensais que le process Agile était Lean car il faisait émerger les bugs. Depuis, avec le recul, j’ai compris qu’une équipe agile qui produit des bugs n’a rien à voir avec un système Lean qui produit des opportunités d’apprentissage : c’était juste une équipe avec des problèmes de qualité comme j’en ai vu souvent.

Ma compréhension des bugs et des problèmes a évolué, le but de cet article est de vous donner des pistes pour mieux comprendre les problèmes qui causent des bugs afin d’améliorer la performance, en l’illustrant avec des exemples concrets. (note : je ne sous-entend en aucun cas que toutes les équipes agiles souffrent de ce même problème) …

Qu’est-ce qu’un bug?

En matière de développement logiciel, le terme de « bug » désigne beaucoup de choses : il peut s’agir d’une erreur système (NullPointerException, un code erreur 404 http, un écran bleu, …), un problème fonctionnel (si je clique sur B, le système devrait faire Z, or il fait Y), un problème de performance, de configuration, etc.

Un bug n’est pas un problème au sens “Lean” du terme tant qu’il n’est pas exprimé comme tel (cf paragraphe suivant). J’en ai vu (et même produit) un certain nombre et 95 % des bugs en question ne ressemblaient pas à des problèmes. A l’exception peut-être des bugs de performance.

Qu’est-ce qu’un problème ?

La définition standard dans le Toyota Way Field book, de Jeffrey Liker décrit les quatre points nécessaires à la définition d’un problème :

1- La performance actuelle

2- La performance souhaitée (standard ou objectif)

3- L’importance du problème telle que définie par la différence entre la perf actuelle et la perf cible

4- L’étendue et les caractéristiques du problème.

Comme l’explique Bené Brown dans son exposé sur la vulnérabilité  TED talk about vulnerability : « Ce que l’on ne sait pas mesurer n’existe pas ». Plus concrètement, si vous ne pouvez pas expliquer un problème par un écart de performance, c’est probablement que vous n’y avez pas réfléchi suffisamment.

Avant de commencer à travailler sur un problème, il faut impérativement l’exprimer clairement, prendre le temps de le comprendre (l’expert Lean Michael Ballé dit qu’il faut même « l’apprécier ») et résister à la tentation de proposer une solution. Comme l’expliquait Einstein : « Si j’avais 1 heure pour résoudre un problème, je passerais les 55 premières minutes à réfléchir au problème et 5 mn à réfléchir à la solution ». Personne ne prétend que c’est facile !

Dans un contexte de développement logiciel agile, les indicateurs de performance peuvent prendre la forme d’un diagramme (coûts et retards), nombre d’anomalies, temps de réponse (qualité), note du client sur les User Stories livrées (note sur 10 de satisfaction client) et le nombre de user stories (ou story points) livrées par sprint (productivité).

Avec ce type d’indicateurs, voici des exemples de problèmes :

. Qualité : la cible en termes de temps de réponse pour une page donnée est de 500 ms or nous avons mesuré 1500 ms avec 5000 utilisateurs en simultanée.

. Qualité : le nombre d’anomalies qu’il reste à la fin du sprint (2 au lieu de zéro).

. Coûts/ retard : nous tablions sur 3 jours pour finaliser cette user story, il nous en a fallu 8.

. Productivité : l’équipe a livré 5 user stories à la fin du sprint au lieu des 7 prévues

. Satisfaction client : Nous voulons une note de 8/10 pour chaque user story, or, nous en avons eu 2 en deçà lors du dernier sprint (respectivement 6,5 et 7).

Comment extraire des problèmes d’anomalies ?

Les anomalies ou bugs sont les symptômes de soucis d’ordre plus général et il est indispensable de comprendre la corrélation entre ces symptômes et les problèmes existants. On pourrait donc considérer que le travail des équipes qui font de l’amélioration continue au quotidien est de repérer et extraire les problèmes de la pile de bugs. Cela nécessite de faire une analyse et de transformer le matériau brut en opportunités d’apprentissage.

J’ai trouvé une manière de faire en classant les anomalies par famille pour comprendre le poids de chacune. La plupart du temps, un bug est la cause d’un problème existant ou est lui-même un problème. Par cette corrélation, on s’assure que l’on prend les problèmes dans le bon ordre, en commençant par celui qui a le plus gros impact sur la performance opérationnelle. Si vous ne savez toujours pas par quoi commencer, le lean nous dit de partir de la qualité !

Exemple 1 : dans un monde agile

J’étais manager d’une équipe de développement agile. Comme souvent, il ne s’agissait pas d’une équipe cross-fonctionnelle mais d’une équipe en silo faisant ses développements par itération, produisant le logiciel côté serveur pour des équipes d’application qui l’utilisaient dans d’autres itérations.

Grâce au Pareto sur les anomalies, nous avons identifié une famille représentant 20 % d’entre elles : ouverts par des équipes d’application et liés à la définition « implicite » de l’API côté serveur du logiciel. Quand les équipes métier ont utilisé ces services applicatifs, il se sont rendus compte qu’il il manquait des paramètres en entrée et des données en sorties, etc… Aussi ces équipes métier ont ouvert des bugs en spécifiant les données en sorties attendues et manquantes. L’équipe qui développe ses services répondait alors : mais c’était implicite que nous ne retournerions pas cette donnée.

Nous avons aussi remarqué que la durée de vie de tels bugs, entre leur création et leur résolution, était d’environ 4 semaines. Le code est livré à l’issue d’une itération d’un mois et l’équipe client l’utilise dans le mois qui suit (dans le meilleur des cas). Ils tombent alors sur le bug généré par le développeur 2 à 3 semaines après qu’il l’ait codé, il doit donc s’y remettre,…

Pour y remédier, nous avons décidé de revoir notre façon de travailler et de mettre les gens ensemble en équipes co-localisées, cross fonctionnelles et interdisciplinaires.

Grâce à cette approche, nous avons réduit de façon très significative (environ 50 %) ces bugs « implicit API ». Plus intéressant encore : la durée de vie de ces types de bugs est tombée à 2 jours. Précisons que certains bugs étaient repérés sans faire l’objet d’un ticket d’incident car les développeurs en pair programming les corrigeaient aussitôt.

Malgré ces progrès, je n’étais pas à l’aise, j’ai compris plus tard pourquoi : d’un point de vue Lean, il y avait deux problèmes :

1-La persistance des anomalies générait du rework et le système de développement produisait des gaspillages : en l’absence de qualité dans le process (“built-in quality”) rien ne garantissait que nous n’allions pas transmettre des problèmes à l’étape suivante. D’autre part, aucune pratique standard n’obligeait l’équipe à s’arrêter à chaque problème pour essayer de le comprendre.

2-Même si ces résultats étaient significatifs et encourageants, il n’y avait aucune corrélation directe avec la performance quotidienne de l’équipe qui permette de prendre des mesures immédiates pour en voir les résultats dès le lendemain. Nous ne regardions que le résultat macro à l’issue de la release de 6 mois. A ce moment-là, on ne pouvait que constater une amélioration de la qualité due à la nouvelle organisation cross-fonctionnelle mais nous n’avions pas les moyens de surveiller et faire évoluer au quotidien.

Rendez-vous dans l’épisode 2 pour voir au travers d’un autre exemple, comment les choses se passent dans un monde plus Lean.