Limiter le travail en cours est la pratique Kanban que tout le monde connait. Elle est aussi celle que les équipes adoptent en premier lorsqu’elles installent un tableau, parce qu’elle est visible, concrète et immédiatement efficace. Pourtant, les équipes qui s’arrêtent là constatent souvent un plafonnement de leurs résultats. La limite WIP (Work In Progress, nombre maximal d’éléments autorisés simultanément dans une étape du processus) est un mécanisme nécessaire, mais il ne fonctionne pleinement que lorsqu’il est soutenu par quatre autres pratiques complémentaires.
Le Kanban Guide for Scrum Teams, publié par scrum.org, identifie ces pratiques comme les piliers d’un flux de travail sain. Daniel Vacanti et Steve Porter, deux figures de la communauté Professional Scrum with Kanban (PSK), ont validé leur impact à travers une série de simulations menées avec environ 90 équipes. Leurs résultats montrent que la combinaison de ces pratiques réduit les temps de traversée bien au-delà de ce que la seule limitation du WIP permet d’obtenir.
Définir le workflow et ses politiques explicites
La première pratique consiste à formaliser le fonctionnement réel du flux de travail, au-delà du simple tracé de colonnes sur un tableau. Il s’agit de rendre explicites les règles qui gouvernent le passage du travail d’un état à un autre: conditions d’entrée dans la colonne “En cours”, traitement des éléments bloqués, possibilité ou non de démarrer un nouvel élément quand un autre est en attente de validation. Sans réponse formalisée à ces questions, chaque membre interprète le flux à sa manière, ce qui génère des goulots d’étranglement invisibles.
Un simple accord d’équipe, inscrit directement sur le tableau, suffit: “Aucun élément ne peut passer de ‘À faire’ à ‘En cours’ sans que quelqu’un s’y engage nommément” ou “Un élément ne peut pas traverser deux colonnes en une seule journée.” Ces règles paraissent élémentaires, mais leur absence est la source de la majorité des dysfonctionnements du flux.
Gérer activement l’âge des éléments en cours
Poser une limite WIP empêche l’accumulation excessive de travail, mais ne garantit pas que les éléments en cours progressent effectivement. Un élément peut rester dans la colonne “En cours” pendant des jours sans que personne ne s’en préoccupe, tant que la limite globale n’est pas atteinte.
La gestion active de l’âge des éléments (work item age, temps écoulé depuis qu’un élément est “en cours”) consiste à surveiller la durée de traitement de chaque élément et à intervenir lorsqu’il dépasse un seuil acceptable. Les simulations de Vacanti et Porter ont montré que les équipes les plus performantes appliquaient une politique explicite: lorsqu’un élément dépasse quatre jours en cours, il est traité en priorité par l’ensemble de l’équipe, même si cela implique de suspendre temporairement un autre travail.
Cette approche, appelée swarming (convergence collective sur un élément bloqué), transforme la limite WIP d’un simple plafond numérique en un véritable mécanisme de gestion du flux. L’objectif n’est pas seulement de limiter ce qui entre dans le système, mais de s’assurer que ce qui y entre en sort rapidement.
Pourquoi mesurer quatre métriques et pas une seule?
Un flux ne peut être amélioré que s’il est mesuré. Le Kanban Guide for Scrum Teams identifie quatre métriques minimales que toute équipe utilisant Kanban devrait suivre, reliées entre elles par la loi de Little.
Le WIP indique la charge actuelle du système. Le cycle time (temps de traversée) mesure le temps écoulé entre le début et la fin du traitement d’un élément. Le work item age (âge de l’élément) fournit une information en temps réel sur les éléments actuellement dans le flux, permettant de repérer ceux qui stagnent avant qu’ils ne deviennent des problèmes. Le throughput (débit) compte le nombre d’éléments terminés par unité de temps.
La loi de Little établit que le cycle time moyen est égal au WIP divisé par le throughput, à condition que le système soit stable. Cette relation explique pourquoi réduire le WIP raccourcit mécaniquement le cycle time, mais elle révèle aussi que les trois autres métriques sont indispensables pour diagnostiquer les problèmes. Un throughput en baisse avec un WIP stable signale un blocage en aval. Un work item age élevé sur certains éléments, alors que le cycle time moyen reste acceptable, révèle une distribution inégale du travail au sein de l’équipe.
Inspecter et adapter le workflow en continu
La quatrième pratique ferme la boucle: il ne suffit pas de définir des politiques et de mesurer le flux, il faut régulièrement remettre en question les règles établies à la lumière des données collectées.
Les rétrospectives sont le moment naturel pour cette inspection dans une équipe Scrum. En contexte PSK, Vacanti et Porter recommandent d’y intégrer une approche inspirée du Toyota Kata de Mike Rother: définir un état cible, observer l’état actuel, identifier le prochain obstacle et mener une seule expérimentation à la fois. Cette discipline évite de modifier plusieurs paramètres simultanément sans jamais savoir lequel a produit l’effet observé.
Les résultats des simulations confirment l’importance de cette rigueur: les équipes qui ont adopté une approche systématique, en ne changeant qu’une politique à la fois et en mesurant l’impact, ont obtenu des améliorations durables, tandis que celles qui ont tenté de tout optimiser en même temps ont souvent dégradé leur flux.
Le calibrage: un point de départ empirique
Les simulations ont également précisé un point souvent débattu: le niveau optimal de la limite WIP. Les données convergent vers un ratio de deux tiers à trois quarts du nombre de membres de l’équipe de développement. Pour une équipe de six personnes, cela représente quatre à cinq éléments en cours simultanément.
Ce ratio n’est pas une règle universelle, mais un point de départ que chaque équipe doit ensuite ajuster selon son contexte, ses dépendances externes et la nature de son travail, en appliquant précisément la quatrième pratique: inspecter, expérimenter, adapter.