Les équipes qui adoptent Scrum découvrent souvent un paradoxe: le cadre fournit un rythme clair (sprint, revue, rétrospective), mais il reste muet sur la façon de gérer le flux de travail à l’intérieur de chaque sprint. C’est précisément là que Kanban entre en jeu, non pas comme une alternative, mais comme un ensemble de pratiques qui viennent combler ce que Scrum laisse volontairement ouvert.
Le malentendu sur la nature de Kanban
Kanban n’est pas un cadre méthodologique au même titre que Scrum. Le terme désigne un système de gestion visuelle du flux de travail, inventé chez Toyota dans les années 1950 pour piloter la production automobile. Appliqué au travail intellectuel depuis les années 2000, Kanban repose sur quelques principes simples: rendre le travail visible, limiter le travail en cours et mesurer le débit. Il n’impose ni rôles, ni cérémonies, ni itérations fixes.
Scrum, de son côté, structure le travail autour de sprints, de rôles définis (Product Owner, Scrum Master, développeurs) et d’événements réguliers. Les deux opèrent à des niveaux différents, ce qui les rend naturellement complémentaires plutôt que concurrents.
Visualiser le travail pour mieux piloter le sprint
La première contribution concrète de Kanban à une équipe Scrum est le tableau visuel. Un tableau Kanban typique découpe le flux en colonnes (à faire, en cours, en revue, terminé) et matérialise chaque élément de travail par une carte. Cette visualisation, que le Scrum Guide ne prescrit pas explicitement, permet à l’équipe de repérer en un coup d’œil les goulets d’étranglement, les tâches bloquées ou les files d’attente qui s’allongent.
En pratique, la plupart des équipes Scrum affichent déjà un tableau de ce type, mais l’utilisent mal. Les colonnes restent trop larges (“en cours” regroupe des tâches en développement, en test et en attente de validation sans distinction), aucune politique explicite ne définit quand une carte passe d’une colonne à la suivante, et le tableau n’est mis à jour qu’au moment du daily scrum plutôt qu’en temps réel. Une tâche bloquée depuis trois jours ne porte aucun signal visuel qui la distingue d’une tâche démarrée le matin même. L’apport de Kanban n’est donc pas le tableau en soi, mais la discipline de le structurer avec des règles claires et de s’en servir comme outil de pilotage continu.
Limiter le travail en cours pour accélérer les livraisons
La deuxième pratique, et probablement la plus transformatrice, est la limite d’encours (WIP limit, pour Work In Progress). Le principe est simple: fixer un nombre maximal de tâches autorisées simultanément dans chaque colonne du tableau. Si la colonne “en cours” est limitée à trois éléments et qu’elle est pleine, personne ne peut démarrer une nouvelle tâche tant qu’une des trois n’est pas terminée.
Cette contrainte volontaire produit un effet contre-intuitif: en interdisant de tout commencer en même temps, elle accélère le débit global. La loi de Little, un théorème mathématique validé empiriquement, établit que le temps de traversée moyen d’un système est proportionnel au nombre d’éléments en cours et inversement proportionnel au débit de sortie. En termes concrets, si une équipe travaille simultanément sur huit éléments du sprint backlog mais n’en termine que deux par jour, le temps moyen de traversée est de quatre jours; en réduisant l’encours à quatre éléments, ce temps tombe à deux jours, à débit constant. Réduire l’encours réduit mécaniquement le délai de livraison.
Pour une équipe Scrum, cela signifie qu’au lieu de répartir le sprint backlog entre tous les membres dès le premier jour, l’équipe se concentre sur un nombre restreint d’éléments et les termine avant d’en commencer d’autres, ce qui réduit les contextes simultanés, diminue le nombre de tâches “presque finies” en fin de sprint et améliore le taux de complétion.
Mesurer le flux pour anticiper plutôt que réagir
Kanban introduit trois métriques de flux que Scrum ne fournit pas nativement. Le cycle time mesure le temps écoulé entre le début du travail sur un élément et sa complétion. Le throughput compte le nombre d’éléments terminés par unité de temps. Le lead time mesure le délai total entre la demande initiale et la livraison.
Ces métriques permettent à l’équipe de dépasser la vélocité (nombre de story points livrés par sprint), une mesure souvent critiquée pour son caractère subjectif et difficilement comparable d’un sprint à l’autre. Daniel Vacanti, dans son ouvrage Actionable Agile Metrics for Predictability, démontre que les métriques de flux offrent une base statistique plus fiable pour les prévisions de livraison.
En combinant ces données avec les rétrospectives Scrum, l’équipe dispose d’un double levier d’amélioration: les métriques signalent les problèmes, la rétrospective cherche les causes et définit les actions correctives.
Pourquoi l’intégration doit rester délibérée
L’Agile Alliance met en garde contre les hybrides non réfléchis. Adopter quelques pratiques Kanban sans comprendre pourquoi revient souvent à abandonner les éléments de Scrum qui semblent contraignants (les rétrospectives, le sprint planning) tout en conservant ceux qui paraissent faciles. Le résultat est un processus affaibli, ni Scrum ni Kanban, qui perd les bénéfices des deux.
L’intégration réussie préserve l’intégrité du cadre Scrum, ses rôles, ses événements, son engagement itératif et y superpose les pratiques Kanban de visualisation, de limitation d’encours et de mesure du flux. Les sprints restent le cadre temporel, mais l’intérieur du sprint est piloté par le flux plutôt que par l’intuition.
Au-delà du logiciel
L’origine industrielle de Kanban rappelle que ces pratiques ne sont pas réservées au développement logiciel. Un bureau de gestion de projet (PMO) qui gère un portefeuille de projets, une équipe RH qui traite des recrutements ou un service juridique qui suit des contrats peuvent tous bénéficier de la visualisation du flux et de la limitation d’encours. Lorsque le volume de travail dépasse la capacité de l’équipe, rendre visible la surcharge est déjà un premier pas vers sa résolution, et combiner cette visibilité avec un cadre structuré comme Scrum donne aux équipes les moyens concrets de transformer le constat en amélioration continue.