Rappel de l’épisode 1 sur ce qui différencie une équipe Agile d’une équipe Lean : en l’absence de qualité dans le process – “built-in quality”- rien ne garantit que l’équipe de développement ne va pas transmettre de bugs à l’étape suivante ; aucune pratique standard n’oblige l’équipe à s’arrêter à chaque problème pour essayer de le comprendre. D’autre part, en analysant le résultat macro uniquement à l’issue d’une release de 6 mois : l’équipe ne sait pas faire de corrélation directe entre ses actions d’amélioration et l’évolution de sa performance quotidienne.

Dans ce second épisode, nous allons voir comment cela se passe dans une équipe Lean et comment faire pour passer d’une équipe agile à une équipe Lean.

Ce qui se passe dans un monde plus “Lean”

Deux ans plus tard, dans la même organisation, je suis devenu leader et coach chargé de mettre en œuvre l’Agile dans le cadre d’un grand projet multi-équipes et multi-technologies. L’une des équipes développe une intégration technique complexe avec une technologie dont nous sommes loin d’être des experts. Cette équipe n’a pas réussi à livrer une seule user story au cours des deux derniers sprints et rencontre des problèmes de qualité, avec de nombreux bugs. Lors de la rétrospective sur le dernier des deux sprints, l’équipe décide de passer chaque semaine les bugs en revue (analyse de bacs rouge en langage Lean). Elle commence alors par bâtir un Pareto des problèmes.

Dès lors, elle se fixe comme objectif d’éliminer la cause racine de chaque famille de bug, une par une, en commençant par celles qui ont le plus d’occurrences. Pour favoriser la collaboration sur ce sujet, le Scrum Master décide d’afficher ce pareto près du Scrum Board avec le nombre de bugs et de le mettre à jour quotidiennement. Chaque nouveau bug est répertorié immédiatement lors de la réunion du matin, quand l’équipe présente ses bugs du jour. Cela rend explicite et concrète la notion de qualité quotidienne pour l’équipe. Cela aide aussi à faire l’étape « C » du PDCA : le check. Quand le problème est éradiqué, il ne doit plus y avoir de bug sur cette ligne pour une semaine. Et si cela se reproduit, c’est une nouvelle opportunité d’apprentissage !

Prenons un exemple : l’équipe identifie une régression comme famille de bug ; une modification logicielle a cassé une fonctionnalité existante. Cela se produit généralement sur l’interface utilisateur qu’il est très difficile de tester automatiquement. L’une des causes racine identifiées vient de l’inexpérience des développeurs les plus juniors qui ne comprennent pas toujours l’impact de leur modification sur le code.  La contre-mesure est d’introduire une nouvelle étape dans le processus, une revue de code avant le commit sur le référentiel SVN avec un développeur plus senior. Non seulement cette étape de 15 minutes réduit drastiquement les régressions, ce qui est visible quotidiennement sur le nombre de bugs par release (2 releases par jour) mais elle permet aussi d’améliorer les compétences des développeurs junior.

A la fin, tous les problèmes sont résolus et les résultats sont remarquables : les problèmes ont été éliminés un par un grâce aux standards (code review avant commit). Le nombre de bugs quotidien chute et le nombre de user stories livrées – fonctionnelles et sans bug –  augmente à chaque itération. En 3 mois, l’équipe qui détenait le triste record de livraison de bugs au sein du projet est devenue un exemple à suivre d’équipe qui livre de la qualité rapidement.

Cette approche, plus Lean que la précédente, a un impact direct sur la performance quotidienne (qualité) et la productivité (nombre de user stories livrées) et l’équipe a mis la barre haute en termes de standards opérationnels.

Exemple d’indicateurs de performance pour équipe agile

Transformer une équipe Agile en une équipe Lean

A partir de ces exemples et de ce que j’ai appris, voici la roadmap que je propose pour transformer une équipe agile en équipe Lean qui apprend :

. Mesurer la performance, la rendre visible et en discuter tous les jours

Ce qui suit sera peut-être difficile à entendre pour certains coaches agiles mais la vérité c’est que si l’on veut améliorer quelque chose, il faut le mesurer. D’autant que l’on n’apprend que si l’on se confronte à la réalité. C’est ainsi que font les géants du web (Google, Amazon, Twitter, Facebook) et d’autres leaders comme Etsy : ils mesurent quasiment tout. Ca n’est pas en comptant simplement les story points qu’ils sont devenus ce qu’ils sont ! Un exemple concret pour une équipe agile : au-delà du burndown chart du sprint, montrer la performance sur la qualité (nombre de bugs encore ouverts, nombre de bugs par release, par famille, etc), satisfaction client (une note sur 10 par user story par exemple) et se demander chaque jour pourquoi l’on n’atteint pas l’objectif sur le burndown chart.

. S’assurer que les problèmes sont exprimés au sens « lean » du terme

Un problème doit être exprimé comme une différence entre la performance constatée et la cible. Le pareto est un outil parfait pour classer des données brutes par familles mais il nécessite une analyse complémentaire pour comprendre comment chaque famille affecte la performance.

De cette manière, vous serez sûr d’avoir correctement formulé le problème et de l’attaquer de la bonne manière, du point de vue de la performance économique.

. Traiter les problèmes un par un quand ils apparaissent

L’une des clés de la résolution de problème en Lean : on ne traite pas plusieurs problèmes à la fois. On en traite un seul pour comprendre son impact sur les indicateurs de performance et pour s’assurer que l’on comprend la relation de cause à effet.

. Faire le check

D’expérience, c’est l’étape que l’on a hélas tendance à oublier. Confronter ses estimations à la réalité. Cela n’a pas fonctionné comme vous l’espériez ? Super ! Que peut-on en apprendre ?  C’est dans cet espace précieux entre ce que vous pensiez qu’il allait se passer et ce qui s’est réellement passé que l’apprentissage se produit. Exactement ce qui s’est passé avec la 2e équipe. Comme l’explique Stephen J. Spear dans Chasing the Rabbit, c’est là que votre système organisationnel susurre à votre oreille : « il y a une chose que tu ne sais pas encore mais si tu écoutes attentivement, je vais te le dire ». C’est là que l’équipe développe son expertise sur son propre travail et ses processus et devient à coup sûr une dream team.

De l’Agile au Lean

En tant qu’Agiliste depuis 2004, j’ai évolué vers le Lean au cours des dernières années et cela m’a permis de dépasser les obstacles que l’Agile seule ne me permettait pas de surmonter.

Le Lean m’a permis d’aller au-delà de l’Agile, d’adopter des pratiques d’amélioration continue qui ont un effet direct sur la performance de l’équipe et son engagement. Faire un distinguo clair entre les bugs et les problèmes a été déterminant dans cette amélioration.