La plupart des articles sur l’intégration de Kanban dans Scrum présentent les limites WIP et les métriques de flux comme des outils d’optimisation. C’est vrai, mais c’est sauter l’étape de diagnostic. En pratique, la première valeur de Kanban dans une équipe Scrum n’est pas l’optimisation du flux: c’est le diagnostic des dysfonctionnements que personne ne voyait.
Le sprint masque autant qu’il révèle
Scrum est conçu autour de cycles d’inspection et d’adaptation. Le Sprint Review montre ce qui a été livré, la rétrospective permet de discuter de ce qui s’est bien ou mal passé. Ces mécanismes sont précieux, mais ils opèrent à la granularité du sprint: on inspecte le résultat final, pas le processus de production.
Entre le Sprint Planning et la Sprint Review, il se passe deux à quatre semaines pendant lesquelles l’équipe travaille sans outil formel pour observer son propre flux. Le Daily Scrum est censé remplir ce rôle, mais en pratique, il se réduit souvent à un tour de table où chacun décrit son activité de la veille. Les problèmes structurels, comme la tendance à tout commencer en début de sprint et à tout terminer dans l’urgence finale, passent sous le radar parce qu’ils ne sont visibles qu’avec un recul que le format du Daily ne permet pas.
Rendre le workflow explicite: le premier diagnostic
La première pratique du Kanban Guide for Scrum Teams consiste à définir et visualiser le workflow (l’ensemble des étapes par lesquelles un élément de travail progresse du début à la fin). En apparence, c’est un exercice simple: dessiner les colonnes d’un tableau. En réalité, c’est un moment de vérité.
Quand une équipe Scrum essaie de formaliser son workflow pour la première fois, elle découvre presque toujours des écarts entre le processus théorique et le processus réel. Les files d’attente implicites apparaissent: l’élément “en cours” qui attend en réalité une revue de code depuis trois jours, la tâche “terminée” qui n’a pas encore été testée. Ces zones grises, invisibles dans un backlog classique organisé en “À faire / En cours / Terminé”, deviennent impossibles à ignorer une fois le workflow détaillé.
Ce premier diagnostic ne nécessite aucune métrique, aucun outil sophistiqué. Il suffit de poser la question: par quelles étapes passe réellement notre travail, et quelles règles régissent le passage d’une étape à l’autre? La plupart des équipes découvrent qu’elles n’ont jamais formalisé ces règles, ce qui explique pourquoi les mêmes discussions reviennent en Daily Scrum sans jamais se résoudre.
Les limites WIP comme révélateur, pas comme contrainte
Poser une limite WIP (Work In Progress, nombre maximal d’éléments autorisés simultanément à une étape du processus) est souvent perçu comme une contrainte d’efficacité. L’idée standard est que limiter le travail en cours réduit le temps de cycle via la loi de Little (temps de cycle moyen = WIP moyen / débit moyen) et améliore le débit global. C’est vrai, mais l’effet le plus immédiat est différent: la limite WIP force l’équipe à confronter ses propres habitudes.
Prenons une équipe de six personnes qui fixe une limite WIP de quatre éléments en développement. Au bout de deux jours, la limite est atteinte et deux personnes n’ont rien à tirer du backlog. Soit elles aident à débloquer un élément en cours (swarming), soit elles commencent à négocier une hausse de la limite “juste cette fois”. La seconde réaction est la plus courante et la plus instructive: elle révèle que l’équipe fonctionne habituellement en mode push (chacun prend du travail indépendamment) plutôt qu’en mode pull (on ne commence que quand la capacité le permet).
Ce moment de friction est le vrai apport des limites WIP. Elles ne produisent pas automatiquement un meilleur flux: elles rendent visibles les comportements qui empêchent le flux de s’installer.
Le work item age: voir les problèmes avant qu’ils n’arrivent
Parmi les quatre métriques de flux recommandées par le guide (WIP, cycle time, throughput et work item age), la moins intuitive est le work item age, le temps écoulé depuis qu’un élément en cours a été commencé. Contrairement au cycle time (temps total de traitement d’un élément terminé), le work item age s’applique aux éléments encore dans le système.
Sa valeur diagnostique est considérable. Un élément dont l’âge dépasse le 85e percentile du cycle time historique de l’équipe est un signal d’alerte: quelque chose le bloque, et ce blocage est probablement invisible dans le format classique du Daily Scrum. En parcourant le tableau de droite à gauche et en commençant par les éléments les plus anciens, l’équipe identifie ses problèmes réels au lieu de discuter des activités de chacun.
Les équipes qui adoptent cette métrique découvrent des schémas récurrents: certains types d’éléments vieillissent systématiquement plus que d’autres, certaines étapes du workflow accumulent de l’âge de manière disproportionnée. Ces schémas pointent vers des problèmes structurels (dépendances externes, compétences concentrées sur une seule personne, critères d’acceptation flous) que la rétrospective classique peine à identifier sans données.
Diagnostic d’abord, optimisation ensuite
La quatrième pratique du guide, l’inspection et l’adaptation de la définition du workflow, ferme la boucle diagnostique. Une fois que l’équipe voit son flux réel, mesure le vieillissement de ses éléments en cours et ressent la friction des limites WIP, elle dispose de données concrètes pour alimenter ses rétrospectives.
L’approche recommandée s’inspire du Toyota Kata de Mike Rother: définir un état cible mesurable, observer l’écart avec l’état actuel, identifier le prochain obstacle et mener une seule expérimentation à la fois. Cette discipline empêche le piège classique de la rétrospective où l’équipe identifie cinq problèmes, décide de cinq actions et n’en exécute aucune faute de priorisation.
Ce que le diagnostic change dans la posture de l’équipe
L’erreur la plus fréquente dans l’adoption de Kanban au sein d’une équipe Scrum est de commencer par l’optimisation: installer un tableau, fixer des limites WIP et attendre que le throughput augmente. Cette approche produit souvent de la frustration parce que les limites sont perçues comme arbitraires tant que l’équipe ne comprend pas les problèmes qu’elles sont censées résoudre.