Kanban et Scrum sont deux approches agiles. Elles ne s'opposent pas au fond — les deux visent le flux de valeur — mais elles conviennent à des contextes différents.

Scrum convient bien quand

• Le travail se prête à un but commun sur quelques semaines (un objectif de sprint a du sens).
• L'équipe gagne à un rythme régulier et à des rendez-vous cadencés.
• Les demandes sont assez homogènes pour être planifiées par lots.
• On construit un produit avec une roadmap.

Kanban convient bien quand

• Le travail arrive en continu, de façon imprévisible (support, exploitation, maintenance).
• Les demandes sont de tailles très variées, difficiles à regrouper en sprints.
• Les priorités changent souvent, y compris en cours de semaine.
• L'équipe traite un flux plutôt qu'un projet.

Le critère décisif

« Est-ce que s'engager sur un lot de travail pour deux semaines a du sens ? » Si oui, Scrum. Si les priorités bougent trop pour ça, Kanban.

Ce n'est pas définitif

Une équipe peut commencer en Scrum, puis, en gagnant en maturité, relâcher la cadence vers du Kanban ou du Scrumban (leçon suivante). L'inverse arrive aussi : une équipe support qui se met à porter un vrai produit adopte des sprints.

Exemple concret : l'équipe qui développe l'application de fidélité utilise Scrum : elle construit un produit, avec une roadmap et des objectifs de sprint. L'équipe qui gère les réclamations clients, elle, utilise Kanban : des demandes qui arrivent en continu, de tailles très variables, avec des urgences fréquentes.

À vous de jouer : pour une équipe que vous connaissez, dites si Scrum ou Kanban lui conviendrait mieux, et pourquoi.