Les équipes qui pratiquent Kanban finissent parfois par constater un paradoxe: le flux de travail est visible, les limites WIP (Work In Progress, nombre maximal de tâches simultanées) sont respectées, les tâches avancent, et pourtant quelque chose manque. La direction n’est pas claire, les parties prenantes ne savent pas quand intervenir, et l’équipe livre sans savoir si ce qu’elle livre a de la valeur.
Certains éléments de Scrum répondent directement à ces problèmes, non pas comme un remplacement de Kanban, mais comme des compléments ciblés que le flux continu seul ne fournit pas.
Le flux ne donne pas de direction
Kanban excelle dans la gestion du débit. Le tableau rend le travail visible, les limites WIP empêchent la surcharge, et les métriques de flux (lead time, throughput) permettent de mesurer la performance. Ce que Kanban ne fournit pas, c’est une intention partagée à court terme.
Le Sprint Goal de Scrum remplit cette fonction. En définissant un objectif pour une période de deux à quatre semaines, l’équipe passe du mode “traiter la file d’attente” au mode “atteindre un résultat”. Cette nuance est significative: une équipe qui tire des cartes sans objectif commun optimise son activité, pas nécessairement sa valeur.
Le Product Goal joue un rôle similaire à plus long terme. Pour une équipe Kanban habituée à traiter les demandes au fil de l’eau, se doter d’un objectif produit explicite permet de filtrer ce qui entre dans le backlog plutôt que de tout accepter.
La cadence crée des points de synchronisation
L’un des reproches fréquents adressés au sprint est son caractère artificiel: pourquoi imposer un cycle fixe quand le travail peut être livré en continu? L’argument est valable sur le plan technique, mais il ignore un aspect organisationnel important.
Les événements Scrum (Sprint Planning, Daily Scrum, Sprint Review, Retrospective) créent des rendez-vous prévisibles. La Sprint Review, par exemple, ne sert pas uniquement à montrer ce qui a été fait: elle crée un moment où les parties prenantes savent qu’elles seront entendues. Sans cette cadence, les retours arrivent de façon aléatoire, ce qui fragmente l’attention de l’équipe et dilue la qualité du feedback.
Le Daily Scrum apporte également une dimension que le simple passage devant le tableau Kanban ne garantit pas. En Kanban, la revue quotidienne se concentre naturellement sur le flux: qu’est-ce qui est bloqué, qu’est-ce qui peut avancer? Le Daily Scrum y ajoute une question d’alignement: ce que nous faisons aujourd’hui nous rapproche-t-il de l’objectif du sprint?
Le Product Owner clarifie les arbitrages
Dans de nombreuses équipes Kanban, la priorisation reste floue. Les demandes arrivent de plusieurs sources, et l’équipe les traite selon un ordre qui mélange urgence perçue, ancienneté dans la file et préférences implicites. Le rôle de Product Owner, tel que défini par Scrum, concentre cette responsabilité sur une seule personne.
Ce n’est pas une question de pouvoir hiérarchique. Le Product Owner apporte trois clarifications que Kanban ne structure pas: quelles demandes refuser, dans quel ordre traiter celles qui restent, et comment arbitrer quand deux parties prenantes ont des priorités contradictoires. Pour une équipe Kanban confrontée à une file d’attente qui ne cesse de croître, cette clarification peut transformer la dynamique de travail.
Ce qui fonctionne déjà sans Scrum
Il serait inexact de présenter Scrum comme la solution à tous les problèmes d’une équipe Kanban. Plusieurs pratiques sont déjà présentes ou facilement adoptables sans changer de framework.
Les rétrospectives, par exemple, existent dans la plupart des équipes Kanban matures. Le Scrum Guide prescrit un format et une cadence, mais le principe d’amélioration continue est commun aux deux approches. De même, la Definition of Done (critères de qualité qu’un élément doit satisfaire avant d’être considéré comme terminé) correspond directement aux politiques explicites que Kanban recommande pour chaque colonne du tableau.
Les cinq valeurs Scrum (engagement, courage, focus, ouverture, respect) ne sont pas non plus spécifiques au framework. Une équipe Kanban qui pratique la transparence sur ses métriques et accepte de rendre visibles ses blocages incarne déjà ces principes.
Deux stratégies d’adoption
Steve Porter et Yuval Yeret, dans leur analyse croisée des deux frameworks, identifient deux approches pour une équipe Kanban qui souhaite intégrer des éléments de Scrum.
La première consiste à adopter Scrum dans son intégralité, en considérant que chaque composant sert un objectif précis et que retirer un élément affaiblit l’ensemble. Cette approche convient aux équipes qui reconnaissent plusieurs problèmes simultanés (direction, cadence, rôles) et préfèrent une transformation structurée.
La seconde utilise les éléments de Scrum comme des “design patterns”, c’est-à-dire des solutions éprouvées à des problèmes spécifiques. Une équipe peut adopter le Sprint Goal sans adopter le sprint, ou instaurer une Sprint Review sans modifier le reste de son processus. Cette approche est plus progressive, mais les auteurs soulignent qu’elle ne constitue pas “faire du Scrum” au sens strict du terme.
Quand le sprint devient un frein
La transparence oblige à reconnaître que le sprint n’est pas toujours pertinent. Pour une équipe Kanban qui a atteint un flux continu mature, avec des livraisons fréquentes et une collaboration constante avec les parties prenantes, le timebox peut introduire une rigidité inutile.
Le “nettoyage de la table” en fin de sprint, où le travail non terminé est réévalué, peut paraître gaspilleur quand l’équipe gère déjà efficacement son encours. De même, l’estimation lors du Sprint Planning perd de sa pertinence quand la décomposition juste-à-temps fonctionne bien.
L’enjeu n’est pas de choisir un camp, mais d’identifier les problèmes réels de l’équipe et de sélectionner les pratiques qui y répondent, qu’elles viennent de Scrum, de Kanban ou d’ailleurs.