J'ai le plaisir d'être ici en tant qu'invité cette semaine à l'invitation de Jeff. Le thème abordé est le suivant kanban. Malheureusement, cet article est un peu long, parce que je veux aller au-delà du niveau habituel d'extraits sonores que l'on accorde à un sujet important.
Un tour d'horizon terminologique
Kanban est un mot japonais qui signifie simplement signe. Il est utilisé pour contrôler le travail en cours, dans le contexte d'une ligne de production où le flux a déjà été établi (Ohno, Système de production Toyotachapitre 2). Le concept a fait son chemin dans le développement de logiciels, où il est souvent opposé à la Scrum ou suggéré comme complément aux mises en œuvre de la Scrum. Cependant, bien que la plupart des utilisations du terme renvoient à ses origines dans le Toyota Way, son utilisation populaire dénature une grande partie de son intention initiale.
La méthode Toyota est un système de construction qui, en tant que formalisme, remonte au milieu du 20e siècle et a des racines explicites au début du 20e siècle ou même à la fin du 19e siècle. C'est le mode de fonctionnement de Toyota. De nombreuses autres entreprises 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. Un grand nombre de ces entreprises sont mentionnées dans la revue Harvard Business Review. Le nouveau jeu du développement de nouveaux produits de Hirotaka Takeuchi et Ikujiro Nonaka. C'est ce document qui a inspiré Scrum, et Jeff Sutherland continue aujourd'hui à travailler en étroite collaboration avec Nonaka, comme Jeff le décrit dans "Takeuchi et Nonaka : Les racines de la Scrum".
Takeuchi a passé six ans à étudier Toyota et a résumé cette culture apparemment paradoxale dans son livre Toyota extrême. La relation historique entre l'article de la Harvard Business Review et Toyota est parfois indirecte, bien que les principes des deux s'alignent bien. Par exemple, la notion de commencer la conception avant que l'analyse ne soit terminée (sur laquelle nous reviendrons plus loin) est explicite à la fois dans l'article de Takeuchi et Nonaka et dans la description de la méthode Toyota par Liker. L'utilisation d'équipes polyvalentes et diversifiées ressort à la fois de l'article de la Harvard Business Review et de l'article de Toyota extrême.
En tant que Le blog de Jeff décrit, il est important de distinguer le Toyota Way du Lean. Dans son utilisation courante et vulgaire - en particulier dans les contextes méthodologiques - le terme "Lean" est trop souvent interprété comme une façon superficielle d'appliquer les outils du Toyota Way à la production sans en adopter les fondements plus profonds. Kanban est l'un de ces outils. Il peut constituer un élément puissant d'un système de production qui fonctionne déjà en flux, mais il est essentiel de comprendre que les fondements du flux doivent être posés en premier. Dans cet article, le terme "Lean" apparaîtra occasionnellement dans des citations qui, sauf mention contraire explicite, font référence à la méthode Toyota.
Scrum est un cadre de construction de produits basé sur la méthode Toyota. Il existe quelques différences entre leurs principes fondamentaux : par exemple, le Toyota Way a un ingénieur en chef que Scrum divise en un Product Owner et un ScrumMaster. Comme nous le verrons plus loin, Scrum n'est ni construit sur kanban ni n'a besoin de kanbanIl s'agit en effet d'un mécanisme idéal pour limiter les travaux en cours. flux continu monobloc.
Comment le Kanban est-il utilisé ?
Dans Toyota, kanban est utilisé de deux manières principales. L'application originale de la kanban (en tant que signe - voir l'exemple à droite, tiré du livre de Liker La méthode Toyota(chapitre 2) était de pallier un mode d'échec du système de production Toyota. Parfois, il n'est pas possible d'avoir un flux continu d'un seul tenant, en raison d'obstacles tels que le développement multisite, une mauvaise structure organisationnelle ou une mauvaise affectation des travailleurs aux lieux de travail. Si vous êtes un fournisseur éloigné de votre consommateur, vous avez besoin d'un sémaphore pour synchroniser le transfert des marchandises. Les kanban est ce sémaphore. Lorsque le consommateur est à court de pièces, la cellule de travail consommatrice met en place un sémaphore. kanban dans un chariot d'approvisionnement qui demande des fournitures supplémentaires. Le chariot est transporté jusqu'au point d'approvisionnement. Son arrivée est un signal donné au fournisseur pour qu'il en fabrique davantage et qu'il remplisse le chariot, après quoi il peut être renvoyé au consommateur. Le consommateur peut initier la demande un peu à l'avance, ce qui donne au fournisseur le temps de répondre à la demande, ou le fournisseur peut garder un certain stock en réserve de sorte que la plupart des demandes puissent être rapidement satisfaites.
Le fournisseur constitue un stock qui est placé dans un chariot et livré au point d'utilisation. Le chariot est laissé sur place. Lorsque le chariot commence à se vider, vous mettez un kanban Le chariot est ensuite ramené au point de ravitaillement pour être rempli. Vous n'avez pas kanban sans le muda (gaspillage) du déplacement de la carte et du chariot, du coût de stockage de l'inventaire. Vous n'avez pas kanban sans le mura qui provient de la communication à faible largeur de bande entre le fournisseur et le consommateur. Par définition, kanban est basée sur le fait d'avoir muriAu lieu de s'écouler continuellement, le travail s'accumule. Ce mode d'échec crée donc un besoin de limiter le travail en cours. Une utilisation disciplinée des kanban limite le travail en cours.
L'autre application se situe dans une cellule de travail, afin de s'assurer que seul un nombre limité de pièces (généralement une) se trouve à tout moment sur la table devant le travailleur. La table a kanban carrés dessinés sur celui-ci. Les pièces sur lesquelles on travaille doivent se trouver à l'intérieur d'un de ces carrés. Si les pièces s'empilent, cela signifie qu'il y a une surproduction quelque part. Si je suis un producteur, je ne dois produire quelque chose que si je vois que mon voisin a besoin, ou est sur le point d'avoir besoin, de la pièce que je fabrique. Je construis cette pièce pour la livrer à mon voisin juste à temps. Kanban Les carrés sont également utilisés à plus grande échelle dans les usines, comme supports de palettes de pièces ou de pièces plus grandes (voir figure de droite ; tiré de leanmanufacture.net).
Le kanban est une solution de repli inutile pour le travail manufacturier répétitif
Kanban s'applique au travail répétitif - construire le même objet encore et encore. Liker - auteur de La méthode Toyota et autorité reconnue en matière de système de production Toyota - nous dit :
Tout ne peut pas être réapprovisionné sur la base d'un système à flux tendu ; certaines choses doivent être planifiées. Prenons l'exemple des produits haut de gamme, comme une Rolex, une voiture de sport ou ces clubs de golf high-tech dont Tiger Woods fait la publicité. Chaque fois que vous achetez un article spécial ou à usage unique, vous devez réfléchir à ce que vous voulez, prendre en compte les coûts et les avantages et planifier le moment où vous l'achèterez. En quelque sorte, vous créez un calendrier d'achat, puisque vous n'en avez pas besoin dans l'immédiat. (Chapitre 9)
C'est ainsi que fonctionnent les logiciels : Il est rare que l'on construise toujours la même chose. Dans l'industrie manufacturière, quelqu'un doit construire toutes les nouvelles pièces dont nous avons besoin. Dans les logiciels, nous pouvons réutiliser une fonction autant de fois que nous le voulons en y ajoutant autant d'appels que nous le souhaitons, ou réutiliser une classe en instanciant un nouvel objet de celle-ci. Une grande partie de la conception est basée sur l'agrégation et l'extension innovantes et incrémentales d'objets existants. C'est particulièrement vrai dans le domaine des logiciels, mais cela s'étend également à des secteurs tels que l'architecture et la construction. Peu de travaux de conception explorent des territoires totalement nouveaux, mais aucun n'est sciemment une réplique d'une construction antérieure. Il s'agit de construire de nouveaux objets pour répondre à un besoin programmé du marché plutôt que de produire de manière stochastique et répétitive la même forme de base.
Liker poursuit :
Les experts du SPT s'impatientent, voire s'irritent, lorsqu'ils entendent les gens s'extasier et se focaliser sur kanban comme s'il s'agissait du système de production Toyota... Le défi consiste à mettre en place une organisation apprenante qui trouvera les moyens de réduire le nombre d'accidents du travail et de maladies professionnelles. kanban et donc de réduire et finalement d'éliminer le stock tampon. Rappelez-vous : le kanban est un système organisé de stocks tampons et, selon Ohno, les stocks sont des déchets, qu'il s'agisse d'un système "push" ou d'un système "pull". Ainsi, le kanban est une chose dont on s'efforce de se débarrasser, et non dont on est fier. (Chapitre 9)
Les logiciels ont détourné Kanban
La fascination pour les kanban en Europe et en Amérique du Nord trouve son origine dans des informations erronées sur la manière dont la kanban s'inscrit dans le Toyota Way, mais le malentendu comporte également un élément culturel. Kanban est correctement appliquée en tant que solution sélective et détaillée à un problème spécifique. Il ne s'agit pas d'une philosophie du développement. Sharon Begley observe :
Les Occidentaux préfèrent les principes universels abstraits, tandis que les Asiatiques de l'Est recherchent des règles adaptées à une situation donnée. (Sharon Begley, "East Versus West : One Sees Big Picture, Other Is Focused", The Wall Street Journal, 28 mars 2003).
Taichi Ōhno, qui a inventé le kanban nous dit dans son ouvrage de référence, le système de production Toyota :
La surveillance étroite des règles kanban est un problème sans fin...
La règle 6 nous incite à réduire le nombre de... (Chapitre 2)
L'idéal est le flux plutôt que la kanban. Une fois encore, Liker nous conseille d'utiliser judicieusement les stocks tampons lorsque le flux continu n'est pas possible aujourd'hui. Mais l'idéal du flux fournit une direction claire". (Liker, The Toyota Way, chapitre 8)
Le mot kanban est également utilisé comme nom d'une méthodologie récente basée sur la visualisation et l'analyse mathématique du travail en cours. Nous voyons des équipes adopter cette forme de kanbanL'objectif est de faire en sorte que l'Europe devienne un outil ou une méthodologie à part entière plutôt qu'une vision du monde, sans avoir d'abord construit les fondations et les disciplines d'un flux monobloc. Kanban (la méthodologie) décourage le travail d'équipe et augmente le risque de ne pas achever la charge de travail convenue dans un laps de temps tel qu'un sprint. En revanche, elle offre une grande flexibilité aux managers. En effet, elle permet au Product Owner de venir voir l'équipe au milieu du Sprint et d'arrêter ce qu'elle est en train de faire tout en introduisant un nouveau PBI ou une nouvelle tâche. Cette interprétation de kanban se vend aux cadres qui ressentent le besoin de reprendre le contrôle qu'ils ont perdu avec Scrum. La possibilité de rafistoler les choses, plutôt que de résoudre les problèmes à la racine, donne un plus grand sentiment de réussite immédiate sans avoir à réfléchir aux conséquences à long terme des décisions à court terme.
Ces incompréhensions des fondements de Toyota sont profondes, et bien qu'elles aient souvent des conséquences négatives, elles ne sont pas sans conséquences. kanban Le point commun est qu'ils ne se limitent pas aux logiciels. Sur le site Kanban.com, nous trouvons une déclaration du directeur des technologies de l'information de CVG Systems : "Pour tirer le meilleur parti de kanbanNous avions donc besoin d'une solution en boucle fermée qui prenne en charge un processus en flux continu, une solution à laquelle n'importe lequel de nos fournisseurs pouvait accéder facilement. Kanban est un palliatif en l'absence de flux monobloc, et non une méthode pour y parvenir.
Il s'agit de groupes distincts contrôlés par un kanban protocole de réapprovisionnement des stocks à la demande (pull au lieu de push), d'une manière très structurée. Il s'agit d'un protocole en six étapes, très structuré processus (Ōhno, Système de production Toyota, chapitre 2)
Une solution vraiment allégée : Flux continu en une seule pièce
Au lieu de dépendre des kanbanLe Lean élimine en effet mura, muriet muda - l'incohérence, l'absence de flux continu et le gaspillage. Au lieu de suivre le mouvement et le traitement des matériaux, un bon Scrum co-localise les équipes ou les appareils qui fabriquent les artefacts. Les fondements du Scrum encouragent le flux continu d'une seule pièce. Les membres de l'équipe tournent autour d'un PBI à la fois. Une alternative dysfonctionnelle courante est la "swim-lane Scrum" : chaque membre de l'équipe s'approprie individuellement un PBI à travers les étapes du processus. Si un individu rassemble plusieurs PBI ou tente d'accomplir toutes les tâches d'un PBI en même temps, il risque de changer de contexte en raison d'un trop grand nombre de travaux en cours. Kanban permet de suivre le nombre de PBI en cours, en s'appuyant sur la théorie des pseudo-queues, afin de limiter le nombre de cartes pouvant se trouver sur le tableau des tâches.
Une bonne pratique Scrum suit le Toyota Way en se concentrant sur un seul PBI à la fois, en s'appuyant sur l'intelligence et l'auto-organisation de l'équipe - plutôt que sur une méthode - pour gérer le travail en cours. Il n'y a pas de sous-équipes de longue date dans une équipe Scrum : les Developers travaillent ensemble en tant qu'unité. Les individus et les interactions l'emportent sur les processus et les outils. Si l'équipe travaille en tant qu'unité, il n'est plus nécessaire d'attendre que les éléments de travail arrivent d'un autre stade de développement. Cela élimine également les stocks nécessaires pour occuper l'équipe de développement sur le site local, ainsi que les stocks préparés pour l'expédition en parallèle chez le fournisseur. Kanban dépend fondamentalement de ces deux stocks.
Le flux continu d'une seule pièce peut avoir lieu dans une seule équipe travaillant comme une unité étroitement soudée, dans une seule cellule de travail (ou équipe Scrum), pour appliquer plusieurs transformations au travail en cours (qui est limité à une seule pièce à la fois). L'équipe fait un peu d'analyse, un peu de conception, un peu de construction et un peu de tests en même temps, dans des cycles très courts. Les individus sont polyvalents, ce qui reflète le concept Toyota de chaku-chaku. Voir l'illustration de droite, tirée de la figure 8-4 de The Toyota Way. Elle reflète une méthode de travail assez peu structurée, comme l'expliquent Takeuchi et Nonaka dans l'article de la Harvard Business Review :
Plutôt que de se dérouler par étapes définies et très structurées, le processus naît de l'interaction entre les membres de l'équipe... Un groupe d'ingénieurs, par exemple, peut commencer à concevoir le produit (phase 3) avant d'avoir obtenu tous les résultats des tests de faisabilité (phase 2). Il se peut aussi que l'équipe soit obligée de reconsidérer une décision à la suite d'informations ultérieures. L'équipe ne s'arrête pas là, mais s'engage dans une expérimentation itérative. Ce processus se poursuit même dans les phases les plus récentes du processus de développement.
Liker souligne l'existence d'un flux monobloc dans le chapitre 3 de l'ouvrage La méthode Toyota:
... la cellule à flux unique est le nec plus ultra de la production allégée. Elle a permis d'éliminer la plupart des huit types de déchets de Toyota.
En fait, l'objectif ultime de la production allégée est d'appliquer l'idéal du flux d'une seule pièce à toutes les opérations de l'entreprise, 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 que nous ayons dans le domaine des logiciels. Il n'y a pas de codeur ni de testeur : il y a deux développeurs qui travaillent ensemble dans une cellule de travail, testant et développant continuellement jusqu'à ce que le travail en cours soit terminé. Une bonne programmation en binôme n'est pas du tout structurée. Parce que les boucles de rétroaction se produisent localement et immédiatement, il n'est pas nécessaire d'avoir une carte Kanban littérale. Comme il s'agit de deux esprits qui ne font qu'un, il n'est pas nécessaire d'avoir des carrés Kanban sous le clavier. Toujours selon Liker, "dans une cellule à flux unique, il y a très peu d'activités sans valeur ajoutée, comme le déplacement de matériaux. Vous voyez rapidement qui est trop occupé et qui est inactif". (La méthode Toyota(chapitre 17)
Cela ne s'arrête pas à la programmation en binôme. Le flux continu d'une seule pièce est l'une des techniques de base que nous enseignons aux participants au cours de certification ScrumMaster pour qu'ils l'appliquent à l'ensemble de l'équipe tout au long du sprint. Dans le Jeu Velocity nous insistons sur le fait que l'ensemble de l'équipe doit travailler sur un PBI à la fois - en essaimant au lieu de jouer à Swim-Lane Scrum. Le rythme est effréné, mais le flux devient fluide après deux ou trois sprints - parce qu'il y a une visibilité totale de qui fait quoi, seconde par seconde. Kanban Les cartes ne feraient qu'entraver le processus. Les bonnes équipes de développement sont comme des équipes de football, de hockey ou de basket-ball. Les joueurs et les artefacts du jeu sont les éléments les plus importants pour comprendre la nature du travail en cours.
La programmation en binôme, en tant que technique, dépend de la mise en place du flux Scrum : bonne spécifications d'habilitation à partir du Backlog de produit, l'auto-organisation et la sélection des tâches parmi les développeurs, etc. Il en va de même pour les autres formes de flux au sein d'une équipe Scrum. Il ne s'agit pas d'une solution miracle, et il n'existe pas de voie rapide pour jeter les bases de la qualité et de l'efficacité. En fait, kanban a été l'un des ajouts les plus tardifs au système de production Toyota, car il fallait attendre que les flux plus larges soient en place. Comme le raconte Ōhno, "les gens de l'extérieur semblent penser que le système de production Toyota et le système de gestion de la chaîne d'approvisionnement de l'entreprise sont des éléments essentiels du système de production Toyota". kanban sont la même chose... Mais... Si l'on ne maîtrise pas complètement cette méthode de travail pour que les choses s'enchaînent, il est impossible d'entrer de plain-pied dans l'univers du travail. kanban le moment venu". (Ōhno, Système de production Toyota, chapitre 2)
Kanban : Une bonne solution pour les équipes qui considèrent le travail comme une lutte contre l'incendie
Les usines de production Toyota et les équipes Scrum existent pour construire des produits. La littérature fait état d'une application réussie de l'approche kanban dans le secteur des services, par analogie avec les pompiers ou les services d'urgence des hôpitaux. Il est difficile de programmer le prochain incendie, sauf si vous vivez dans le monde des Fahrenheit 451. De nombreuses équipes de développement fonctionnent en mode lutte contre les incendies, souvent avec un "swooping" du Product Owner au cours d'un Sprint. Il est difficile d'adopter une discipline : il est facile de vouloir réagir immédiatement aux changements des clients au lieu d'intégrer une demande dans le plan d'entreprise, et il est agréable de lancer un produit quand on le souhaite. Certaines équipes Scrum n'apprennent jamais les disciplines de la planification et de l'estimation. Il est facile de comprendre 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 la collaboration, de se sentir responsables de l'achèvement du travail dans le respect des prévisions, ou de développer les disciplines de la planification à long terme et des spécifications habilitantes qui sont à la base de la valeur à long terme. Le problème avec kanban (comme pour le Scrum-cul) est que la mauvaise exécution qui en résulte ne vous tuera pas. Dans son livre, Liker s'étonne de l'ignorance des soi-disant praticiens du Lean et a constaté des réductions de stocks allant jusqu'à 80% après que leur compréhension a été clarifiée (Liker, The Toyota Way, chapitre 14). Il ajoute : "Je suis très étonné de l'ignorance des soi-disant praticiens de l'allégement :
J'ai visité des centaines d'organisations qui prétendent être des praticiens avancés des méthodes allégées... [Après avoir étudié Toyota pendant vingt ans, il m'apparaît clairement qu'en comparaison, ce sont des amateurs.
Il estime que moins de 1% des entreprises extérieures à Toyota ont compris (Liker, The Toyota Way, chapitre 1). (Liker, The Toyota Way, chapitre 1) Beaucoup de ces entreprises suivent le mot à la mode Lean au lieu de suivre le cœur de la méthode Toyota. Le cadre Scrum, tel qu'il a été défini, a soigneusement évité ce piège (voir "Takeuchi et Nonaka : Les racines de Scrum").
Il en va de même pour les logiciels. Les équipes qui ont fait les deux ont constaté que kanban peut en fait offrir moins de visibilité aux travaux en cours que le Scrum, et supprimer le sentiment de travail d'équipe et de "pression positive" qui découle du flux d'une équipe Scrum (cf. Réflexions de Samuli Heljo).
L'esprit Kaizen : retour aux sources
French 
English 
Spanish