Méthodes et pratiques

Kanban et le Lean logiciel

Une équipe peut être occupée du matin au soir et ne presque rien terminer. La méthode Kanban, que David J. Anderson a formulée à la fin des années 2000, répond à ce problème par deux gestes simples : rendre le travail visible et limiter le nombre de choses commencées. Elle hérite du système de production de Toyota, tout comme le « Lean logiciel » de Mary et Tom Poppendieck, que cet article présente aussi.

Tout le monde est occupé et rien ne sort

Une équipe de six personnes assure la maintenance du logiciel de gestion d'une mutuelle. Un lundi, sa responsable compte les demandes ouvertes : vingt-quatre sont « en cours », soit quatre par personne en moyenne. Chacun passe de l'une à l'autre au gré des relances. Les demandeurs se plaignent des délais, et l'équipe a le sentiment de travailler beaucoup pour un résultat mince.

Cette équipe ne voit pas son travail en cours. Le travail en cours (en anglais work in progress, abrégé en WIP) désigne tout ce qui est commencé et pas encore terminé. Dans un atelier, il s'entasse entre les machines et saute aux yeux. Dans un bureau, il reste invisible, réparti entre des fichiers, des messageries et des mémoires. La méthode Kanban commence par le montrer.

Du kanban de Toyota à la méthode Kanban

En japonais, kanban signifie « enseigne » ou « panneau », et par extension « étiquette » ou « fiche ». Chez Toyota, à partir des années 1950, Taiichi Ohno utilise des fiches pour organiser un flux tiré : un poste ne fabrique des pièces que lorsque le poste suivant en a consommé et lui renvoie la fiche correspondante. Comme le nombre de fiches en circulation est fixe, le stock entre deux postes ne peut pas dépasser un plafond. Le corpus Lean du site décrit ce mécanisme dans l'article sur le flux tiré et le kanban.

David J. Anderson transpose cette idée au travail intellectuel. Il raconte l'avoir d'abord approchée en 2004 chez Microsoft, dans une équipe de maintenance, en s'appuyant sur la théorie des contraintes, puis l'avoir développée à partir de 2006 chez Corbis, une société de Seattle. Son livre Kanban: Successful Evolutionary Change for Your Technology Business paraît en 2010. Pour faire comprendre le principe, il y évoque les jardins du palais impérial de Tokyo. Chaque visiteur reçoit à l'entrée une carte qu'il rend en sortant, et quand toutes les cartes sont distribuées, il faut attendre qu'un visiteur sorte. Le nombre de personnes présentes dans le jardin est ainsi limité sans que personne ait à compter.

Le même mot recouvre donc trois choses : la fiche de Toyota, le tableau à colonnes que beaucoup d'équipes affichent au mur, et la méthode d'Anderson, que l'on écrit avec une majuscule.

Partir de ce que l'on fait déjà

La méthode d'Anderson ne demande au départ aucun changement d'organisation. Ses principes de base sont de partir du fonctionnement actuel, de rechercher un changement progressif et de respecter, dans un premier temps, les rôles et les responsabilités en place. Kanban ne prescrit ni rôle, ni réunion, ni cycle. Il se pose sur l'existant et le fait évoluer par petites touches, là où Scrum demande d'adopter d'emblée un cadre complet.

Le livre de 2010 énumère cinq propriétés que l'auteur dit avoir retrouvées dans les mises en œuvre réussies.

• Visualiser le flux de travail. Un tableau représente les étapes par des colonnes, et chaque demande par une carte.
• Limiter le travail en cours. Chaque étape reçoit un plafond, inscrit en haut de sa colonne.
• Mesurer et gérer le flux. On suit le temps que met une demande à traverser le tableau, plutôt que le taux d'occupation des personnes.
• Rendre explicites les règles de fonctionnement. L'équipe écrit, par exemple, ce qu'une carte doit avoir obtenu pour quitter une colonne.
• Utiliser des modèles pour repérer les améliorations possibles. Anderson cite la théorie des contraintes, les travaux de Deming sur la variabilité et les gaspillages du Lean.

Limiter le travail en cours

Limiter le travail en cours est la règle la plus contraire à l'intuition. Quand les demandes s'accumulent, le réflexe est de tout commencer, pour montrer à chacun que l'on s'occupe de lui. Une relation simple de la théorie des files d'attente, démontrée par John Little en 1961, montre pourquoi ce réflexe allonge les délais. Dans un système stable, le délai moyen de traitement est égal au travail en cours moyen divisé par le débit moyen, le débit étant le nombre d'éléments terminés par unité de temps.

La limite a un second effet : elle fait apparaître les goulots d'étranglement, c'est-à-dire les étapes dont la capacité plafonne le débit de l'ensemble. Reprenons l'équipe de maintenance, qui a affiché un tableau à quatre colonnes : « À faire », « En cours » (8 cartes au plus), « En recette » (4 cartes au plus) et « Terminé ». La recette est la vérification d'une correction avant sa mise en service.

Un jeudi, la colonne « En recette » est pleine, car quatre demandes attendent l'unique testeuse. Léo vient de finir un correctif. La règle lui interdit de l'ajouter en recette, et sa carte reste donc dans la colonne « En cours », qui est pleine elle aussi : il ne peut rien commencer d'autre. Il va voir la testeuse et lui demande : « Qu'est-ce que je peux prendre pour te décharger ? » Elle lui confie la vérification d'une demande simple. Trois semaines plus tard, l'équipe constate que la recette bloque presque chaque jeudi et décide que deux développeurs s'y formeront. Sans la limite, Léo aurait commencé une nouvelle demande, et la pile devant la testeuse aurait encore grossi. Les praticiens de Kanban résument cette discipline par une formule : arrêter de commencer, commencer à finir.

Mesurer le flux

Kanban s'intéresse au trajet des demandes plus qu'à l'emploi du temps des personnes. Le délai de traversée (lead time) est le temps écoulé entre le moment où une demande est acceptée et celui où elle est livrée. Le débit (throughput) est le nombre de demandes terminées par semaine. Avec son historique, une équipe peut répondre à la question de tous les demandeurs sur la date de livraison sans estimer chaque demande, par exemple en annonçant que quatre demandes sur cinq sortent en moins de dix jours.

Le Lean logiciel des Poppendieck

Sept ans avant le livre d'Anderson, Mary et Tom Poppendieck avaient déjà rapproché le développement de logiciels du système de production de Toyota. Leur livre Lean Software Development: An Agile Toolkit (2003) propose sept principes : éliminer le gaspillage, amplifier l'apprentissage, décider le plus tard possible, livrer le plus vite possible, donner le pouvoir à l'équipe, construire un produit intègre et voir l'ensemble. Un second livre, en 2006, les reformule légèrement.

Les Poppendieck transposent aussi les gaspillages de l'usine, que le corpus Lean présente dans l'article sur les sept gaspillages. Le stock devient le travail partiellement fait : une spécification rédigée mais pas développée, ou un code écrit mais pas livré, a coûté de l'effort et ne rapporte encore rien. La surproduction devient la fonctionnalité superflue, celle que personne n'utilisera. La liste comprend encore les changements de tâche, les attentes et les défauts. On reconnaît dans la chasse aux fonctionnalités superflues le dixième principe du Manifeste, qui définit la simplicité comme « l’art de minimiser la quantité de travail inutile ».

Ni Anderson ni les Poppendieck ne figurent parmi les signataires du Manifeste. Leurs travaux forment un courant voisin, qui partage avec lui le goût des petits lots et du retour rapide, et qui s'en distingue par l'attention portée au flux d'ensemble plutôt qu'à l'équipe seule.

Kanban ou Scrum ?

Henrik Kniberg et Mattias Skarin ont comparé les deux approches dans un petit livre de 2010, Kanban and Scrum: Making the Most of Both. Ils les traitent comme des outils que l'on choisit selon la situation et que l'on peut combiner. Corey Ladas a proposé à la fin des années 2000 le nom de « Scrumban » pour ces mélanges. Kanban convient bien au travail qui arrive sans prévenir, comme le support, la maintenance ou l'exploitation. Scrum convient mieux quand une équipe construit un produit et peut se fixer un objectif pour quelques semaines.

Hors du logiciel

Rien dans Kanban n'est propre à l'informatique. Jim Benson et Tonianne DeMaria Barry en ont tiré en 2011 une version individuelle, Personal Kanban, qui tient en deux règles : visualiser son travail et limiter son travail en cours.

Limites et pièges

Un tableau sans limites. Beaucoup d'équipes disent « faire du Kanban » parce qu'elles déplacent des cartes dans un outil. Sans plafond de travail en cours, ce tableau est une liste de tâches bien présentée. Il rend le travail visible, ce qui est déjà utile, mais il ne change rien au flux.

Des limites que l'on relève dès qu'elles gênent. La limite est faite pour gêner : elle signale un blocage et oblige à en parler. Une équipe qui augmente le plafond à chaque tension supprime le signal et garde le problème.

Un flux sans rendez-vous. Scrum impose une revue et une rétrospective à chaque Sprint. Kanban n'impose aucun cycle, et une équipe peut traiter des cartes pendant des mois sans jamais s'arrêter pour examiner son fonctionnement. Il faut donc ajouter soi-même ces temps de recul.

Un point de départ trop confortable. Partir de l'existant facilite l'adoption, mais peut laisser intacte une organisation qui fonctionne mal. Le tableau révèle les blocages et ne les résout pas : dans l'exemple du service d'urbanisme, tout dépendait de la bonne volonté de l'adjoint.

Une analogie avec l'usine à manier prudemment. Une chaîne de montage répète la même opération, alors qu'une équipe de développement fabrique chaque fois quelque chose de nouveau. Donald Reinertsen, dans The Principles of Product Development Flow (2009), rappelle que la variabilité est inévitable dans la conception de produits et qu'on ne peut pas l'éliminer sans éliminer aussi la nouveauté. La chasse au gaspillage, appliquée sans discernement, peut ainsi condamner l'exploration et l'apprentissage, qui ressemblent de loin à du temps perdu.

Des preuves surtout tirées de l'expérience. Les bénéfices de Kanban dans le logiciel sont rapportés par des études de cas et des témoignages de praticiens. Une revue systématique de la littérature publiée en 2013 par Muhammad Ovais Ahmad, Jouni Markkula et Markku Oivo n'a retenu que 19 études pertinentes sur les 492 publications repérées. L'article Que valent les preuves ? replace ce constat dans l'ensemble du corpus.