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.
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.