Le flux continu pièce à pièce, une alternative à Kanban
Auteur : Jim Coplien
Source : An Alternative to Kanban: One-Piece Continuous Flow
Date : 20/11/2011
Traducteur : Fabrice Aimetti
Date : 22/11/2011
Traduction :
Un petit tour sur la terminologie
Kanban est un mot japonais qui signifie simplement signe. Il est utilisé pour maîtriser les travaux en cours, dans le cadre d'une ligne de production où le flux de travail a déjà été mis en place (Ohno, Toyota Production System, chapitre 2). Le concept a trouvé sa place dans le développement logiciel, où il est souvent distingué de Scrum ou suggéré comme un complément aux implémentations de Scrum. Toutefois, si la plupart des utilisations du terme nous ramènent à ses origines dans La Voie Toyota, son utilisation populaire fait l'impasse sur une grande partie de son intention initiale.
La Voie Toyota est un système de construction de choses qui, formellement, remonte à la moitié du 20ème siècle, et a des racines explicites dans le début du 20ème siècle ou même à la fin du 19ème siècle. C'est la manière dont Toyota fonctionne. Beaucoup d'autres sociétés japonaises, à commencer par les fournisseurs de Toyota mais aussi beaucoup d'autres, suivent les mêmes principes de chevauchement des phases de développement, d'auto-organisation et d'apprentissage. Nous trouvons beaucoup de ces sociétés mentionnées dans l'article de la Harvard Business Review "Les Nouvelles Règles de Développement d'un Nouveau Produit" rédigé par Hirotaka Takeuchi et Ikujiro Nonaka. C'est l'article qui a inspiré Scrum et Jeff Sutherland continue de travailler étroitement avec Nonaka aujourd'hui, comme Jeff le décrit dans son billet "Takeuchi et Nonaka: Les racines de Scrum".
Takeuchi a passé six ans à étudier Toyota et a résumé cette culture apparemment paradoxale dans son livre Extreme Toyota. La relation historique entre l'article de la Harvard Business Review et Toyota, est parfois indirecte, même si les principes mis en avant par les deux s'alignent très bien. Par exemple, le fait de commencer la conception avant que l'analyse soit terminée (nous y reviendrons plus tard ci-dessous) est explicite à la fois dans l'article de Takeuchi et Nonaka ainsi que dans la description de La Voie Toyota faite par Liker. L'utilisation de la polyvalence de multiples équipes est mentionnée à la fois dans l'article de la Harvard Business Review et dans le livre Extreme Toyota.
Comme le billet de Jeff le décrit si bien, il est important de distinguer La Voie Toyota du Lean. "Lean" dans son utilisation la plus commune et grossière - en particulier sa démarche méthodologique - est trop souvent interprétée comme un moyen pour appliquer de façon superficielle les outils de La Voie Toyota à la production, sans pour autant adopter ses fondamentaux les plus essentiels. Kanban est un de ces outils. Il peut être un élément puissant d'un système de production qui travaille déjà en flux, mais il est crucial de comprendre que la mise en oeuvre du flux doit venir en premier. Dans cet article, le terme "Lean" sera occasionnellement cité et, sauf mention explicite contraire, il fera référence à La Voie Toyota.
Scrum est un framework pour construire un produit basé sur La Voie Toyota. Il y a peu de différences entre leurs fondamentaux : par exemple, La Voie Toyota a un ingénieur en chef que Scrum divise en un Product Owner et un ScrumMaster. Comme nous allons en discuter ci-dessous, Scrum n'est pas construit sur la base de kanban, n'a pas besoin de kanban, car il est idéalement adapté comme un mécanisme de limitation du travail en cours appelé flux continu pièce à pièce.
Comment est utilisé Kanban ?
Le fournisseur fournit le stock nécessaire qui est mis dans le chariot et livré sur le lieu d'utilisation. Le chariot est laissé sur place. Lorsque le chariot commence à se vider, vous mettez une carte kanban (un signe) dedans en y inscrivant des informations sur les besoins anticipés, et le chariot est de nouveau véhiculé au point d'approvisionnement afin d'être rempli. Vous n'avez pas de kanban sans muda (gaspillage) qui comprend le déplacement de la carte et du chariot ainsi que le coût du stockage. Vous n'avez pas de kanban sans le mura (NdT : irrégulier, non lissé) qui provient de la faible bande passante de communication entre le fournisseur et le consommateur. Par définition, le kanban est basé sur le muri (NdT : surcharge non raisonnable, souvenez-vous : "je vais muri-r") : au lieu d'un flux continu, le travail s'empile. Ce mode de travail défaillant crée donc le besoin de limiter les travaux en cours. Une utilisation disciplinée de kanban limite les travaux en cours.
Le kanban constitue un moyen de lutter contre le gaspillage lors d'un travail de fabrication répétitif
Le kanban s'applique à un travail répétitif, c'est-à-dire construire le même élément, encore et encore. Liker, auteur du livre La Voie Toyota et qui est une autorité reconnue sur le sujet du Système de Production Toyota, nous dit :
On ne peut pas tout réapprovisionner en se basant uniquement sur un système de flux tiré ; certaines choses doivent être planifiées. Prenons l'exemple de produits haut de gamme, comme une Rolex, une voiture de sport ou ces supers clubs de golf high-tech dont Tiger Woods fait la publicité. A chaque fois que vous achetez un objet spécial ou à usage unique, vous devez penser à ce que vous voulez, vous devez comparez les coûts et les bénéfices et finalement planifier son acquisition. En un sens, vous créez un calendrier d'achat puisque vous n'en avez pas un besoin immédiat. (Chapitre 9)
Le logiciel est dans le même cas : nous construisons rarement la même chose encore et encore. Dans le domaine de la fabrication, on doit construire toutes les nouvelles pièces dont nous avons besoin. Dans le domaine du logiciel, nous pouvons réutiliser une fonction autant de fois que nous désirons en ajoutant autant d'appels à cette fonction que nous le souhaitons, ou nous pouvons réutiliser une classe en instanciant un nouvel objet à partir d'elle. Beaucoup des travaux de conception sont basés sur le fait d'innover, d'aggréger et d'étendre des objets qui existent déjà. C'est particulièrement vrai dans le monde du logiciel, mais cela s'étend aussi à des industries telles que l'architecture du bâtiment et la construction. Peu de travaux de conception sont amenés à totalement défricher de nouveaux territoires, même si aucun artisan ne fait sciemment une réplique exacte d'une ancienne construction. Il s'agit de construire de nouvelles choses pour les besoins d'un marché planifié plutôt que de produire de façon répétitive et stochastique la même forme de base.
Liker continue :
Les experts TPS s'impatientent vraiment et s'irritent même lorsqu'ils entendent les gens divaguer et se consacrer au kanban comme s'il s'agissait du Système de Production Toyota... Le défi c'est de développer une organisation apprenante qui va trouver de nouvelles façons de réduire le nombre de kanban et donc de réduire et finalement d'éliminer les stocks tampons. Rappelez-vous : le kanban est un système organisé de stocks tampons et, selon Ohno, le stock est un gaspillage, que ce soit dans un système à flux poussé ou à flux tiré. Le kanban est donc quelque chose dont vous cherchez à vous débarrasser, dont vous n'êtes pas fier. (Chapitre 9)
Le monde du logiciel a détourné l'usage de kanban
La fascination pour le kanban en Europe et en Amérique du Nord trouve ses racines dans la désinformation sur la façon dont le kanban s'inscrit dans La Voie Toyota, mais il y a aussi un élément culturel à l'origine de cette incompréhension. Le kanban est vraiment mis en oeuvre comme la résolution sélective et précise d'un problème spécifique. Ce n'est pas une philosophie de développement. Sharon Begley fait l'observation suivante :
Les occidentaux préfèrent des principes abstraits universels. Les orientaux cherchent des règles appropriées à une situation donnée. (Sharon Begley, "L'Est par rapport à l'Ouest : l'un voit l'image complète, l'autre se concentre sur un point précis", Wall Street Journal, 28 mars 2003).
Taichi Ohno, qui a inventé le système kanban, nous raconte dans son ouvrage historique Le Système de Production Toyota :
La surveillance étroite des règles kanban est un problème sans fin... La règle 6 nous exhorte à réduire le nombre de kanban... (Chapitre 2)
L'idéal est le flux plutôt que le kanban. Encore une fois, Liker nous conseille : "les stocks tampons sont utilisés judicieusement là où le flux continu n'est pas possible aujourd'hui. Mais le flux idéal nous fournit une direction claire." (Liker, La Voie Toyota, chapitre 8).
Le mot kanban est également utilisé comme le nom d'une méthode récente basée sur la visualisation et l'analyse mathématique des travaux en cours. Nous voyons des équipes adopter cette forme de kanban en tant qu'outil ou méthode à part entière plutôt que comme une vision du monde, sans avoir d'abord mis en oeuvre les fondations et la discipline associées à un flux pièce à pièce. Le kanban (la méthode) décourage le travail d'équipe et augmente le risque de ne pas terminer la quantité de travail convenue à l'avance au sein d'une boîte de temps semblable au Sprint. Cela donne aux managers une grande souplesse. Autrement dit, cela permet au Product Owner de venir voir l'équipe en plein milieu d'un Sprint et d'arrêter ce qu'elle est train de faire tout en introduisant un nouvel élément dans le Backlog du Produit ou une nouvelle tâche. Cette interprétation du kanban vend aux managers un moyen de retrouver le contrôle sur ce qu'ils avaient perdu avec Scrum. La capacité à rafistoler les choses, plutôt qu'à résoudre les problèmes à la racine, procure une plus grande sensation de succès immédiat sans avoir à réfléchir aux conséquences à long terme de décisions à court terme.
Cette mauvaise compréhension des fondamentaux de Toyota est profonde, et même si elle utilise souvent kanban comme un fil conducteur, elle ne se limite pas au logiciel. Si nous jetons un coup d'oeil à Kanban.com, nous tombons sur un constat du Directeur informatique de CVG Systems : "Pour tirer le meilleur profit de kanban, nous avions besoin d'une solution en boucle fermée qui permettait d'obtenir un processus en flux continu, une solution qui n'était compatible avec aucun de nos fournisseurs." Le kanban est un bouche-trou en l'absence de flux pièce à pièce, et non une méthode pour y parvenir. Il s'agit de groupes distincts contrôlés par un protocole kanban qui approvisionne les stocks sur demande (mode tiré au lieu de poussé), d'une manière très structurée. Il s'agit d'un processus en six étapes, très structuré (Ohno, Système de Production Toyota, chapitre 2).
Une solution vraiment Lean : un flux continu pièce à pièce
Au lieu de se baser sur kanban, le vrai Lean élimine les mura, muri et muda, respectivement l'inconsistance (NdT : ou la variabilité), l'absence de flux continu (NdT : ou lissé) et les gaspillages. Au lieu de tracer le mouvement et la transformation des pièces, une bonne implémentation de Scrum co-localise les équipes ou les appareils qui produisent les objets. Les fondamentaux de Scrum favorisent le flux continu pièce à pièce. Les membres de l'équipe fourmillent autour d'un seul élément du Backlog Produit à la fois. Une autre possibilité fréquente et qui est une anomalie est le "Scrum en couloirs" : chaque membre de l'équipe s'approprie un élément du Backlog Produit à travers les étapes d'un processus. Si un individu traite plusieurs éléments du Backlog Produit, ou essaye de réaliser toutes les tâches d'un élément du Backlog Produit, vous le verrez probablement passer d'une tâche à l'autre, ce qui provient du fait d'avoir trop de travail en cours. Le kanban propose de suivre le nombre d'éléments du Backlog Produit en cours, en s'appuyant sur des pseudo-théories mathématiques sur les files d'attente, afin de limiter le nombre de cartes sur le tableau des tâches.
Une bonne implémentation de Scrum respecte La Voie Toyota en se concentrant sur un seul élément du Backlog Produit à un instant donné, en s'appuyant sur l'intelligence de l'équipe et sur l'auto-organisation pour gérer les travaux en cours, plutôt qu'en faisant appel à une méthode. Il n'y a pas de sous-équipes qui durent longtemps dans une équipe Scrum : les développeurs travaillent ensemble comme une unité soudée. Ce sont les individus et les interactions plus que les processus et les outils. Si l'équipe fonctionne comme une unité soudée, elle élimine le problème d'attendre des éléments de travail en provenance d'une autre étape de développement. Elle élimine également les stocks nécessaires pour maintenir l'équipe de développement occupée sur un même site, ainsi que la préparation en parallèle des stocks chez le fournisseur qui doit les livrer. Le kanban dépend fondamentalement de ces deux types de stocks.
Plutôt que d'investir dans la définition et la structuration à outrance des différentes étapes, le processus est né de l'interaction entre les membres de l'équipe... Un groupe d'ingénieurs, peut par exemple commencer à concevoir le produit (étape 3) avant que tous les résultats des tests de faisabilité (étape 2) soient rendus disponibles. Ou une équipe peut être forcée de reconsidérer une décision suite à des informations tardives. Dans tous les cas, l'équipe ne s'arrête pas, elle se livre plutôt à des expérimentations de façon itérative. Et elle continue à le faire même dans les dernières étapes du processus de développement.
Liker souligne l'importance du flux pièce à pièce dans le chapitre 3 de La Voie Toyota :
... la cellule qui travaille avec un flux pièce à pièce représente le summum de la production lean. Elle a éliminé la plupart des huit sortes de gaspillage recensées par Toyota.
En fait, le but ultime de la fabrication lean consiste à appliquer l'idéal du flux pièce à pièce à toutes les opérations métiers, de la conception du produit au lancement, la prise de commande et la production physique.
La programmation en binôme est l'une des meilleures analogies dont nous disposions dans le monde du logiciel. Il n'y a pas de codeur et pas de testeur : il y a deux développeurs travaillant ensemble dans une cellule de travail continuellement en train de tester et de développer jusqu'à ce que le travail en cours soit fini-fini-fini. Une bonne programmation en binôme est peu structurée. Puisque les boucles de feedback se produisent localement et immédiatement, il n'est pas nécessaire d'avoir une carte kanban réelle. Puisque les deux esprits travaillent comme un seul, il n'est pas nécessaire d'avoir des carrés kanban en dessous du clavier. Encore une fois, Liker dit : "Dans une cellule d'un flux pièce à pièce, il y a très peu d'activité ne générant pas de valeur ajoutée comme par exemple le déplacement de matériaux autour d'elle. Vous voyez très rapidement qui est surchargé et qui est inactif." (La Voie Toyota, chapitre 17).
Cela ne s'arrête pas à la programmation en binôme. Un flux continu pièce à pièce fait partie intégrante des techniques que nous enseignons aux participants de la formation certifiante ScrumMaster pour l'appliquer sur toute l'équipe tout au long du sprint. Dans l'exercice du Jeu de la Vélocité, nous soulignons que toute l'équipe doit travailler sur un seul élément du Backlog Produit à la fois, fourmillant autour au lieu de jouer au Scrum en couloirs. Le rythme est effréné, mais le flux se lisse après deux ou trois sprints car il y a une visibilité complète sur qui fait quoi, seconde par seconde. Les cartes Kanban nous empêcheraient de le faire. Les bonnes équipes de développement sont comme des équipes de football, de hockey ou de basket-ball. Les joueurs et les objets du jeu sont les plus importantes choses à prendre en considération pour comprendre la nature des travaux en cours.
La programmation en binôme, en tant que technique, dépend du fait d'avoir le plus grand flux Scrum en place : favoriser de bonnes spécifications à partir du Backlog Produit, de l'auto-organisation, une sélection des tâches entre les développeurs, et ainsi de suite. La même chose est vraie pour les autres formes de flux au sein d'une équipe Scrum. Ce n'est pas une solution miracle, et il n'y a pas de voie rapide pour bâtir les fondations de la qualité et de l'efficacité. En fait, le kanban a été l'un des derniers ajouts au Système de Production Toyota, car il a fallu attendre que de plus grands flux soient en place. Comme Ohno le précise : "Les étrangers semblent penser que le Système de Production Toyota et le kanban sont la même chose... Mais ... A moins que quelqu'un comprenne parfaitement cette méthode pour réaliser le travail de sorte que les choses soient dans un flux, il est impossible de se diriger directement vers un système kanban lorsque le moment est venu." (Ohno, Système de Production Toyota, chapitre 2).
Le kanban : adapté pour les équipes qui voient leur travail comme le fait d'éteindre les incendies
Les usines de production Toyota et les équipes Scrum existent pour construire des produits. La littérature mentionne l'application réussie de kanban dans le secteur des services, de manière analogue à la lutte contre les incendies ou aux salles d'urgence des hôpitaux. Il est difficile de planifier votre prochain incendie, sauf si vous vivez dans le monde de Fahrenheit 451. De nombreuses équipes de développement fonctionnent en mode pompier, souvent dû à des "attaques en piqué" du Product Owner au cours du Sprint. Et se discipliner est difficile : il est facile de vouloir être en mesure de réagir immédiatement aux demandes de changement du client au lieu d'intégrer une demande dans le business plan, et il semble intéressant de livrer une version lorsque bon vous semble. Certaines équipes Scrum n'apprennent jamais la discipline de la planification et de l'estimation. Il est facile de voir comment ces organisations gravitent autour de kanban.
Il est difficile pour ces équipes de développer un véritable sens du travail d'équipe et de travailler ensemble, de ressentir la paternité d'un travail terminé selon une prévision, ou de développer la discipline d'une planification à long terme et de spécifications à la base d'une valeur à long terme. Le problème avec le kanban (comme avec le Scrum-butt ; NdT : Scrum Canada Dry), c'est que les piètres résultats obtenus ne vous tueront pas. Dans son livre, Liker s'étonne de l'ignorance des pseudo-praticiens Lean, et a vu les stocks se réduire de presque 80% une fois après avoir éclairé leur compréhension (Liker, La Voie Toyota, chapitre 14). Il dit :
J'ai visité des centaines d'organisations qui prétendent être des pratiquants avancés des méthodes lean ... Après avoir étudié Toyota pendant vingt ans, il est clair pour moi qu'en comparaison ce sont des amateurs.
Il estime que moins de 1% des entreprises en dehors de Toyota "y arrive". (Liker, La Voie Toyota, chapitre 1). Beaucoup des entreprises qui essayent, suivent le mot Lean à la mode au lieu du coeur de La Voie Toyota. Le framework Scrum, tel qu'il est défini, a soigneusement évité ce piège (voir "Takeuchi et Nonaka : Les Racines de Scrum").
La même chose est vraie dans le logiciel. Les équipes qui ont fait les deux ont constaté que le kanban peut effectivement offrir moins de visibilité à l'entreprise sur le travail en cours que Scrum ne le fait, et dissiper l'esprit d'équipe ainsi que la "pression positive" provenant du flux d'une équipe Scrum (voir les réflexions de Samuli Heljo).
S'engager sur la voir du Kaizen : retour aux fondamentaux
Une bonne équipe Scrum bénéficie automatiquement des apports de kanban lors de la pratique d'un flux continu pièce à pièce. C'est une façon toute faite de limiter le travail en cours tout en encourageant le travail d'équipe. Elle procure aux membres de l'équipe une autonomie au sein de la boîte de temps pour réaliser leurs travaux tout en leur permettant de mieux satisfaire leurs prévisions. Une telle maturité peut constituer une bonne base pour déployer plus tard des techniques comme le kanban, mais l'inventeur de kanban aussi bien que notre propre expérience suggèrent qu'il est probable d'échouer sans un cadre comme Scrum qui permet d'apprendre à discipliner le flux.
Je remercie Gertrud Bjørnvig, Neil Harrison, Kenji Hiranabe, Bojan Jovicic, Jens Østergaard, David Starr, Jeff Sutherland et Stefan van den Oord pour leurs commentaires et leurs éclaircissements.
