Agile : un ensemble de valeurs, pas une méthode
Le mot « agile » fait référence au manifeste agile publié en 2001 par 17 praticiens du développement logiciel : 4 valeurs et 12 principes qui privilégient, par exemple, les individus et leurs interactions plutôt que les processus et les outils, ou la réponse au changement plutôt que le suivi strict d'un plan. Ce manifeste ne décrit aucune pratique concrète — pas de sprint, pas de tableau, pas de rôle nommé.
C'est là que se situe la confusion la plus fréquente : dans le langage courant, « être agile » est souvent réduit à « faire du Scrum ». En réalité, une équipe peut appliquer les valeurs agiles sans suivre Scrum à la lettre, et inversement, une équipe peut suivre les rituels Scrum sans être réellement agile dans son état d'esprit.
Scrum : un cadre structuré en itérations
Scrum organise le travail en sprints — des itérations de durée fixe, généralement une à quatre semaines. Chaque sprint suit un cycle défini : planification en début de sprint, points quotidiens (daily scrum), revue et rétrospective en fin de sprint. Trois rôles structurent l'équipe : le Product Owner (responsable du backlog et de la valeur du produit), le Scrum Master (facilitateur du processus), et l'équipe de développement.
Cette structure apporte un cadre prévisible et un rythme régulier, ce qui facilite la planification et la mesure de la vélocité d'une équipe dans le temps.
Kanban : un flux continu, sans itération imposée
Kanban repose sur une logique différente : un flux continu de tâches visualisées sur un tableau à colonnes, régulé non pas par des itérations mais par des limites de travail en cours (WIP). L'objectif est de terminer les tâches en cours avant d'en démarrer de nouvelles, ce qui réduit le multitâche et améliore le temps de traitement moyen.
Contrairement à Scrum, Kanban ne définit aucun rôle formel : pas de Scrum Master, pas de Product Owner prescrit par le framework lui-même. C'est une différence structurelle importante, pas un simple détail.
- Scrum : itérations de durée fixe, rôles définis, cérémonies régulières
- Kanban : flux continu, limites de travail en cours, pas de rôles formels
Comment choisir entre Scrum et Kanban
Le choix dépend surtout de la nature du travail. Scrum convient bien à des équipes qui construisent un produit par incréments réguliers, avec un périmètre qui peut être découpé en objectifs de sprint. Kanban convient mieux à des flux de travail plus imprévisibles — support, maintenance, exploitation — où des itérations fixes ont peu de sens face à des demandes qui arrivent en continu.
Il existe aussi des approches hybrides, parfois appelées Scrumban, qui empruntent des éléments aux deux frameworks. Elles restent cependant plus faciles à comprendre une fois que Scrum et Kanban ont été appris séparément, plutôt qu'en même temps.
Un critère pratique pour trancher : si vous pouvez découper le travail à venir en objectifs atteignables sur une période fixe de deux à quatre semaines, Scrum a de bonnes chances de convenir. Si le travail arrive de façon continue et imprévisible, sans qu'un découpage en objectifs de sprint fasse sens, Kanban est généralement plus adapté.
Ne pas confondre absence de rôles formels en Kanban avec absence de responsabilités : la coordination et la priorisation restent nécessaires, elles ne sont simplement pas attribuées à des rôles nommés par le framework.
Pour aller plus loin
Questions fréquentes
Peut-on être agile sans utiliser Scrum ou Kanban ?
Oui. L'agilité est un ensemble de valeurs et de principes qui peuvent s'incarner dans des processus qui ne correspondent exactement ni à Scrum ni à Kanban — l'essentiel est d'appliquer les principes (livraison itérative, feedback rapide, amélioration continue), pas de suivre un framework à la lettre.
Scrum est-il plus « agile » que Kanban ?
Non, les deux sont des frameworks agiles à part entière, chacun compatible avec les valeurs du manifeste. Aucun des deux n'est intrinsèquement plus agile que l'autre — ils répondent simplement à des contextes de travail différents.
Une équipe peut-elle changer de framework en cours de route ?
Oui, c'est même assez courant lorsque la nature du travail évolue — par exemple une équipe qui passe d'un mode projet avec périmètre défini (plutôt Scrum) à un mode support avec flux continu de demandes (plutôt Kanban).
Le Scrum Master a-t-il un équivalent en Kanban ?
Pas formellement. Certaines équipes Kanban désignent informellement une personne pour faciliter le flux, mais ce n'est pas un rôle prescrit par le framework, contrairement au Scrum Master dans Scrum.
Faut-il apprendre Scrum avant Kanban ?
Ce n'est pas obligatoire, mais consolider un vocabulaire avant l'autre — plutôt que les deux en parallèle — limite les confusions entre termes proches, comme cela a été observé de façon répétée chez les débutants.
Existe-t-il d'autres frameworks agiles que Scrum et Kanban ?
Oui, il existe d'autres approches (Extreme Programming, Lean Software Development, et des frameworks d'agilité à l'échelle) mais Scrum et Kanban restent les deux les plus utilisés en entreprise, ce qui justifie de les maîtriser en priorité.
Le manifeste agile s'applique-t-il en dehors du développement logiciel ?
À l'origine conçu pour le développement logiciel, le manifeste agile a depuis été adopté bien au-delà — marketing, RH, matériel, voire certaines équipes du secteur public — dès lors que le travail bénéficie d'itérations courtes et de retours fréquents.