La plupart des équipes Scrum utilisent un tableau visuel pour suivre leurs tâches. Quand on leur demande si elles utilisent Kanban, elles répondent oui en montrant les colonnes À faire, En cours et Terminé. Cette réponse révèle un malentendu courant: Kanban n’est pas un tableau, c’est un système de gestion du flux de travail dont le tableau n’est que la partie la plus visible. Ce que Kanban apporte réellement à une équipe Scrum va bien au-delà de la visualisation.
Deux systèmes sur des plans différents
Scrum structure le travail selon un rythme défini, avec des rôles, des événements et des moments d’inspection, tandis que Kanban optimise le flux en rendant visible la manière dont le travail circule à travers le système, où il ralentit et pourquoi. Ces deux préoccupations ne se contredisent pas, elles se complètent.
Corey Ladas a formalisé cette complémentarité en 2009 sous le nom de Scrumban. L’idée n’était pas de créer une troisième méthode, mais de reconnaître que les équipes Scrum matures finissent naturellement par s’intéresser aux dynamiques de flux. L’Agile Alliance décrit Scrumban comme une approche qui “combine les meilleures caractéristiques des deux systèmes”, une formulation prudente qui reflète bien la réalité du terrain.
Le système pull: finir avant de commencer
Le principe fondateur de Kanban est le système pull (flux tiré): un élément de travail ne progresse vers l’étape suivante que lorsque cette étape a la capacité de l’absorber. C’est l’opposé du système push classique, où chaque étape pousse son travail terminé vers la suivante sans se soucier de sa charge actuelle.
En pratique, cela se traduit par les WIP limits (limites de travail en cours): un plafond sur le nombre d’éléments simultanément présents dans chaque colonne du flux. Si la limite est atteinte, l’équipe ne tire pas de nouvel élément mais aide à débloquer ceux qui stagnent. Le mantra informel est “stop starting, start finishing”, et son effet principal est de rendre les goulots d’étranglement visibles immédiatement au lieu de les laisser s’accumuler dans l’ombre.
Pour une équipe Scrum, le WIP limit appliqué au sprint résout un problème récurrent: le sprint qui commence avec tout en parallèle et se termine dans l’urgence. En forçant l’équipe à terminer les éléments en cours avant d’en démarrer de nouveaux, le flux de livraison devient plus régulier tout au long du sprint.
La loi de Little et ses conséquences pratiques
Les quatre métriques de flux identifiées par Daniel Vacanti (Actionable Agile Metrics for Predictability, 2015) sont le WIP (travail en cours), le cycle time (temps écoulé entre le début et la fin du traitement d’un élément), le throughput (nombre d’éléments terminés par unité de temps) et le work item age (temps passé par un élément dans le système depuis qu’il a été commencé).
La loi de Little, un théorème de la théorie des files d’attente, établit que ces métriques sont interdépendantes: en régime stable, le temps de cycle moyen égale le WIP moyen divisé par le débit moyen. La conséquence est directe: si vous voulez livrer plus vite sans changer la taille de l’équipe, réduisez le nombre de choses en cours simultanément.
Cette relation mathématique éclaire un paradoxe fréquent: les équipes qui travaillent sur tout en même temps livrent lentement malgré une activité intense, parce qu’un WIP élevé allonge mécaniquement le temps de cycle, indépendamment de l’effort fourni.
Ce qui change dans les rituels quotidiens
L’intégration des pratiques de flux dans Scrum ne nécessite pas de modifier le cadre. Elle enrichit chaque événement existant avec des données concrètes.
Le sprint planning gagne en fiabilité quand l’équipe s’appuie sur son throughput historique plutôt que sur la vélocité en story points. Prenons une équipe dont la vélocité oscille entre 35 et 55 points d’un sprint à l’autre: l’écart reflète moins une variation réelle de capacité que l’inconsistance de l’estimation en points, où un “5” en janvier ne vaut pas toujours un “5” en mars. Si cette même équipe mesure son throughput et constate un débit moyen de 14 éléments terminés par sprint avec un écart-type de 2, la prévision pour le prochain sprint repose sur une mesure objective plutôt que sur une unité dont la signification dérive au fil du temps.
Le daily standup se concentre sur le flux plutôt que sur le reporting individuel. Yuval Yeret recommande de surveiller le work item age: tout élément dont l’âge dépasse le 85e percentile du cycle time historique mérite une attention prioritaire, indépendamment de ce que la personne qui y travaille en pense.
La rétrospective dispose de données exploitables au lieu de reposer sur des impressions. Le cycle time par type d’élément, la distribution du throughput et l’évolution du WIP moyen sur plusieurs sprints permettent d’identifier des tendances structurelles plutôt que des anecdotes ponctuelles.
Les pièges de l’hybridation
Le risque principal est de prendre les outils de Kanban comme prétexte pour abandonner la structure de Scrum. Les sprints, avec leur cadence fixe, créent un rythme d’inspection et d’adaptation que le flux continu pur ne fournit pas naturellement. Supprimer les sprints “parce qu’on a un tableau Kanban” produit généralement un environnement sans cadence, sans engagement collectif et sans moments formels de remise en question.
L’autre piège, symétrique, est le “faux Kanban”: un tableau visuel sans WIP limits, sans métriques et sans politique de flux explicite. Cette version cosmétique n’apporte aucun des bénéfices du système pull. Si votre colonne “En cours” peut contenir 15 éléments simultanément sans que personne ne s’en alarme, ce n’est pas du Kanban.
L’hybridation solide conserve l’intégralité des événements, rôles et artefacts de Scrum, et superpose les pratiques de flux comme une couche d’optimisation. Les WIP limits, les métriques de cycle time et le throughput ne remplacent pas le sprint review ou la rétrospective: ils leur fournissent la matière première quantitative qui transforme des discussions d’opinion en discussions factuelles.