Comment fonctionne Kanban
Auteur : Amr Noaman Abdel-Hamid
Source : How Kanban Works
Date : 31/07/2014
Traducteur : Fabrice Aimetti
Date : 07/08/2025
Traduction :
Récemment, Kanban a suscité un intérêt croissant en tant que méthode simple et efficace pour gérer le développement logiciel et l'amélioration continue. Mais comment (ou peut-être pourquoi) Kanban fonctionne-t-il ? Est-ce parce qu'il expose le système et permet un suivi visuel des demandes ? Ou parce qu'il limite les travaux en cours (“'work-on-process”') et réduit le gaspillage dû aux bascules de tâches (task switching) ? Ou peut-être est-ce dû au feedback fréquent et précis qu'il fournit aux managers par le biais de mesures simples telles que le temps de cycle (“'cycle time”') et le débit ("throughput") ? Dans cet article, nous entrerons dans les détails et étudierons Kanban à la lumière de la théorie des files d'attente et de la loi de Little. En outre, à l'aide d'études de cas, nous illustrerons trois problèmes typiques auxquels sont confrontés les managers de systèmes de développement Kanban, ainsi que la manière de les résoudre. Nous découvrirons ainsi quelques concepts de base et des idées intéressantes sur le fonctionnement de Kanban.
La loi de Little dans les systèmes logiciels
La loi de Little (du nom de John Little) est l'une des idées sur lesquelles repose le système Kanban. Dans le domaine du développement de logiciels, la loi de Little s'énonce de la manière suivante :
WIP = Th * CT où WIP (Work In Process) = quantité moyenne d'éléments inachevés (bugs, user stories, change requests, etc) dans le système de développement. Th (Débit / Throughput) = production de l'équipe en unité de temps CT (Temps de Cycle / Cycle Time) = Temps moyen nécessaire à l'équipe pour terminer un élément.
La dynamique de la loi de Little est surprenant. Elle explique de nombreuses difficultés liées au développement de logiciels et nous incite à trouver des solutions. Pour analyser la dynamique des prochaines études de cas, nous utiliserons les diagrammes d'effets, un excellent outil pour analyser les systèmes non linéaires ou les systèmes ayant plus de deux effets ou influences affectant le comportement du système.
Cas 1 : Augmenter le débit de l'équipe
Adam est le coach d'une équipe de deux développeurs et d'un testeur chargés de la maintenance d'un grand nombre de produits dans l'entreprise. En 2013, l'entreprise a investi dans la commercialisation du produit et a réussi à doubler le nombre de clients. L'équipe d'Adam a commencé à recevoir un nombre croissant de demandes d'assistance. Cependant, le PDG ne souhaite pas augmenter la taille de l'équipe.
Dans ce cas, pour répondre au nombre croissant de demandes des clients, l'équipe devra augmenter son débit. Selon la loi de Little (Th = WIP / CT), pour augmenter le débit de l'équipe, il faut soit réduire le temps de cycle, soit augmenter le WIP. L'équipe ne peut pas réduire le temps de cycle parce qu'elle a une capacité fixe. La solution la plus simple est donc d'augmenter le WIP.
La question qui se pose est la suivante : l'augmentation du WIP se traduira-t-elle par une augmentation du débit ? Un WIP plus important augmentera le débit jusqu'à une certaine limite, après quoi le débit commencera à diminuer, comme le montre le graphique suivant :
Relation entre le Débit et le WIP
Comme le montre le graphique suivant, l'augmentation du WIP incitera l'équipe à optimiser son travail et à éliminer les gaspillages de son processus de production (zone jaune) jusqu'à ce que l'équipe atteigne le débit maximal possible (pic vert). Après cela, l'augmentation du WIP peut ne pas entraîner d'amélioration supplémentaire ; au contraire, elle peut diminuer le débit de l'équipe en raison du stress et des bascules de tâches (zone rouge).
Réponse de l'équipe à l'augmentation du WIP en fonction de la quantité de WIP
Dans la zone rouge, l'équipe est submergée par des facteurs externes et connaît des problèmes internes qui diminuent sa productivité. Le diagramme d'effets qui suit analyse la dynamique de l'équipe dans la zone rouge :
L'augmentation du WIP au-delà de la capacité de l'équipe réduira la productivité et le débit de l'équipe.
Ce diagramme montre l'effet de l'augmentation du WIP au-delà de la capacité de l'équipe. Cela augmentera la communication avec les clients, les bascules de tâches et le stress. Travailler dans le stress et passer d'une tâche à l'autre peut entraîner un plus grand nombre de bugs et finira par diminuer la productivité, ce qui, à son tour, diminuera le débit.
Pour comprendre l'impact de cette décision, le diagramme suivant modélise l'effet de renforcement : l'augmentation du WIP entraîne une baisse de productivité qui, à son tour, accumule les demandes et augmente le WIP, et ainsi de suite. Le système continuera à tourner en boucle et le débit continuera à diminuer jusqu'à ce que l'équipe se retrouve bloquée !
L'augmentation du WIP au-delà de la capacité de l'équipe peut provoquer deux boucles de renforcement. Dans cette dynamique, le WIP continuera d'augmenter jusqu'à ce que le système de développement se bloque !
Remarque : deux effets négatifs consécutifs = effet positif
En résumé, si vos capacités sont fixes et que vous souhaitez augmenter le débit, vous pouvez augmenter à la fois la taille de l'équipe et le WIP. Si cela n'est pas possible, il ne vous reste qu'une seule autre option : réduire le temps de cycle, ce qui revient à découvrir et à éliminer les gaspillages.
Cas 2 : Stabiliser le temps de cycle
Ismail est le responsable du développement qui s'est engagé à fournir des modifications aux clients dans un délai spécifié dans un contrat de niveau de service (SLA). Ismail et son équipe sont confrontés à des taux d'entrée fluctuants des demandes des clients. Parfois, elles sont plus nombreuses que d'habitude, ce qui fait que le temps de cycle dépasse leur SLA, et d'autres fois, le taux est faible et ne consomme pas toute leur capacité. Le diagramme suivant explique pourquoi le temps de cycle augmente en raison de taux d'entrée plus élevés :
Des taux d'entrée plus élevés se traduisent par des temps de cycle plus importants. De même, des taux d'entrée plus faibles entraînent des temps de cycle plus courts, conformément à la loi de Little.
Pour stabiliser le temps de cycle, la loi de Little implique que le temps de cycle CT est directement proportionnel au WIP et inversement proportionnel au débit. Par conséquent, si Ismail pouvait stabiliser ces deux paramètres, le temps de cycle se stabiliserait en conséquence.
Pour ce faire, Ismail doit contrôler à la fois le WIP et la capacité de l'équipe (le nombre de membres de l'équipe ou le pourcentage du temps de l'équipe consacré au traitement des demandes des clients) afin de répondre à des taux d'entrée plus ou moins élevés. Ces deux paramètres ont un double effet sur le temps de cycle : l'augmentation du WIP augmentera le temps de cycle, tandis que l'augmentation de la capacité de l'équipe le diminuera. Les deux effets s'annulent donc :
Si les responsables peuvent augmenter/diminuer le WIP et la capacité de l'équipe, ils peuvent stabiliser le temps de cycle et optimiser l'utilisation et la performance de l'équipe.
En résumé, si l'équipe est confrontée à des taux d'entrée fluctuants, elle doit contrôler deux paramètres : les limites de WIP et la capacité de l'équipe. En contrôlant ces deux paramètres, l'équipe peut stabiliser le temps de cycle et optimiser l'utilisation de l'équipe.
Cas 3 - Ne pas trop accélérer / Expedite !
Accélérer le travail (en utilisant une voie prioritaire dans votre tableau Kanban) peut être une solution facile pour les rapports de problèmes récurrents et les demandes de service problématiques, en particulier avec les clients mécontents. Dans de nombreux cas, il est tentant d'accélérer le travail sans aucune règle, juste pour répondre à des cas particuliers ou à des plaintes virulentes de clients.
La voie d'accélération consommera une partie du temps et des efforts de l'équipe, ralentira le développement et augmentera le temps de cycle moyen. Selon la loi de Little, cela réduira effectivement le débit de l'équipe :
Selon la loi de Little, si le WIP est fixe, plus le temps de cycle est élevé, plus le débit sera faible.
En réalité, la relation linéaire entre le temps de cycle et le débit se modifie également, comme suit :
Le débit est considérablement réduit en raison de deux facteurs : l'augmentation du temps de cycle et le glissement du graphique définissant la relation entre Th et CT.
Dans les cas les plus extrêmes, les équipes peuvent basculer sur les tâches de la voie d'accélération et commencer à les traiter instantanément à la demande et laisser toutes les autres tâches à l'état en cours. Le changement de contexte instantané a un impact encore plus négatif sur le débit. Le diagramme suivant explique cet impact :
Les éléments accélérés augmentent le temps de cycle des éléments encore en cours et ont une incidence négative sur le débit final.
Pour résumer le troisième cas, il faut se méfier du piège que représente la voie d'accélération. Elle peut avoir un effet négatif sur la productivité globale de l'équipe et entraîner une diminution du temps de cycle moyen. Bien que cela puisse être utile dans certains cas d'urgence anodins, cela peut ouvrir la porte à d'autres dynamiques négatives involontaires.
Conclusion
Dans ces trois cas, nous avons démontré le fonctionnement de Kanban à la lumière de la théorie des files d'attente. Il s'agit d'un outil de gestion très simple et très efficace. En tant que manager ou team leader, vous avez plusieurs paramètres à contrôler : le WIP et la capacité de l'équipe. Vous disposez également d'indicateurs de processus tels que le temps de cycle et le débit, que vous pouvez mesurer très facilement pour avoir un feedback régulier sur l'efficacité du processus. Dans ces trois exemples, nous avons mis en évidence trois facteurs fondamentaux dans l'utilisation de Kanban :
- Essayez d'étudier la capacité de votre équipe et de ne pas la submerger de travail supplémentaire au-delà de cette capacité. La représentation graphique du WIP par rapport au débit vous donnera une indication du WIP maximal que l'équipe peut supporter.
- Vous pouvez contrôler plus d'un paramètre pour stabiliser le processus de développement. Comme dans le deuxième cas, vous pouvez contrôler le WIP et la capacité de l'équipe afin de parvenir à un temps de cycle stable.
- Méfiez-vous du piège que représente la voie d'accélération. Il s'agit essentiellement d'une porte dérobée permettant de transgresser le processus. Si elle est utilisée sans précaution, elle peut nuire à la productivité de l'équipe.
Références
Loi de Little
Dans le chapitre de son livre expliquant la loi de Little, publié par le Massachusetts Institute of Technology, John Little explique la loi et fait le lien entre la théorie et la pratique. Il s'agit d'une excellente lecture, simple mais qui va au cœur de la loi de Little.
L'une des questions que ce chapitre du livre explique très bien est la différence entre la loi de Little dans sa formulation originale (qui considère le taux d'arrivée / Arrival Rate comme l'un des paramètres de la formule) et son application dans les systèmes de fabrication (qui remplace le taux d'arrivée par le débit). Voici une explication :
La loi de Little stipule que :
L = λ W où L = nombre moyen d'éléments dans le système de file d'attente λ = taux d'arrivée de nouveaux éléments dans le système W = temps d'attente moyen pour un élément dans le système
John Little affirme que cette loi est robuste et générique et qu'elle s'applique exactement à tout système de file d'attente, sous réserve d'une condition essentielle : "disposer d'une fenêtre d'observation finie qui commence [lorsque le système est vide] et s'arrête lorsque le système est vide" (p.88).
Comme vous pouvez le constater, cette formulation est différente de celle discutée dans l'article. En fait, il existe deux différences fondamentales entre la loi de Little dans sa formulation originale et la façon dont elle est énoncée dans le contexte du logiciel (WIP = Th*CT). La première parle de taux d'entrée ou d'arrivée, tandis que la seconde parle de taux de sortie (output rate) ou de débit. La deuxième question concerne la condition énoncée par Little : le système doit commencer avec 0 élément et finir à 0 élément. Dans le domaine des logiciels, il est rare qu'un système ne fasse l'objet d'aucune demande de maintenance.
Pour résoudre ces différences, Little a indiqué une condition plus subtile de la loi à respecter, à savoir : aucun élément ne doit entrer dans le système et se perdre ou ne pas être terminé, ce qu'il appelle la "conservation du flux" (p. 93). Si nous appliquons cette condition au système, nous pouvons facilement montrer que le taux d'entrée = le taux de sortie et, par conséquent, nous pouvons relier Lambda (λ) à throughout (th).
Pour la deuxième condition (le système doit commencer et se terminer par 0 élément), Little affirme que la loi "s'applique toujours, au moins en tant qu'approximation, tant que nous choisissons un intervalle de temps suffisamment long". (p. 93)
Diagramme d'Effets
Les diagrammes d'effets ont été introduits pour la première fois dans la célèbre série en quatre volumes "Quality Software Management" de Gerald Weinberg. Il s'agit d'un outil très utile pour comprendre la dynamique d'un système présentant un comportement non linéaire, très similaire aux systèmes des équipes de développement de logiciels.
Les diagrammes d'effets sont similaires aux diagrammes de boucles causales (Causal Loop Diagrams - CLD), mais leur notation est légèrement différente et ils sont plus puissants pour modéliser les interventions humaines dans le système. Un diagramme d'effets se compose principalement de nœuds et de flèches. Chaque nœud correspond à une quantité mesurable. Une flèche simple correspond à un effet (positif ou négatif) que le nœud source exerce sur le nœud cible. Vous trouverez sur ce lien un manuel complet sur la manière de dessiner et d'utiliser les diagrammes d'effets (fr).