Kanban

Quand on parle de dé­ve­lop­pe­ment agile, cela évoque gé­né­ra­le­ment la méthode du scrum, mais il ne s’agit pas de la seule façon possible d’appliquer la notion de gestion de projet agile au sein de votre en­tre­prise. Le kanban est une autre méthode qui connaît un grand succès dans beaucoup de secteurs. Mais qu’en est-il de votre en­tre­prise : le kanban est-il adapté aux besoins de votre activité ou de vos projets ? Pour le savoir, nous allons vous expliquer comment cette méthode fonc­tionne.

À l’origine, le kanban nous vient du Japon. C’est Toyota qui a développé ce système dès 1947 pour répondre à ses propres besoins. Cela explique son nom, né du rap­pro­che­ment des deux mots japonais kan et ban pour signifier quelque chose comme « carte de sig­na­li­sa­tion ». Chez Toyota, le kanban a permis d’améliorer les flux de matériaux. L’objectif du cons­truc­teur au­to­mo­bile était d’éviter les goulots d’étran­gle­ment dans la ligne de pro­duc­tion et l’ac­cu­mu­la­tion de stocks de matériaux de pro­duc­tion. En lo­gis­tique, on parle dans ce cas de méthode des flux tendus, qui consiste à ne procéder à un ap­pro­vi­sion­ne­ment que lorsque le stock s’amenuise.

Par la suite, la méthode s’est imposée dans le domaine du dé­ve­lop­pe­ment logiciel. Chez Microsoft comme chez Corbis (autre en­tre­prise créée par Bill Gates), l’idée de dé­ve­lop­pe­ment lean empruntée à l’industrie au­to­mo­bile a été adaptée à cet effet dans les années 2000. Il ne s’agissait plus dès lors de gérer des matériaux de pro­duc­tion mais d’appliquer la méthode des flux tendus à des tâches. Le principe est simple : une équipe ne peut puiser une nouvelle tâche dans le backlog qu’une fois que ses tâches en cours sont achevées. Cela permet en outre d’améliorer la fluidité des processus dans de nombreux autres domaines.

Au sein d’une équipe donnée, on utilise le kanban à la fois pour améliorer ses processus de travail et augmenter sa pro­duc­ti­vité et la qualité du produit fini. Le kanban fait partie des méthodes dites « agiles » ; à ce titre, il permet de rendre les processus de travail beaucoup plus flexibles. Les tâches sont divisées en petites étapes à traiter les unes à la suite des autres. C’est pour cette raison qu’on associe souvent au kanban le slogan anglais suivant : « Stop starting, start finishing! ». Plutôt que de commencer à tra­vail­ler plus ou moins en parallèle sur plusieurs tâches en mode mul­ti­tâche, cette méthode exige que chaque étape soit achevée avant qu’il ne soit possible de se consacrer à une nouvelle.

Il s’agit d’un système auquel il est très facile de s’adapter. En effet, con­trai­re­ment à d’autres méthodes exis­tantes, le kanban s’intègre fa­ci­le­ment à des con­fi­gu­ra­tions exis­tantes. C’est une ca­rac­té­ris­tique qui lui permet en outre d’être très ouvert, puisqu’il est possible d’appliquer pa­ral­lè­le­ment au kanban d’autres méthodes, telles que le scrum.

Cependant, on constate gé­né­ra­le­ment dans la vie pro­fes­sion­nelle qu’il existe des tâches plus im­por­tantes que d’autres. Pour rendre cette hié­rar­chie des tâches visible sur le tableau kanban, on insère ce qu’on appelle des couloirs, ou « swimlanes ». Il s'agit de lignes ho­ri­zon­tales qui sub­di­vi­sent la colonne d’en-cours. Par exemple, l’équipe peut insérer dans la partie su­pé­rieure (appelée « fast lane », ou voie rapide) tous les processus qui doivent faire l’objet d’un trai­te­ment prio­ri­taire et noter plus bas les tâches moins urgentes. Cela permet ainsi à chaque membre de l’équipe de vi­sua­li­ser en un seul coup d’œil les priorités du moment.

Ce mode de re­pré­sen­ta­tion assure de façon très simple une véritable trans­pa­rence du travail. Cependant, le Kanban ne permet pas seulement de vi­sua­li­ser les processus, mais aussi de limiter les tâches. Avant de commencer à utiliser le Kanban dans la pro­duc­tion, on détermine combien de tâches il est possible de traiter en parallèle. Bien sûr, aucune res­tric­tion n’est imposée aux deux colonnes ex­té­rieures. En revanche, les colonnes in­ter­mé­diaires possèdent chacune une valeur maximale qui lui est propre. Ainsi, une équipe ne peut traiter en même temps que deux cartes pour une étape donnée, car selon les spé­cia­listes du Kanban, le travail en mul­ti­tâche tend à générer des retards dans les processus et les li­vrai­sons.

Con­trai­re­ment aux méthodes clas­siques, au titre des­quelles on passe di­rec­te­ment d’une étape à la suivante, le kanban suit la méthode des flux tendus. La tâche est ainsi « étirée ». Ce n’est qu’une fois que l’équipe dispose dans cette colonne d’une capacité de trai­te­ment suf­fi­sante que les col­la­bo­ra­teurs peuvent extraire une nouvelle tâche de la colonne de gauche. Cela implique aussi une sub­di­vi­sion verticale des colonnes : côté gauche, les tâches en cours de trai­te­ment ; côté droit, les tâches qui peuvent être trans­fé­rées vers la colonne suivante.

Cette li­mi­ta­tion garantit en outre une ré­par­ti­tion plus efficace des capacités de travail. Sans cela, une tâche à effectuer en plusieurs étapes pourrait entraîner des blocages avant d’être achevée. Si le premier poste devait avancer trop vite, au point d’entraîner un blocage à l’étape suivante, les col­la­bo­ra­teurs en charge du premier poste ne pour­raient pas continuer à tra­vail­ler en con­for­mité avec le kanban. Pour éviter cela, ils utilisent les capacités ainsi libérées afin d’aider le deuxième poste à résoudre le problème constaté.

Outre cette li­mi­ta­tion imposée aux tâches si­mul­ta­nées, d’autres règles peuvent aussi être re­pré­sen­tées de façon claire et nette sur un tableau kanban. Par exemple, la règle qui détermine à quel moment il est possible de con­si­dé­rer une tâche comme achevée et donc prête à être transmise au poste suivant. Il doit en outre ap­pa­raître clai­re­ment que ces règles sont variables. Un processus agile doit également être capable d’analyser les règles et de les faire évoluer.

Pour améliorer à long terme les processus de travail, il est important d'échan­ger des retours d’ex­pé­rience (« feedbacks »). C’est pour cela que le kanban prévoit l’or­ga­ni­sa­tion de réunions ré­gu­lières (des « cadences »), sans toutefois imposer de normes précises quant à leur fréquence. Le pionnier oc­ci­den­tal du kanban, David J. Anderson, fait quelques pro­po­si­tions à cet effet : une réunion kanban par jour (de façon similaire au scrum quotidien), dif­fé­rents passages en revue thé­ma­tiques et d’autres réunions.

Les échanges entre collègues per­met­tent de con­tri­buer à la com­pré­hen­sion générale du kanban : Il s’agit toujours, en dernière analyse, d’améliorer les processus de travail et le produit. En s’appuyant sur le réel, l’équipe doit intégrer petit à petit des amé­lio­ra­tions plutôt que d’imposer un grand bou­le­ver­se­ment. Cette approche est souvent comparée avec la phi­lo­so­phie japonaise du kaizen. Cette théorie, qui trouve ses ap­pli­ca­tions prin­ci­pales dans la gestion d’en­tre­prise, met en avant la notion d’amé­lio­ra­tion continue (kaizen est un terme japonais sig­ni­fiant « chan­ge­ment pour le mieux »). La théorie ne s’appuie cependant pas sur un objectif final à réaliser. Le kaizen prévoit qu’il est toujours possible de mettre en œuvre d’autres mo­di­fi­ca­tions.

Au total, on distingue six pratiques dif­fé­rentes dans le cadre du Kanban :

1. Vi­sua­li­sa­tion : le tableau kanban est une vi­sua­li­sa­tion du dé­rou­le­ment du travail. L’or­ga­ni­sa­tion elle-même reste toutefois re­la­ti­ve­ment ouverte. Seul élément crucial : les dif­fé­rents postes doivent être clai­re­ment définis et chaque colonne doit afficher sa limite.
2. Li­mi­ta­tion : chaque colonne présente un nombre maximal de tâches possibles. Ce n’est qu’une fois une carte de tâche trans­fé­rée vers la colonne de droite que l'équipe peut prendre une nouvelle carte dans la colonne de gauche. Cela conduit iné­vi­ta­ble­ment à un processus de travail plus efficace.
3. Gestion : tout processus de travail peut aboutir à un moment donné à un blocage ou à un goulot d’étran­gle­ment. Dans de telles si­tua­tions, il est né­ces­saire que l’équipe se concentre sur la ré­so­lu­tion de ces problèmes. En outre, l’ob­ser­va­tion des processus de travail peut permettre de répartir cor­rec­te­ment les capacités de travail pour éviter ce genre de situation.
4. Gé­né­ra­tion de règles : des règles de processus ex­pli­cites sont conçues pour rendre les processus de travail plus clairs et trans­pa­rents. Par exemple, la dé­ter­mi­na­tion des limites fait partie de ces règles, mais il s’agit également de la dé­fi­ni­tion du moment à partir duquel une tâche est con­si­dé­rée comme achevée. Les règles de processus doivent aussi cons­ti­tuer une partie visible et évolutive du tableau Kanban.
5. Retours d’ex­pé­rience : les retours d’ex­pé­rience sont une part in­dis­pen­sable du processus de travail, dans la mesure où ils cons­ti­tuent l’unique façon de l’améliorer. C'est pourquoi la méthode prévoit l’or­ga­ni­sa­tion de réunions ré­gu­lières appelées cadences. Cependant, à la dif­fé­rence du scrum, le kanban ne fixe pas de cadre rigide pour l’or­ga­ni­sa­tion de ces réunions.
6. Kaizen : le kanban doit permettre d'amé­lio­rer en continu les processus de l’équipe. La théorie part en effet du principe qu'il n’est pas possible d'at­teindre une situation optimale, mais seulement de tra­vail­ler de façon durable en con­ti­nuant à mettre en œuvre des amé­lio­ra­tions.

Le kanban s’intègre fa­ci­le­ment à toute structure d’équipe. Certaines en­tre­prises tra­vail­lent d’ailleurs pro­ba­ble­ment sans le savoir avec une version allégée du kanban. La gestion à flux tendus est une technique qui pri­vi­lé­gie la clarté, et c’est aussi le cas de la vi­sua­li­sa­tion sur un tableau kanban, avec la trans­pa­rence des processus et la li­mi­ta­tion claire du trai­te­ment mul­ti­tâche que cela implique, qui suivent une logique très claire.

Le kanban ne doit pas seulement son succès à sa facilité d’uti­li­sa­tion pour les équipes, mais aussi à sa mise en œuvre simple. La barrière à l’entrée est très faible : les mo­di­fi­ca­tions initiales à effectuer par l’équipe ou l’en­tre­prise con­cer­nées en vue de la trans­po­si­tion du Kanban sont peu nom­breuses. Cela nécessite prin­ci­pa­le­ment de disposer d’un tableau kanban qu’il est possible d’adapter au fur et à mesure et impose de prendre clai­re­ment la décision d’appliquer la méthode des flux tendus. C’est l’équipe elle-même qui peut et doit dé­ter­mi­ner toutes les amé­lio­ra­tions à mettre en œuvre. Quelles règles de processus devons-nous fixer ? Quelles limites plaçons-nous ? Sous quelle forme réalisons-nous notre tableau kanban ?

En outre, le kanban est d’une manière générale un système très ouvert qui n’impose presque pas de règles. Il n’y a ni ca­len­drier imposé, ni rôles spé­ci­fiques, con­trai­re­ment à ce qu’on retrouve par exemple dans la méthode du scrum. C’est ce qui permet au kanban d’être ap­pli­cable dans presque toutes les si­tua­tions. Cela vaut pour les équipes de toutes tailles. Même des par­ti­cu­liers peuvent améliorer leur propre processus de travail grâce au kanban.

• Petites équipes : des petits groupes de col­la­bo­ra­teurs s’or­ga­ni­sent d’ailleurs souvent après des pré­sen­ta­tions agiles. Pour donner plus de structure aux processus de travail et augmenter ainsi leur ef­fi­ca­cité, il est possible d’intégrer un kanban très simple.
• Grandes en­tre­prises : pour les grandes en­tre­prises qui existent depuis longtemps, il est beaucoup plus difficile d’adopter de nouveaux processus. C’est pré­ci­sé­ment là que le kanban a tout son intérêt. Cette méthode légère et ouverte peut être intégrée petit à petit.
• Par­ti­cu­liers : peu importe qu’on soit créateur d’en­tre­prise ou tra­vail­leur in­dé­pen­dant : le kanban aide aussi les par­ti­cu­liers à organiser leurs tâches.

L’ordre de grandeur de la mise en œuvre du kanban dans une en­tre­prise peut être déterminé par la re­pré­sen­ta­tion de ce qu'on appelle des Flight Levels. Autre pionnier du kanban, Klaus Leopold définit clai­re­ment les trois étapes au niveau des­quelles le kanban peut soutenir le dé­rou­le­ment du travail.

• Flight Level 1 : niveau opé­ra­tion­nel : C’est à ce niveau, le moins élevé, que se trouve l’équipe des spé­cia­listes occupés au quotidien à produire ou à livrer le produit ou service concerné. Bien souvent, ces équipes ne sont chargées que d’une partie seulement du produit final. In­ver­se­ment, cela implique que les tâches ne leur par­vien­nent que sous forme de paquets ; elles doivent alors être sub­di­vi­sées en tâches par­tielles plus petites avant qu’il soit possible d’y tra­vail­ler. Toutefois, s’il s’avère qu’une seule équipe dans l´’en­tre­prise travaille en ap­pli­quant le kanban, cela risque d’entraîner certains problèmes auprès d’autres équipes qui mettent en œuvre une autre méthode non agile, comme la méthode en cascade.
• Flight Level 2 : coor­di­na­tion : On retrouve à ce deuxième niveau la coor­di­na­tion des équipes situées au premier niveau. Le kanban permet ici de garantir que toutes les équipes ef­fec­tuent leurs tâches dans le bon ordre et sont cons­tam­ment ali­men­tées en travail. On évite ainsi pour toutes les équipes les périodes de su­rac­ti­vité ou, au contraire, les temps morts.
• Flight Level 3 : gestion de por­te­feuille stra­té­gique : On atteint le troisième niveau lorsqu'il ne s’agit plus seulement, avec le kanban, de coor­don­ner un simple projet mais un por­te­feuille complet organisé au moyen de la méthode agile. La direction peut ainsi décider à quel moment lancer chaque projet. Cela peut permettre d’améliorer la gestion des tâches dans toute l’en­tre­prise.

Enfin, le kanban est fi­na­le­ment tellement ouvert qu’il peut fa­ci­le­ment être mis en œuvre en parallèle avec d’autres méthodes. L’as­so­cia­tion du kanban et du scrum est par­ti­cu­liè­re­ment en vogue. Le scrum est en soi un système plutôt res­tric­tif. Dans le cadre de sa mise en œuvre, une équipe se voit imposer de suivre des normes dé­tail­lées. Toutefois, dans la mesure où le kanban est au contraire très ouvert, il est facile à intégrer dans les processus normatifs du scrum.

Il existe cependant des dif­fé­rences entre les deux méthodes : là où le scrum met l’équipe au premier plan, le kanban met l’accent sur le processus de fa­bri­ca­tion et le résultat pour le client. Sur d’autres plans, les deux systèmes se com­plè­tent : les réunions obli­ga­toires à haute fréquence imposées notamment par le scrum ne sont pas du tout exigées dans le cadre du kanban, mais elles cor­res­pon­dent néanmoins à l’esprit de cette approche, fondée sur le retour d’ex­pé­rience et la ré­troac­ti­vité.

Les avantages du kanban ont déjà été mis en évidence lors de la des­crip­tion de la méthode : son in­té­gra­tion très simple, l’amé­lio­ra­tion constante du dé­rou­le­ment du travail, le ren­for­ce­ment de la trans­pa­rence. Mais il comporte également des aspects sus­cep­tibles de dissuader une équipe de l’adopter. Par exemple, il est in­dis­pen­sable que le travail soit accompli par étapes. Lorsque ce n’est pas le cas, c’est le système dans son ensemble qui n’a plus de sens.

Un autre point qui n’en fait pas né­ces­sai­re­ment le choix idéal pour toutes les équipes est lié à un de ses avantages. Les li­mi­ta­tions imposées à la colonne des en-cours per­met­tent d’iden­ti­fier ra­pi­de­ment les problèmes survenant à un poste donné et de déplacer au besoin les capacités de travail pour les pallier. C’est toutefois possible uni­que­ment lorsqu’on peut également déplacer réel­le­ment les capacités de travail. Les membres de l’équipe doivent ainsi être en mesure de tra­vail­ler à dif­fé­rents postes. Dans le cas contraire, on parvient ra­pi­de­ment à une impasse, avec une situation où certains col­la­bo­ra­teurs se re­trou­vent débordés et d'autres n’ont rien à faire, soit très exac­te­ment le contraire de l’objectif visé par le kanban.