Kanban a la réputation d’être la méthode agile la plus simple à adopter. Pas de rôles imposés, pas de sprints, pas de cérémonies obligatoires: on prend le processus existant, on le rend visible, et on l’améliore progressivement. Cette simplicité apparente explique à la fois l’attrait de Kanban et la fréquence des implémentations qui n’aboutissent pas. Voici cinq erreurs récurrentes et comment les éviter.
Piège 1: un tableau sans limites WIP
Le premier réflexe d’une équipe qui découvre Kanban est de créer un tableau avec des colonnes (À faire, En cours, Terminé) et d’y placer ses tâches. Ce geste utile rend le travail visible, mais il ne constitue pas encore un système Kanban. La méthode repose sur un mécanisme fondamental: la limite de travail en cours (WIP, Work in Progress), qui plafonne le nombre d’éléments autorisés simultanément dans chaque colonne.
Sans limite WIP, le tableau devient un miroir de la surcharge plutôt qu’un outil pour la corriger. Vingt tickets s’accumulent dans “En cours” et personne ne termine quoi que ce soit parce que tout le monde est occupé. La limite WIP force un choix: pour commencer un nouvel élément, il faut d’abord en terminer un autre. Ce mécanisme, appelé système à flux tiré (pull system), est ce qui distingue un tableau de suivi d’un véritable système Kanban.
La difficulté pratique est de choisir les bonnes limites. Une approche courante consiste à commencer avec une limite égale au nombre de personnes dans l’étape, puis à l’ajuster en observant les effets. Une limite trop haute ne change rien; une limite trop basse crée de l’inactivité artificielle. L’objectif est de trouver le seuil qui expose les blocages sans paralyser l’équipe.
Piège 2: des colonnes qui ne reflètent pas le vrai processus
Un tableau Kanban doit représenter le flux réel du travail, pas un processus idéalisé. Beaucoup d’équipes dessinent trois colonnes génériques alors que leur processus comporte en réalité des étapes intermédiaires cruciales: attente de validation, revue par un tiers, intégration dans un livrable plus large. Quand ces étapes restent invisibles, les tickets semblent stagner sans raison apparente dans la colonne “En cours” alors qu’ils sont en réalité bloqués entre deux étapes.
La solution est de modéliser les files d’attente explicitement. Séparer “En cours” en deux sous-colonnes (“En traitement” et “En attente de validation”) rend visible le temps d’attente, qui représente souvent une part significative du délai total. Un élément dont le traitement prend deux jours mais qui attend cinq jours de validation a un cycle time de sept jours, et seule la modélisation fidèle du flux permet de l’identifier.
Piège 3: ignorer les métriques de flux
Kanban sans données n’est qu’un tableau de post-its. Trois métriques sont essentielles pour piloter un système Kanban. Le lead time mesure le délai entre la demande et la livraison. Le cycle time mesure la durée de traitement effectif une fois le travail commencé. Le débit (throughput) compte le nombre d’éléments terminés par période.
Ces métriques ne servent pas à évaluer la performance individuelle mais à diagnostiquer le système. Un lead time en augmentation régulière signale que le système absorbe plus de travail qu’il n’en produit. Un cycle time très variable indique que les éléments ne sont pas suffisamment homogènes ou que des blocages intermittents perturbent le flux.
Le Kanban Guide recommande d’utiliser ces données pour définir des Service Level Expectations (SLE): des engagements probabilistes basés sur l’historique plutôt que sur des estimations individuelles. Par exemple: “85% de nos éléments sont livrés en moins de 12 jours ouvrés”. Cette approche remplace les promesses incertaines par des prévisions fondées sur les données.
Piège 4: pas de politiques explicites
Qui décide qu’un ticket est prioritaire? Quel est le critère pour qu’un élément passe d’une colonne à la suivante? Comment traite-t-on une demande urgente du client? Quand ces questions n’ont pas de réponse écrite et partagée, chaque décision repose sur la négociation informelle, ce qui génère des incohérences et des frustrations.
Rendre les politiques explicites est la quatrième des six pratiques Kanban formalisées par David Anderson. Un exemple concret: définir des classes de service avec des règles claires. Les éléments urgents contournent la limite WIP et sont traités en priorité. Les éléments à date fixe sont planifiés en fonction de leur échéance. Les éléments standard sont traités dans l’ordre d’arrivée. Les éléments différables sont traités quand la capacité le permet. Ces règles, affichées sur le tableau, éliminent les débats quotidiens sur “qu’est-ce qu’on fait en premier”.
Piège 5: amélioration sans cadence
Kanban prescrit peu de rituels, mais il recommande fortement des boucles de feedback régulières. La réunion Kanban quotidienne se concentre sur le flux (“quel ticket est bloqué et depuis quand”) plutôt que sur les individus (“qu’as-tu fait hier”). La revue de réapprovisionnement décide quels nouveaux éléments entrent dans le système. La rétrospective analyse les tendances des métriques et identifie des expérimentations possibles.
Sans ces cadences, l’amélioration repose sur la bonne volonté individuelle et s’essouffle rapidement. L’un des principes fondateurs de la méthode est de poursuivre l’amélioration par le changement évolutif: des ajustements fréquents, mesurables et réversibles. On réduit une limite WIP de cinq à quatre, on observe l’effet sur le cycle time pendant deux semaines, on décide de conserver ou de revenir en arrière. Cette approche par expérimentation contrôlée est ce qui donne à Kanban sa capacité d’adaptation sans rupture organisationnelle.