Deux questions différentes
On présente souvent Kanban et Scrum comme deux plats du même menu. En pratique, ils partent de deux questions distinctes. Kanban demande : où le travail s'arrête-t-il ? Scrum demande : qu'est-ce qu'on peut livrer d'ici la fin du cycle ? Le reste de la comparaison en découle.
Kanban : surveiller le flux
Le Kanban Guide (édition de mai 2025) définit Kanban comme une stratégie pour optimiser le flux de valeur dans un processus. Elle repose sur trois pratiques : définir et visualiser le flux de travail, gérer activement les éléments qui le traversent, et améliorer le flux. Pas d'itération imposée, pas de rôle prescrit. Une seule exigence est vraiment ferme : contrôler le nombre d'éléments en cours, entre le moment où on les démarre et celui où on les termine.
Pourquoi cette limite pèse-t-elle autant ? Parce qu'elle agit directement sur le temps qu'une tâche met à traverser le tableau. La loi de Little dit que, dans un système stable, le nombre moyen d'éléments en cours est égal au débit moyen multiplié par le temps moyen de traversée (Little, 2011).
Un exemple avec des chiffres inventés pour l'occasion. Une équipe de support termine environ 5 tickets par jour et en laisse 20 ouverts en permanence : chaque ticket met en moyenne 4 jours à sortir (20 ÷ 5). Si elle plafonne les tickets en cours à 8 sans que son débit baisse, le délai moyen tombe à 1,6 jour (8 ÷ 5). Rien n'a été accéléré : on a simplement arrêté de tout commencer en même temps.
Scrum : tenir un rythme
Le Guide Scrum 2020 de Ken Schwaber et Jeff Sutherland décrit Scrum comme un cadre léger qui aide des personnes, des équipes et des organisations à créer de la valeur par des solutions adaptatives, face à des problèmes complexes. Il est précis sur peu de points : des Sprints d'un mois au maximum, une équipe de dix personnes ou moins, trois responsabilités (Developers, Product Owner, Scrum Master), cinq événements dont le Sprint lui-même, et trois artefacts (Product Backlog, Sprint Backlog, Increment). Chaque Sprint poursuit un objectif unique, le Sprint Goal. Les détails sont dans notre article sur la méthode Scrum.
Ce qui change en pratique
| Critère | Kanban | Scrum |
|---|---|---|
| Question de départ | Où le travail stagne-t-il ? | Que livre-t-on à la fin du Sprint ? |
| Ce qu'on borne | Le nombre d'éléments en cours | La durée du Sprint (un mois maximum) |
| Rôles imposés | Aucun | Product Owner, Scrum Master, Developers |
| Changement d'avis en cours de route | Possible à tout moment, dans la limite d'en-cours | Le backlog se réordonne ; seul le Product Owner peut annuler un Sprint |
| Mesures courantes | Temps de traversée, débit | Sprint Goal atteint ou non (la vélocité est un usage répandu, mais le Guide ne la mentionne pas) |
Comment choisir sans s'y perdre
- Le travail arrive au fil de l'eau, en petites pièces, sans date commune (support, contenu, recrutement) : Kanban colle mieux, faute de livrable collectif à caler sur un calendrier.
- L'équipe construit un produit ou une campagne et veut un point de contrôle régulier avec les parties prenantes : Scrum donne ce rythme, à condition de tenir ses événements.
- Kanban sans limite d'en-cours devient une liste de choses à faire plus présentable. Scrum sans rétrospective qui change quelque chose devient une succession de réunions.
Beaucoup d'équipes mélangent les deux. Pour un panorama de ce que la littérature recense sur l'usage de Kanban dans le logiciel, on peut lire la revue systématique d'Ahmad, Markkula et Oivo (2013).
Sources
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (mai 2025). kanbanguides.org
- Schwaber, K., & Sutherland, J. (2020). The 2020 Scrum Guide. scrumguides.org
- Little, J. D. C. (2011). OR Forum: Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549. doi:10.1287/opre.1110.0940
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013). Kanban in software development: A systematic literature review. 39th EUROMICRO Conference on Software Engineering and Advanced Applications, 9-16. doi:10.1109/SEAA.2013.28