Limites d'en-cours dans Scrum : les erreurs Kanban qui paralysent le Sprint
Bien des Équipes Scrum ont ajouté un tableau Kanban et des limites de travail en cours (WIP) à leur flux de travail, et le Kanban Guide for Scrum Teams de Scrum.org appuie exactement cette démarche. Bien faites, les limites d'en-cours révèlent les goulots d'étranglement et tirent l'équipe vers l'achèvement du travail plutôt que vers son démarrage. Mal faites, elles créent des frictions sans améliorer le flux. Après un an de travail réparti, où un élément bloqué peut traîner inaperçu pendant des jours dans la file d'un bureau à domicile, bien s'y prendre compte plus que jamais. Voici les erreurs que les équipes commettent le plus souvent.
Là où les équipes se trompent
Fixer la limite trop haut pour qu'elle compte. Une limite d'en-cours qui dépasse ce sur quoi l'équipe travaillerait jamais à la fois ne change rien. Le but de la limite est de faire ressentir la contrainte à l'équipe et de lui faire terminer les choses avant d'en tirer d'autres. Si elle ne mord jamais, elle n'est que décoration.
Traiter les limites d'en-cours comme un substitut au Sprint. Ajouter Kanban ne supprime pas Scrum. Le Sprint, l'Objectif de Sprint et tous les événements demeurent. Le Kanban Guide for Scrum Teams est explicite : ces pratiques complètent le cadre Scrum — elles ne remplacent ni le Scrum quotidien, ni la Revue de Sprint, ni la Rétrospective.
Ignorer les indicateurs de flux une fois le tableau en place. Un tableau avec des limites mais sans attention au temps de cycle, à l'âge des éléments ou au débit n'est qu'un mur de papillons adhésifs. La valeur vient de la surveillance de la durée des éléments et de l'action quand ils vieillissent.
Ne jamais laisser l'équipe ajuster la limite. Les limites d'en-cours ne sont pas imposées une fois pour toutes puis figées. L'équipe devrait les inspecter et les adapter en Rétrospective — trop serrées, les gens restent oisifs; trop lâches, les éléments s'accumulent à moitié finis.
Bloquer au lieu de converger. Quand la limite est atteinte, le bon réflexe est que l'équipe converge pour terminer le travail en cours, et non d'en commencer un nouveau dans une autre colonne. Les équipes qui contournent discrètement la limite en perdent tout l'avantage.
Bien le faire
Bien utilisées, les limites d'en-cours et le Scrum quotidien se renforcent mutuellement : la conversation passe de « qu'ai-je fait hier » à « qu'est-ce qui bloque les éléments les plus proches de l'achèvement ». Gardez la pratique honnête avec quelques habitudes.
Fixez la limite initiale légèrement sous le confort actuel, puis ajustez-la en Rétrospective à l'aide de données réelles de temps de cycle.
Rendez les éléments bloqués bien visibles — pour les équipes réparties, un indicateur dans l'outil que tout le monde consulte vaut mieux qu'un coin de tableau physique.
Quand la limite est atteinte, terminez avant de commencer : convergez, travaillez en binôme ou révisez plutôt que d'ouvrir un nouveau travail.
Examinez l'âge des éléments lors du Scrum quotidien afin que rien ne reste oublié dans une file à distance.
Si vos équipes veulent combiner les pratiques de flux Scrum et Kanban d'une manière qui tient vraiment, les services-conseils en réalisation de programmes et de projets de XNM peuvent vous aider à les mettre en place et à les accompagner.