Agilité

Scrum ou Kanban : quelle méthode agile choisir pour votre équipe ?

Par Codevista InnovationsPublié le 12 octobre 2026Mis à jour le 15 octobre 20269 min de lecture

Scrum organise le travail en sprints d'un mois au plus, avec trois responsabilités (Product Owner, Scrum Master, Developers) et des événements fixes ; Kanban gère un flux continu sans rôles imposés, en limitant le travail en cours. Choisissez Scrum quand une équipe construit un produit et peut protéger un objectif pendant quelques semaines, Kanban quand les demandes arrivent sans prévenir (support, maintenance, exploitation). Le Scrumban combine les deux.

Quelle est la différence entre Scrum et Kanban ?

Les deux approches partagent les principes agiles : rendre le travail visible, livrer par petits morceaux, s'améliorer à partir des faits. Elles diffèrent par le degré de structure. Scrum est un cadre décrit dans le Scrum Guide : responsabilités, événements et artefacts définis. Kanban est une méthode de gestion du flux : on visualise le processus actuel, on limite le travail en cours et on l'améliore pas à pas.

• Cadence : sprints de durée fixe (un mois ou moins) contre flux continu sans itération obligatoire.
• Rôles : Product Owner, Scrum Master et Developers contre aucun nouveau rôle imposé.
• Événements : le Sprint et, à l'intérieur, Sprint Planning, Daily Scrum, Sprint Review et Sprint Retrospective, contre des rituels choisis par l'équipe.
• Limitation du travail : ce qui entre dans le sprint contre des limites de WIP par étape du flux.
• Mesure : atteinte de l'objectif de sprint (la vélocité n'est qu'une pratique courante) contre lead time, débit et âge des tâches.
• Changements : objectif de sprint protégé, périmètre renégociable avec le Product Owner, contre nouvelle priorité acceptée dès qu'une place se libère.

Sprints ou flux continu : cadence, rôles et événements

Ce que le Scrum Guide impose

Le sprint est un conteneur pour tous les autres événements. Sa durée est fixe et d'un mois au plus ; beaucoup d'équipes logicielles retiennent des sprints plus courts. Le Sprint Planning définit l'objectif de sprint et le travail qui y contribue. Le Daily Scrum, limité à 15 minutes, permet aux Developers d'inspecter leur progression vers cet objectif et d'ajuster leur plan. La Sprint Review est une séance de travail avec les parties prenantes sur le résultat obtenu et la suite, pas une simple démonstration. La Sprint Retrospective porte sur la façon de travailler.

Le Product Owner est responsable de maximiser la valeur du produit et de gérer le Product Backlog, ordre de priorité compris. Le Scrum Master est responsable de la mise en place de Scrum et de l'efficacité de la Scrum Team. Les Developers, c'est-à-dire tous ceux qui produisent l'incrément, quel que soit leur métier, s'engagent à livrer à chaque sprint un incrément utilisable qui respecte la Definition of Done. Le Scrum Guide indique qu'une Scrum Team compte généralement dix personnes ou moins.

Ce que Kanban laisse libre

Kanban ne réorganise pas l'équipe. On cartographie les étapes réelles du travail (à analyser, en cours, en revue, livré), on écrit les règles de passage entre colonnes, puis on choisit ses rituels : point quotidien devant le tableau, revue régulière du flux. Cette souplesse fait démarrer vite, mais devient un risque si personne ne porte l'amélioration.

Limites de WIP, métriques et changements en cours de sprint

La limite de WIP (work in progress) est le cœur de Kanban. Si la colonne « en revue », limitée à trois éléments, est pleine, on n'y fait plus rien entrer : plutôt que de démarrer autre chose, l'équipe aide à terminer ce qui attend. Le multitâche diminue et les goulots deviennent visibles. La loi de Little formalise l'intuition : dans un flux stable, à débit égal, plus de travail en cours signifie en moyenne des délais plus longs.

• Scrum : on regarde d'abord si l'objectif de sprint est atteint et l'incrément réellement terminé. La vélocité n'est pas prescrite par le Scrum Guide ; c'est un outil de prévision interne, pas une mesure de performance à comparer entre équipes.
• Kanban : le lead time (de la demande à la livraison), le cycle time (du démarrage à la livraison), le débit et l'âge des tâches en cours répondent à la question de tout demandeur : « quand est-ce que ce sera prêt ? »

Sur le changement, le Scrum Guide est clair : aucun changement ne doit mettre en danger l'objectif du sprint. Le périmètre peut être renégocié avec le Product Owner, seul habilité à annuler un sprint devenu sans objet. En Kanban, la priorité se décide quand une place se libère : un incident urgent passe sans rompre d'engagement.

Scrum ou Kanban : quelle méthode pour quelle équipe ?

Le bon critère n'est ni la taille de l'entreprise ni le secteur, mais la nature des demandes qui arrivent à l'équipe.

• Scrum convient aux équipes qui construisent un produit avec un objectif : plateforme SaaS, application métier, nouveau service digital. Elles peuvent montrer un résultat utilisable à la fin de chaque sprint et ajuster la suite.
• Kanban convient au travail continu et imprévisible : support applicatif, maintenance corrective, exploitation, traitement de dossiers, ou demandes internes d'une équipe RH ou marketing.
• Le Scrumban convient quand le backlog est stable mais que les urgences sont fréquentes.

Dans une même DSI, à Casablanca comme ailleurs, les deux peuvent coexister : l'équipe qui refond le portail client en Scrum, celle qui maintient la production en Kanban. Quand plusieurs équipes Scrum livrent un même produit, la question devient celle de l'agilité à l'échelle avec SAFe ; pour les fonctions hors IT, voir l'agilité au-delà de l'IT.

Scrumban : quand combiner Scrum et Kanban

Le Scrumban n'a pas de référentiel comparable au Scrum Guide : c'est une pratique qui garde une partie de la structure de Scrum et y ajoute la gestion du flux. Deux points de départ sont courants.

• Une équipe Scrum qui ajoute du Kanban garde sprints, rôles et événements, mais pilote son Sprint Backlog avec des limites de WIP et suit son cycle time.
• Une équipe Kanban qui ajoute de la cadence garde le flux continu, mais instaure une revue et une rétrospective à date fixe.

Le Scrumban échoue quand il sert d'excuse pour supprimer ce qui dérange : plus d'objectif, plus de limite respectée, plus de rétrospective. Si l'équipe ne sait plus dire quelles règles elle suit, ce n'est plus du Scrumban.

Les erreurs fréquentes avec Scrum et avec Kanban

Anti-patterns Scrum

• Le Product Owner de façade, sans pouvoir réel d'arbitrer les priorités.
• Le Scrum Master secrétaire, qui organise les réunions mais ne lève aucun obstacle.
• Le sprint sans objectif, simple liste de tâches que chaque urgence fait dérailler.
• La vélocité comme indicateur de performance, qui pousse à gonfler les estimations.
• La rétrospective sans suite, où les mêmes problèmes reviennent sprint après sprint.

Anti-patterns Kanban

• Le tableau sans limites : on démarre tout ce qui arrive ; ce n'est qu'une liste en colonnes.
• Des limites dépassées chaque semaine « exceptionnellement », donc inexistantes.
• Des règles implicites : personne ne sait ce que « terminé » veut dire ni qui choisit la prochaine demande.
• Aucune revue du flux : l'équipe subit son tableau au lieu de l'améliorer.

Checklist : comment choisir entre Scrum et Kanban

1. Le travail peut-il être regroupé autour d'un objectif tenu sur un sprint (un mois au plus) sans interruption permanente ? Si oui, Scrum est un bon candidat.
2. Une part importante des demandes est-elle urgente et imprévisible ? Privilégiez Kanban, ou une capacité réservée en Scrumban.
3. Une personne peut-elle arbitrer les priorités avec une vraie autorité ? Scrum en a besoin dès le départ.
4. L'organisation est-elle prête à changer rôles et réunions ? Sinon, Kanban permet de commencer avec le processus actuel.
5. Vos demandeurs veulent-ils surtout savoir quand ce sera prêt ? Les métriques de flux y répondent directement.
6. Plusieurs équipes travaillent-elles sur un même produit ? Il faudra aussi un cadre d'agilité à l'échelle.

Quel que soit le choix, formez l'équipe et ceux qui fixent ses priorités ensemble. Codevista Innovations propose une formation Scrum et une formation Kanban, en présentiel partout au Maroc, en hybride ou à distance ; notre dossier de qualification pour le financement CSF de l'OFPPT est en cours. Pour choisir la bonne, ou bâtir un programme sur mesure à partir d'un audit de compétences, contactez-nous.

Questions fréquentes

Peut-on passer de Scrum à Kanban en cours de projet ?

Oui, c'est fréquent quand un produit passe de la construction à la maintenance. Gardez le tableau existant, ajoutez des limites de WIP et des règles explicites, puis allégez les sprints une fois le flux stabilisé. Conservez une rétrospective régulière : c'est souvent le premier rituel abandonné, alors que c'est lui qui permet de corriger la transition.

Kanban convient-il à une équipe qui n'est pas informatique ?

Oui. Kanban ne suppose ni code ni logiciel : il suffit d'un travail qui passe par des étapes identifiables. Une équipe RH qui gère des recrutements, un service achats ou une équipe marketing peuvent visualiser leur flux, limiter le travail en cours et suivre leurs délais. C'est souvent l'entrée la plus simple dans l'agilité pour les fonctions hors IT.

Faut-il un Scrum Master dans une équipe Kanban ou Scrumban ?

Kanban n'impose aucun rôle, donc pas de Scrum Master. En pratique, quelqu'un doit veiller au respect des limites de WIP, animer la revue du flux et porter les actions d'amélioration. En Scrumban, si l'équipe garde les événements de Scrum, il reste utile de confier à une personne la responsabilité de leur efficacité.

Quelle formation choisir entre Scrum et Kanban ?

Celle qui correspond au travail réel de l'équipe. Une formation Scrum sert un Product Owner, un Scrum Master ou les Developers d'une équipe produit. Une formation Kanban sert davantage les responsables du support, de l'exploitation ou des services internes. Dans une organisation mixte, former les managers aux deux évite de transformer le choix de méthode en querelle de chapelles.