Un sprint bien planifié ne garantit pas un sprint fluide. L’équipe s’engage sur un ensemble d’éléments, le Sprint Backlog est clair, les objectifs sont définis, et pourtant, à mi-sprint, trois tâches stagnent en attente de validation pendant que deux personnes démarrent de nouveaux éléments faute de visibilité sur les blocages. Ce scénario est si courant qu’il révèle une lacune structurelle: Scrum organise le travail en itérations, mais ne fournit aucun mécanisme pour gérer le flux de travail à l’intérieur de ces itérations.
C’est exactement le problème que Kanban résout. Et contrairement à une idée répandue, combiner Kanban et Scrum n’est ni une hérésie méthodologique ni un compromis bancal. Le Kanban Guide for Scrum Teams, publié en 2021 par Scrum.org en collaboration avec des praticiens Kanban, formalise cette complémentarité. Environ 25% des organisations combinent déjà les deux approches (PMI, 2024).
Ce que Scrum ne dit pas sur le flux
Scrum prescrit des rôles, des événements et des artefacts. Il définit le sprint comme unité de temps, le Product Backlog comme réservoir de travail et le Sprint Backlog comme engagement de l’équipe. Ce cadre est efficace pour structurer la planification et l’inspection, mais il laisse une zone aveugle considérable: que se passe-t-il entre le Sprint Planning et la Sprint Review?
Le framework ne dit rien sur le nombre d’éléments qu’une personne devrait traiter simultanément, sur la façon de détecter un goulot d’étranglement en cours de sprint, ni sur la manière de mesurer si le travail progresse à un rythme soutenable. Ces questions relèvent de la gestion du flux, une discipline distincte de la gestion du backlog, et c’est là que Kanban intervient.
La limite WIP: le levier le plus sous-estimé
Le WIP (Work in Progress) est le nombre d’éléments de travail commencés mais non terminés. Le sprint lui-même constitue une limite WIP implicite puisque l’équipe ne s’engage que sur un volume fini. Mais cette limite reste grossière: elle borne le total sans contraindre la distribution du travail entre les étapes.
Les limites WIP explicites opèrent à un niveau plus fin. En fixant un maximum d’éléments par colonne du tableau Kanban (par exemple, deux éléments en test à la fois), on force l’équipe à résoudre les blocages avant de démarrer du travail supplémentaire. Le résultat est contre-intuitif pour beaucoup de gestionnaires de projet: faire moins de choses en parallèle accélère la livraison globale. Les données de terrain le confirment, avec des augmentations de débit de l’ordre de 40% et des réductions de délai pouvant atteindre 60%.
Quatre métriques qui changent la conversation
La gestion du flux repose sur quatre indicateurs complémentaires: le cycle time (temps écoulé entre le début et la fin d’un élément), le throughput (nombre d’éléments livrés par unité de temps), le WIP (nombre d’éléments en cours) et le work item age (ancienneté d’un élément dans son étape actuelle).
Ces métriques sont reliées par la loi de Little, selon laquelle le temps de cycle moyen est égal au WIP moyen divisé par le débit moyen. Cette relation mathématique a une conséquence pratique directe: pour réduire le temps de cycle, il suffit de réduire le WIP, sans demander à l’équipe de travailler plus vite ou plus longtemps.
L’introduction de ces données dans les cérémonies Scrum transforme la qualité des échanges. Au Daily Scrum, plutôt que de faire un tour de table sur les activités de la veille, l’équipe peut parcourir le tableau de droite à gauche et concentrer la discussion sur les éléments dont l’ancienneté dépasse la moyenne. En rétrospective, un diagramme de flux cumulatif révèle visuellement si le système de travail est stable ou si le WIP dérive sprint après sprint. On passe de conversations fondées sur les impressions à des analyses fondées sur les faits.
Visualiser pour rendre les problèmes inévitables
Un tableau Kanban bien conçu ne se contente pas de lister les tâches du sprint. Il cartographie l’ensemble du flux de valeur, de la demande initiale à la livraison effective, en rendant explicites les files d’attente et les transferts entre étapes. Cette visualisation rend les dysfonctionnements impossibles à ignorer: quand une colonne déborde pendant que la suivante reste vide, le problème est visible par toute l’équipe sans qu’un manager ait besoin de le signaler.
La visualisation s’accompagne d’un effort de documentation des politiques de travail. Quels critères un élément doit-il remplir pour passer d’une colonne à l’autre? Qui est habilité à tirer un nouvel élément? Ces règles, souvent implicites dans les équipes Scrum classiques, gagnent à être formalisées. Elles réduisent les ambiguïtés et permettent à chaque membre de l’équipe de prendre des décisions autonomes sans attendre une validation hiérarchique.
Améliorer par l’expérimentation, pas par la réorganisation
La dernière contribution de Kanban au cadre Scrum est peut-être la plus fondamentale: une culture d’amélioration fondée sur l’expérimentation plutôt que sur les opinions. Au lieu de débattre en rétrospective sur ce qui “devrait” changer, l’équipe formule une hypothèse (“si nous réduisons la limite WIP de la colonne validation de quatre à deux, le cycle time devrait baisser”), la teste sur deux sprints et vérifie le résultat dans les données. Cette approche scientifique, inspirée de méthodes comme le Toyota Kata, produit des améliorations modestes mais vérifiables, qui s’accumulent sprint après sprint.