看板 — Affiche
Kanban (看板) est japonais. Les caractères se décomposent en : 看 (kan), regarder, voir, & 板 (ban) : planche, plaque, signe. Ensemble : une planche de signaux visuels.
Le mot remonte à des siècles avant le système de gestion. Chaque magasin du Japon d'Edo avait un kanban : une plaque de bois à l'extérieur annonçant ce qui était vendu à l'intérieur. Le signal visuel était l'annonce, l'indicateur d'inventaire et le déclencheur de reprise à la fois.
L'insight de Taiichi Ohno sur le supermarché
Dans les années 1950, l'ingénieur Toyota Taiichi Ohno a visité les supermarchés américains. Ce qu'il a vu a changé l'histoire de la fabrication.
Dans une usine traditionnelle, le modèle de poussée , la production fonctionnait selon un calendrier. Un prévisionnement disait "nous aurons besoin de 500 unités le mois prochain", donc l'usine en a fabriqué 500 et les a poussées sur un rayon. Si la demande était fausse, le rayon débordait. Si la demande dépassait la prévision, le rayon était vide. Dans les deux cas, quelqu'un avait tort.
Les supermarchés fonctionnaient différemment. Les rayons contenaient une quantité fixe de chaque article. Lorsque le dernier pot de confiture d'arachide était pris par un client, l'espace vide de l'étagère était lui-même le signal de reprise. Les travailleurs de stock n'avaient pas besoin qu'un gestionnaire leur dise de reprendre : l'étagère leur le disait. C'est le modèle de tirage : la demande en aval déclenche la reprise en amont.
Ohno a ramené cet insight à Toyota. La carte physique (kanban) collée sur un panier de pièces est devenue le signal : "ce panier est vide : produisez plus". Aucune prévision n'était nécessaire. Aucun planificateur central. Le travail s'est tiré devant lui.
Poussée vs. Tirage
La distinction poussée/tirage est la base de tout ce qui suit.
Colonnes en tant qu'états
Un tableau Kanban rend le travail visible. Chaque pièce de travail est une carte. Les cartes se déplacent de gauche à droite à travers les colonnes qui représentent des états.
Les colonnes classiques sont : Backlog → Selected → In Progress → Review → Done
Mais les colonnes exactes n'ont pas d'importance. Ce qui compte, c'est que chaque carte a exactement un état actuel, et cet état est visible à tout le monde qui travaille dans ce système.
Ce que représente une carte
Une carte représente une unité de travail qui peut être achevée indépendamment. Pas un projet. Pas un objectif. Une chose spécifique et délimitée avec une définition claire de ce qui est considéré comme terminé.
Bon exemple de carte : Rotation des clés SSH sur les serveurs de production : terminé lorsque tous les serveurs affichent la nouvelle clé dans authorized_keys et que l'ancienne clé est supprimée.
Mauvaise exemple de carte : Améliorer la sécurité. (Cela représente un projet, pas une tâche. Le cas échéant, le diviser en morceaux.)
Limites WIP
La colonne In Progress dans le diagramme montre une limite WIP : 3. Cela signifie qu'il ne peut y avoir au plus trois cartes en cours d'achèvement en même temps. Si vous souhaitez tirer une quatrième carte, vous devez d'abord en terminer une.
Cela peut sembler comme une contrainte. C'est en effet le cas : à des fins de conception. Les limites WIP vous obligent à terminer ce que vous avez commencé avant de commencer quelque chose de nouveau. Vous en saurez plus sur l'importance de cela dans une section ultérieure.
Délimitation des cartes de travail
L'habileté la plus difficile du Kanban n'est pas de dessiner le tableau. C'est de délimiter les cartes. Trop grandes et la carte reste en cours de réalisation pendant des semaines, bloquant d'autres travaux. Trop petites et le tableau se remplit de bruit.
Les silos fonctionnent bien
Toute opération multi-disciplinaire a des centres de travail fonctionnels : une boulangerie a des pâtisseries, du pain, des produits savoureux et une caisse. Un studio de produits a des designs, un contenu, une construction et des opérations. Un projet de construction a des murs, des tuyaux, de l'électricité et un finissage. Ces centres existent pour de bonnes raisons : une spécialisation profonde nécessite une propriété concentrée.
Le Kanban ne dissout pas ces divisions. Il rend les transferts entre eux visibles et explicites.
La carte de retour
Lorsqu'une unité de travail passe d'un centre de travail à un autre, par exemple, un actif de design qui nécessite une écriture avant que l'assemblage de la page par le constructeur ne puisse avoir lieu, une carte de retour l'accompagne. Le centre en amont voit la carte apparaître dans son Backlog. Ils la tirent lorsque'ils ont de la capacité. Aucourant d'email n'est requis. Aucune réunion n'est nécessaire pour coordonner. La carte est le signal.
Ce que le diagramme montre
Le ticket ★ commence par le Design (En cours : actifs visuels). Lorsque le Design termine sa partie, une carte de retour est créée et le ★ ticket apparaît dans le Backlog du centre Build. Build le tire ensuite. Ensuite, Opérations le tire. Chaque centre a son propre tableau. Chaque tableau montre uniquement le travail actuel de ce centre. Mais le ★ traverse tous les centres et tout le monde peut voir où il se trouve.
C'est l'insight du supermarché appliqué aux organisations : chaque centre de travail est une étagère. Les cartes sont uniquement réapprovisionnées dans les étagères en aval lorsque le travail en amont est tiré et consommé.
Conception d'un retour
La carte de retour est le contrat entre les centres de travail. Elle doit contenir assez de contexte pour que l'équipe de réception puisse agir sans réunion.
Arrêtez de commencer. Commencez à terminer.
WIP signifie Work In Progress. Une limite WIP est un plafond sur le nombre de cartes qui peuvent se trouver dans une colonne à la fois.
Cela sonne comme une restriction. C'est le but.
Pourquoi les limites aident
Chaque fois que vous commencez un nouveau travail sans terminer le précédent, vous payez une taxe de rechange de contexte. Votre cerveau charge le contexte du nouveau travail et décharge partiellement le vieux. Lorsque vous revenez au travail ancien, vous le chargez à nouveau. Pour le travail cognitif, l'écriture, la déboguage, la conception, l'examen, ce coût de rechargement est mesuré en heures, pas en secondes.
Les limites de travail en cours empêchent l'accumulation de travaux incomplets. Elles font également quelque chose de plus précieux : elles mettent en évidence les goulets d'étranglement.
Les goulets d'étranglement deviennent visibles
Si la colonne Examen a une limite de travail en cours de 2 et qu'elle est toujours à 2, c'est un signal : l'examen est plus lent que la production. Plus de travail est terminé dans En cours que ce que l'Examen peut consommer. Sans limite de travail en cours, le tableau se remplit de cartes 'terminées mais en attente d'examen' et le goulet d'étranglement reste invisible. Avec une limite de travail en cours, la colonne En cours ne peut pas accepter de nouvelles cartes et tout l'équipe voit la contrainte.
Cela n'est pas un échec. C'est de l'information. Le système vous dit de corriger l'Examen, embaucher, travailler en équipe, réduire la taille des lots, plutôt que de pousser plus de travail sans réfléchir.
La loi de Little (de manière informelle)
Le temps de traitement (durée d'un ticket de la réception à la fin) = Travail en cours ÷ Taux de trésorerie (tickets terminés par unité de temps). Si vous souhaitez réduire les temps de traitement sans embaucher, réduisez le Travail en cours. Moins de choses en vol signifie que chaque chose se termine plus rapidement.
R = (W × C) + T
Les limites de travail en cours protègent trois variables. L'consultant en efficacité Brian Tracy les a nommées en 1986.
R = (W × C) + T
- R: Résultat : l'issue souhaitée
- W: Clarté du but : la précision avec laquelle vous savez ce que vous voulez (0-10)
- C: Concentration : intensité de l'effort concentré (0-10)
- T: Temps travaillé sans distractions (heures ininterrompues)
Pourquoi W et C se multiplient
La clarté et la concentration ne sont pas indépendantes. Une haute concentration sur un objectif flou produit un mouvement rapide dans la mauvaise direction. Une parfaite clarté de l'objectif sans concentration produit rien. Ils interagissent : c'est pourquoi Tracy les a écrits en tant que produit, pas en tant que somme. Un 9/10 sur chaque variable donne R = 81 + T. Un 3/10 sur chaque variable donne R = 9 + T. La différence n'est pas additive.
Pourquoi T ajoute
Chaque heure sans distraction ajoutée produit linéairement le résultat. T ne peut pas composer W et C : il peut seulement empiler sur le produit. Cela explique pourquoi la première mesure est toujours d'améliorer W et C, pas de travailler plus longtemps. Plus de T sur un faible (W × C) produit donne toujours un résultat médiocre.
Ce que le tableau Kanban fait à chaque variable
- W: Une carte bien détaillée (titre clair, critères d'acceptation mesurables, propriétaire unique) augmente W avant le début du travail. Les cartes floues abaissent automatiquement W.
- C: Les limites de travail en cours forcent la concentration. Une carte dans Active signifie attention totale sur un problème. Trois cartes dans Active signifie que C est divisé en trois.
- T: Les blocs Pomodoro et la protection du calendrier créent les heures sans distraction que T mesure. L'horloge du tableau n'est pas une décoration : elle suit T en temps réel.
Tracy a affirmé que tout problème pouvait être résolu en 30 minutes lorsque W, C et T sont optimisés. Le tableau Kanban est l'instrument pour optimiser les trois simultanément.
Lecture du tableau
La pratique de la lecture des bouchons à partir de l'état du tableau.
Pas Agile. Pas en cascade.
Agile est une méthodologie. En cascade est une méthodologie. Kanban est un système.
Les méthodologies prescrivent comment vous travaillez. Les systèmes décrivent ce qui est vrai sur le travail. Kanban ne vous dit pas de faire des sprints de deux semaines, des réunions quotidiennes ou des retrospectives. Il vous dit une chose : faites le travail visible, limitez le WIP et tirez.
Le problème avec les méthodologies
Agile fonctionne bien pour les équipes qui construisent des produits de manière itérative, du logiciel, pour la plupart. Le modèle en cascade fonctionne bien pour les projets ayant des exigences fixes et des inconnues connues, la construction, la fabrication de matériel. Aucun des deux ne se mappent de manière claire sur le travail interdisciplinaire où une tâche de conception et une tâche d'exécution ont des temps de cycle et des définitions de 'fait' complètement différents.
Forcer un centre de conception et un centre d'exploitation à adopter le même rythme de sprint est une erreur de catégorie. Un sprint de deux semaines qui fonctionne pour la création de contenu crée une urgence artificielle dans le travail logistique. Un rituel de rassemblement debout conçu pour les équipes co-implantées crée un surcoût pour les solos indépendants.
Trouver un terrain d'entente sur les travaux à réaliser
La méthode un : trouver le travail à faire. Trouver les personnes ou les partenaires les mieux placés pour le faire. Ne pas imposer un processus par-dessus : laissez le travail survenir son propre processus grâce à un système de visibilité partagé.
Ce n'est pas l'absence de processus. C'est la bonne quantité de processus : assez pour coordonner, pas assez pour créer un surcoût de coordination qui dépasse la valeur du travail.
Ne construisez pas ce que vous pouvez acheter. Ne buyez pas ce que vous pouvez développer.
Avant la création d'une carte de travail, demandez-vous : cette chose devrait-elle exister du tout ? Chaque pièce de travail que vous construisez, vous l'avez pour toujours. Chaque SaaS auquel vous vous souscrivez, vous en dépendez pour toujours. Chaque dépendance open-source que vous forquez, vous la maintenez pour toujours.
L'arbre de décision : Pouvons-nous développer cela ? Un processus, une compétence, une relation qui produit la capacité de manière soutenable, préférez cela. Si le développement n'est pas viable : Pouvons-nous acheter cela ? Un outil sur-marché qui résout 80 % du problème sans travail personnalisé, préférez cela. Si l'achat n'est pas viable : Construisez-le. Et construisez-le en sachant que vous l'avez maintenant.
La plupart des organisations inversent cet ordre. Elles construisent une infrastructure personnalisée pour les problèmes que les outils de commodité résolvent bien, puis se démènent pour maintenir ce qu'elles ont construit. Kanban rend cela visible : chaque carte dans votre Backlog est une chose que vous avez choisie de construire. La question honnête est de savoir si elle devrait être là du tout.
Build / Buy / Grow
Appliquez le cadre de décision.
Concevez un tableau
Assemblez-le. Vous concevrez un système Kanban pour un scénario cross-fonctionnel spécifique.
Scénario
Une petite équipe de création relance leur produit avec une nouvelle marque. Le travail concerne quatre centres :
- Design : nouveau logo, identité visuelle, photographie de produit, maquettes de pages
- Contenu : descriptions de produit réécrites, copie pour les pages d'accueil, annonce par e-mail
- Construction : site web mis à jour, nouvelle procédure de paiement, redirections depuis les anciennes URL
- Ops : paramétrage mis à jour du processeur de paiement, information du partenaire de livraison, réconfiguration des analyses
La relance a un délai ferme : un salon commercial en 45 jours où la nouvelle marque est rendue publique.
Solos Restent Des Silos
Dans la plupart des organisations, le kanban existe pour rendre le travail visible au sein d'une hiérarchie de gestion. Les gestionnaires coordonnent entre les silos. Le kanban réduit le coût de la coordination.
Dans le modèle un, il n'y a pas de gestionnaires. Il y a des solos. Un solo gère une entreprise indépendamment : un solo design, un solo construction, un solo écriture, un solo opération. Chaque solo est, par définition, un silo. Il n'y a aucune organisation les reliant. Aucune relation de rapport. Aucun gestionnaire pour forcer la coordination.
Le kanban devient la couche de coordination. Pas en aplanissant les silos, les solos restent entièrement indépendants, mais en rendant les transferts entre eux visibles et explicites. Un solo ne fait pas parvenir un courriel ou ne planifie pas de réunion pour transférer du travail. Ils mettent une carte sur un tableau partagé. Le solo recevant la prend quand il a de la capacité.
Cela explique pourquoi le kanban convient mieux au modèle un que les méthodes agile ou en eau froide : il n'exige pas de rythme partagé, pas de retrospectives conjointes, pas de planification synchronisée. Chaque solo définit ses propres limites de travail en cours, son propre temps de cycle, sa propre définition de terminé. La coordination a lieu au niveau des cartes, pas au niveau du processus.