Scrum vs Kanban : quelle méthode agile choisir ?

Scrum et Kanban sont les deux approches agiles les plus populaires dans le monde du développement logiciel et au-delà. Si elles partagent des valeurs communes (transparence, amélioration continue, livraison de valeur), elles diffèrent profondément dans leur structure et leur application. Choisir entre les deux, ou les combiner, dépend de votre contexte, de votre équipe et de la nature du travail à accomplir.

Cet article compare Scrum et Kanban de manière objective pour vous aider à faire un choix éclairé.

Scrum en bref

Scrum est un framework agile fondé sur l'empirisme et le lean thinking. Il organise le travail en cycles itératifs appelés Sprints, d'une durée fixe (généralement deux semaines). Chaque Sprint est structuré par des événements formels : Sprint Planning, Daily Scrum, Sprint Review et Sprint Retrospective.

Scrum définit trois rôles (Product Owner, Scrum Master, Developers), trois artefacts (Product Backlog, Sprint Backlog, Increment) et cinq événements. C'est un framework prescriptif dans sa structure, mais flexible dans son contenu.

Kanban en bref

Kanban est une méthode de gestion du flux de travail inspirée du système de production Toyota. Son principe fondamental est la visualisation du travail et la limitation du travail en cours (WIP limits). Contrairement à Scrum, Kanban ne prescrit ni rôles, ni événements, ni itérations fixes.

Kanban repose sur quatre principes :

1. Visualiser le flux de travail : chaque tâche est représentée sur un tableau, de "A faire" à "Terminé".
2. Limiter le travail en cours : chaque colonne du tableau a un nombre maximum d'éléments.
3. Gérer le flux : mesurer et optimiser le temps de traversée (lead time) des éléments.
4. Améliorer continuellement : analyser les métriques pour identifier les goulots d'étranglement.

Tableau comparatif complet

Dimension	Scrum	Kanban
Cadence	Sprints fixes (1-4 semaines)	Flux continu
Rôles	PO, SM, Developers	Aucun rôle prescrit
Événements	5 événements formels	Aucun événement prescrit
Planification	Sprint Planning en début de Sprint	En continu, au fil de l'eau
Métrique clé	Vélocité	Lead time, throughput
Changements	Scope protégé pendant le Sprint	Changements possibles à tout moment
Artefacts	Product Backlog, Sprint Backlog, Increment	Tableau Kanban
Livraison	A la fin de chaque Sprint	En continu
Estimation	Recommandée (Story Points, T-shirt sizing)	Optionnelle
WIP limits	Implicites (capacité du Sprint)	Explicites (par colonne)

Quand choisir Scrum

Scrum est particulièrement adapté dans les contextes suivants :

Développement de produit complexe

Quand l'équipe construit un produit dans un environnement incertain, les Sprints offrent un cadre pour expérimenter, apprendre et s'adapter rapidement. La boucle Sprint Planning, livraison, Review, Retrospective crée un cycle d'apprentissage structuré.

Équipe nouvelle ou immature en agilité

Scrum fournit un cadre clair avec des rôles définis, des événements structurés et des règles explicites. Pour une équipe qui découvre l'agilité, cette structure est un guide précieux. Le rôle du Scrum Master est particulièrement important pour accompagner cette transition.

Besoin de prévisibilité

Les Sprints de durée fixe et la vélocité permettent de prévoir approximativement ce qui sera livré et quand. Les parties prenantes peuvent s'appuyer sur un rythme régulier de livraison et de démonstration.

Priorités qui changent fréquemment

Le Product Backlog permet de réordonner les priorités entre chaque Sprint, tout en protégeant le travail en cours pendant le Sprint. Ce mécanisme de protection est essentiel quand les demandes changent constamment.

Quand choisir Kanban

Kanban excelle dans d'autres contextes :

Travail de maintenance et support

Les équipes qui gèrent des tickets de support, des incidents ou de la maintenance bénéficient du flux continu de Kanban. Il n'est pas nécessaire d'attendre le prochain Sprint pour prendre en charge un bug critique.

Travail imprévisible

Quand la nature et le volume du travail sont difficiles à prévoir (support client, opérations, DevOps), la flexibilité de Kanban est un avantage. Pas besoin de s'engager sur un Sprint Backlog quand on ne sait pas ce qui arrivera demain.

Equipes matures en agilité

Les équipes qui maîtrisent déjà les principes agiles peuvent trouver la structure de Scrum trop contraignante. Kanban leur offre un cadre plus léger tout en maintenant les principes de transparence et d'amélioration continue.

Optimisation du flux

Quand l'objectif principal est de réduire le temps de traversée et d'augmenter le débit, les métriques de Kanban (lead time, cycle time, throughput) sont plus adaptées que la vélocité de Scrum.

Les métriques comparées

Métriques Scrum

• Vélocité : nombre de Story Points livrés par Sprint. Permet de prévoir la capacité future.
• Burndown chart : progression du travail restant pendant le Sprint.
• Sprint Goal success rate : pourcentage de Sprints dont le Sprint Goal a été atteint.

Métriques Kanban

• Lead time : temps total entre la demande et la livraison.
• Cycle time : temps entre le début du travail et sa livraison.
• Throughput : nombre d'éléments livrés par unité de temps.
• WIP : nombre d'éléments en cours à un instant donné.
• Cumulative Flow Diagram : visualisation de la distribution du travail dans les différentes étapes.

Scrumban : le meilleur des deux mondes ?

Certaines équipes choisissent de combiner Scrum et Kanban dans une approche appelée Scrumban. Concrètement, cela peut signifier :

• Conserver les Sprints et les événements Scrum, mais ajouter des WIP limits explicites.
• Garder le tableau Kanban et les métriques de flux, mais introduire des Retrospectives régulières.
• Utiliser Scrum pour le développement de nouvelles fonctionnalités et Kanban pour le support.

Cette approche hybride peut fonctionner, à condition de ne pas perdre la cohérence du framework choisi. Le risque est de prendre les éléments les plus confortables de chaque approche en ignorant les contraintes qui les rendent efficaces.

Les idées reçues à déconstruire

"Kanban est plus agile que Scrum"

Kanban est plus flexible que Scrum, mais pas nécessairement plus agile. L'agilité ne se mesure pas au nombre de règles, mais à la capacité de s'adapter et de livrer de la valeur. Un Scrum bien pratiqué peut être plus agile qu'un Kanban mal implémenté.

"Scrum interdit les changements pendant le Sprint"

Scrum protège le Sprint Goal, pas le contenu exact du Sprint Backlog. Les Developers peuvent négocier le périmètre avec le Product Owner tant que le Sprint Goal n'est pas menacé.

"Kanban n'a pas besoin de discipline"

L'absence de structure prescrite ne signifie pas l'absence de discipline. Les WIP limits, la visualisation du flux et l'amélioration continue exigent une rigueur quotidienne. Sans discipline, Kanban dégénère en chaos organisé.

"Il faut choisir l'un ou l'autre"

Rien n'interdit de commencer par Scrum pour acquérir les fondamentaux agiles, puis de migrer vers Kanban ou Scrumban à mesure que l'équipe gagne en maturité. L'approche peut aussi varier selon les projets ou les équipes au sein d'une même organisation.

Comment choisir : un guide de décision

Posez-vous ces questions :

1. Votre travail est-il planifiable ? Si oui, Scrum. Si non, Kanban.
2. Votre équipe débute en agilité ? Si oui, Scrum offre un cadre structurant.
3. Livrez-vous un produit ou gérez-vous un service ? Produit : Scrum. Service : Kanban.
4. Avez-vous besoin de prévisibilité pour les parties prenantes ? Si oui, Scrum avec ses Sprints réguliers.
5. Votre priorité est-elle l'optimisation du flux ? Si oui, Kanban et ses métriques dédiées.

Scrum, Kanban et certification

La compréhension de Scrum et de ses différences avec d'autres approches est un élément important de la certification PSM I. L'examen peut inclure des questions sur ce qui distingue Scrum d'autres frameworks ou méthodes, et sur les principes fondamentaux qui font de Scrum un framework unique.

Pour maîtriser ces distinctions et vous préparer efficacement, inscrivez-vous sur Outsmart et entraînez-vous avec des questions adaptées à votre niveau.

En résumé

Scrum et Kanban ne sont pas en compétition : ce sont deux outils différents pour des contextes différents. Scrum excelle dans le développement de produit avec sa structure itérative et ses rôles définis. Kanban brille dans la gestion de flux continu avec sa flexibilité et ses métriques de flux. Le meilleur choix est celui qui correspond à votre contexte, votre équipe et vos objectifs. Et quel que soit votre choix, les principes d'empirisme, de transparence et d'amélioration continue restent les fondements d'une pratique agile réussie.