La question revient souvent dans les équipes qui pratiquent Scrum depuis quelques sprints: comment améliorer le flux de travail sans remettre en cause le cadre existant? La réponse que propose scrum.org depuis 2018 tient en une combinaison de quatre lettres: Kanban.
Ce que Kanban apporte à Scrum
Kanban est une stratégie d’optimisation du flux qui repose sur trois principes: visualiser le travail, limiter le travail en cours (WIP, pour Work In Progress) et mesurer le débit. Appliquées dans un contexte Scrum, ces pratiques ne remplacent rien: elles rendent visible ce qui restait implicite.
Dave West, CEO de scrum.org, résume la logique dans une interview accordée à VivifyScrum: puisque Scrum repose sur la transparence, il paraît naturel de chercher dans Kanban des moyens de mieux visualiser le travail. Le Kanban Guide for Scrum Teams, publié par scrum.org et révisé en 2021, formalise cette complémentarité. Il ne s’agit pas d’une extension du cadre Scrum mais d’un ensemble de pratiques que les équipes peuvent greffer sur leur fonctionnement existant.
Le guide identifie quatre pratiques essentielles: définir et visualiser le workflow, limiter activement le travail en cours, gérer les éléments de manière active et inspecter le flux pour l’améliorer. Chacune renforce un aspect déjà présent dans Scrum sans en modifier les rôles, événements ou artefacts.
Visualiser pour comprendre, pas pour contrôler
Le premier bénéfice de Kanban dans un contexte Scrum n’est pas l’optimisation, c’est la prise de conscience. Lorsqu’une équipe rend son flux de travail visible sur un tableau, elle découvre ce que les cérémonies Scrum seules ne révèlent pas toujours: les files d’attente entre les étapes de développement et de test, les tâches bloquées en attente de validation ou le travail commencé mais jamais terminé.
Cette visibilité pousse à reconsidérer des éléments fondamentaux du cadre. La Definition of Done, par exemple, prend un nouveau relief lorsqu’on voit concrètement où s’arrête le travail d’un développeur et où commence celui d’un testeur. Le Sprint Goal gagne en clarté quand l’équipe visualise l’ensemble des éléments qui contribuent à l’atteindre.
West insiste sur un point important: cette visibilité ne doit pas devenir un instrument de surveillance. Elle sert l’équipe elle-même, pas le management. Les processus “non écrits” et les hypothèses implicites qui régissent souvent le travail quotidien deviennent des sujets de discussion en rétrospective plutôt que des angles morts permanents.
Limiter le travail en cours: moins de parallèle, plus de débit
La limitation du WIP est probablement la pratique Kanban la plus contre-intuitive pour les équipes habituées à remplir leur Sprint Backlog au maximum. Le principe est pourtant simple, validé par la théorie des files d’attente (loi de Little): réduire le nombre d’éléments traités simultanément accélère le temps de traversée de chaque élément.
Dans un Sprint Scrum, cela se traduit par une discipline collective: l’équipe s’engage à terminer les éléments en cours avant d’en commencer de nouveaux. Cette pratique réduit le changement de contexte, diminue le risque de livrer des éléments partiellement terminés en fin de sprint et améliore la prévisibilité de l’équipe.
L’erreur classique consiste à fixer des limites WIP trop ambitieuses dès le départ. West recommande une approche progressive: commencer simplement, expérimenter, garder ce qui fonctionne. Les métriques avancées comme les diagrammes de flux cumulatif peuvent venir plus tard, une fois que les pratiques de base sont intégrées.
Au-delà du Sprint: rendre visible le travail invisible
Un apport souvent sous-estimé du Kanban Guide concerne le travail qui se situe en dehors du Sprint classique. La product discovery en amont (recherche utilisateur, validation d’hypothèses, prototypage) et les activités en aval (monitoring en production, support, dette technique) échappent généralement au tableau Scrum standard.
En visualisant ces flux adjacents, l’équipe construit un pont entre Scrum et les pratiques DevOps ou Lean qui régissent souvent le reste de la chaîne de valeur. Le Product Owner gagne en visibilité sur le temps réel nécessaire entre l’identification d’un besoin et sa livraison effective, ce qui améliore la qualité de la planification.
Une évolution, pas une révolution
West positionne Scrum avec Kanban non pas comme une direction définitive mais comme un outil parmi d’autres dans la boîte à outils agile. Scrum a toujours accueilli des pratiques complémentaires: l’eXtreme Programming y a apporté le pair programming et le TDD, le Lean y a introduit la réflexion sur les gaspillages. Kanban s’inscrit dans cette même logique d’enrichissement progressif.
Cette posture rejoint un message plus large que West développe dans ses interviews récentes: ne pas devenir la “police de Scrum”. L’application rigide des règles sans compréhension de leur finalité produit rarement de bons résultats. Ce qui compte, c’est que l’équipe dispose d’outils concrets pour inspecter son travail et s’adapter, les trois piliers de l’empirisme (transparence, inspection, adaptation) sur lequel Scrum est fondé.
Pour les équipes qui cherchent un premier pas concret, le chemin le plus simple reste de cartographier leur flux de travail actuel sur un tableau et de se poser une question en rétrospective: où le travail s’accumule-t-il, et pourquoi?