Quand une équipe de projet hésite entre Scrum et Kanban, le débat tourne souvent court. D’un côté, les partisans des sprints considèrent Kanban comme un tableau de post-it sans structure. De l’autre, les adeptes du flux continu voient dans Scrum un carcan rigide qui empêche toute réactivité. Ces positions tranchées partagent un point commun: elles reposent sur des caricatures. Comprendre ce que chaque cadre prescrit réellement, et surtout ce qu’il ne prescrit pas, change fondamentalement la manière dont on envisage leur coexistence.
Ce que Kanban exige vraiment
Kanban est souvent réduit à un tableau avec des colonnes et des post-it. Cette vision minimaliste omet l’essentiel. Le Kanban Guide définit cinq pratiques fondamentales: définir et visualiser le workflow, limiter le WIP (Work In Progress, le nombre d’éléments de travail simultanément en cours), gérer activement les éléments de travail, inspecter et adapter le flux (le mouvement continu du travail de la demande à la livraison), et établir des politiques explicites. Aucune de ces pratiques n’est anodine. Limiter le WIP, par exemple, oblige une organisation à renoncer au multitâche systémique, une habitude profondément ancrée dans la plupart des environnements professionnels. Daniel Vacanti, auteur d’Actionable Agile Metrics for Predictability, considère cette exigence comme tout aussi disruptive que l’introduction des sprints et des rôles Scrum.
L’idée que Kanban s’applique sans friction sur un processus existant relève du mythe. Rendre le travail visible et imposer des limites de capacité met en lumière des dysfonctionnements que personne ne souhaite voir, qu’il s’agisse d’un service RH submergé de demandes non priorisées ou d’une équipe de développement produit incapable de terminer ses projets en cours avant d’en démarrer de nouveaux.
Quand les sprints deviennent flexibles
L’objection inverse, selon laquelle Scrum serait trop rigide pour permettre un flux de travail fluide, repose sur une lecture sélective du cadre. Le Scrum Guide 2020 a clarifié plusieurs points que les praticiens chevronnés connaissent mais que les formations d’introduction mentionnent rarement.
Contrairement à une idée répandue, un sprint n’est pas une période à l’issue de laquelle on livre, mais une période au sein de laquelle on peut livrer autant de fois que nécessaire: l’incrément peut être mis à disposition des utilisateurs à tout moment, pas uniquement lors de la Sprint Review. De la même manière, le Sprint Planning a pour objectif de définir un Sprint Goal (l’objectif concret que l’équipe s’engage à atteindre), pas de dresser la liste exhaustive des tâches des deux prochaines semaines. Le Sprint Backlog évolue au fil du sprint à mesure que l’équipe affine sa compréhension du travail, et cette flexibilité native rapproche Scrum d’un système pull (un système où le travail est tiré par la capacité disponible plutôt que poussé par la demande) bien plus que ne le suggèrent ses détracteurs. Le Scrum Guide ne prohibe pas non plus l’ajout d’éléments en cours de sprint, à condition que le Sprint Goal ne soit pas compromis: une équipe qui reçoit une demande urgente compatible avec son objectif peut l’intégrer sans violer aucune règle. La rigidité tant décriée relève davantage de la manière dont certaines organisations implémentent Scrum que de ce que le cadre prescrit effectivement.
La collaboration au coeur du flux
Parmi les critiques adressées à Kanban, celle du manque de travail d’équipe est la plus surprenante. L’argument veut que sans rôles définis ni cérémonies de synchronisation, chaque membre travaille dans son couloir. C’est ignorer ce que signifie concrètement la troisième pratique Kanban: gérer activement les éléments de travail. Quand un goulot d’étranglement (une étape où le travail s’accumule parce que la capacité est insuffisante) se forme, l’équipe entière doit réagir. Les limites de WIP créent une pression systémique qui rend l’entraide non pas optionnelle mais nécessaire: lorsqu’un membre a atteint sa limite, il ne peut avancer qu’en aidant un collègue à débloquer un élément en aval.
Yuval Yeret, praticien reconnu de l’agilité organisationnelle, propose une convention éclairante: nommer les colonnes du tableau par activité plutôt que par rôle. “Analyse” au lieu de “Chez l’analyste”, “Validation” au lieu de “Chez le responsable qualité”. Ce choix de nomenclature, apparemment anodin, change la dynamique de l’équipe. Quand la colonne “Validation” déborde, n’importe quel membre compétent peut y contribuer, ce qui rend les silos fonctionnels perméables et déplace la responsabilité de l’individu vers le collectif.
Le vrai clivage n’est pas méthodologique
Si Scrum et Kanban se ressemblent davantage que leurs partisans respectifs ne l’admettent, pourquoi le faux antagonisme persiste-t-il? Une explication tient à la manière dont ces cadres sont enseignés et commercialisés. Les formations Scrum insistent sur les rôles, les artefacts et les événements, ce qui donne l’impression d’un système fermé. Les formations Kanban mettent en avant la légèreté et l’adaptation progressive, ce qui suggère un système ouvert. Mais les principes sous-jacents convergent: rendre le travail visible, limiter ce qui est en cours, inspecter le résultat, s’adapter.
Le véritable clivage dans les organisations ne se situe pas entre Scrum et Kanban, mais entre les équipes qui mesurent et pilotent leur flux de travail et celles qui se contentent d’afficher un tableau ou de tenir des cérémonies sans en exploiter les données. Une équipe Scrum qui ne suit pas sa vélocité avec rigueur et une équipe Kanban qui affiche un tableau sans jamais respecter ses limites de WIP partagent le même problème: l’absence de discipline empirique. L’outil choisi importe moins que la rigueur avec laquelle il est appliqué.
Combiner sans confondre
La question pratique pour un chef de projet n’est pas de choisir entre Scrum et Kanban, mais d’identifier quelles pratiques de chaque cadre répondent aux problèmes concrets de son équipe. Les sprints apportent un rythme de planification et d’inspection qui convient aux environnements où les priorités changent fréquemment. Les limites de WIP et la gestion active du flux apportent une visibilité opérationnelle qui manque souvent aux équipes Scrum focalisées sur le Sprint Goal sans regarder comment le travail circule au quotidien.
Adopter les deux ne signifie pas les fusionner dans un cadre hybride mal défini, mais comprendre ce que chacun prescrit, respecter ces prescriptions, et observer les résultats. Les faux antagonismes tombent d’eux-mêmes quand on cesse de défendre un camp pour commencer à résoudre des problèmes concrets.