Les fondamentaux : deux philosophie différentes
Avant de plonger dans les détails techniques, comprenons d'abord ce qui distingue fondamentalement ces deux approches.
Scrum fonctionne par cycles courts et structurés. Imaginez une équipe qui organise son travail en sprints de deux semaines. Chaque lundi matin, l'équipe se réunit pour planifier ce qui sera livré. Chaque jour, un point rapide de 15 minutes permet d'identifier les blocages. Et à la fin du sprint, une démonstration montre les résultats concrets aux parties prenantes, suivie d'une rétrospective pour s'améliorer.
Kanban privilégie le flux continu. Prenons l'exemple d'une équipe support qui reçoit des demandes en permanence. Leur tableau visualise chaque tâche depuis "À faire" jusqu'à "Terminé", avec une règle simple : maximum 3 tâches en cours par personne. Dès qu'une tâche est terminée, la suivante démarre. Pas de sprint, pas de réunion de planification imposée, juste un flux constant et maîtrisé.
Scrum : la structure qui libère
Les cérémonies qui rythment le travail
Scrum impose cinq moments clés qui structurent le quotidien de l'équipe :
💠 Sprint Planning (4h pour un sprint de 2 semaines) : l'équipe sélectionne les éléments du backlog qu'elle s'engage à livrer et définit comment elle va les réaliser.
💠 Daily Scrum (15 minutes quotidiennes) : chacun partage ce qu'il a fait hier, ce qu'il fera aujourd'hui et les obstacles rencontrés.
💠 Sprint Review (2h en fin de sprint) : démonstration des fonctionnalités livrées aux parties prenantes pour recueillir leurs retours.
💠 Sprint Rétrospective (1h30 après la review) : l'équipe analyse ce qui a bien fonctionné et identifie des axes d'amélioration concrets.
💠 Backlog Refinement (2h par semaine, réparties) : préparation et clarification des éléments futurs du backlog.
Une équipe de développement d'une startup parisienne témoigne : "Au début, ces réunions nous semblait lourdes. Mais après trois mois, nous avons réduit nos bugs de 40% grâce aux rétrospectives, et nos délais de livraison sont passés de 6 semaines imprévisibles à des sprints de 2 semaines tenus à 85%."
Les métriques qui comptent
Scrum s'appuie sur des indicateurs précis pour mesurer la performance et la prédictibilité :
La vélocité mesure le nombre de points d'histoire livrés par sprint. Une équipe qui livre régulièrement 35 points par sprint peut planifier avec confiance. Si cette vélocité chute soudainement à 20 points, c'est un signal d'alarme immédiat : dette technique, surcharge cognitive, problèmes d'équipe.
Le burndown chart visualise l'avancement du sprint jour après jour. Une courbe qui ne descend pas assez vite en milieu de sprint permet d'ajuster avant qu'il ne soit trop tard.
Le sprint goal achievement révèle si l'objectif du sprint est atteint. Des équipes matures atteignent leur objectif dans 80 à 90% des cas. En dessous de 60%, il faut revoir la façon dont les sprints sont planifiés.
Kanban : la fluidité maîtrisée
Les principes visuels et les limites
Kanban repose sur la visualisation du travail et la limitation du travail en cours (Work In Progress - WIP). Le tableau Kanban le plus simple comporte trois colonne : "À faire", "En cours" et "Terminé". Mais les équipes matures ajoutant des colonnes qui reflètent leur réalité. "En revue de code", "En test", "En attente de validation client".
La vraie puissance de Kanban réside dans les limites WIP. Si une colonne "En développement" est limitée à 4 tâches et qu'elle est pleine, personne ne peut en démarrer une cinquième tant qu'une des quatre n'a pas avancé. Cette contrainte force l'équipe à finir ce qui est commencé plutôt que de multiplier les tâches en parallèle.
Une équipe d'intégration d'une entreprise du CAC 40 raconte : "Avant Kanban, chaque développeur jonglait avec 7 ou 8 tickets simultanément. Rien n'avançait vraiment. En imposant une limite de 2 tickets par personne, notre temps de livraison moyen est passé de 12 jours à jour, sans augmenter l'effectif".
Les métriques de flux
Kanban se concentre sur la fluidité et la prévisibilité du flux de travail :
Le lead time mesure le temps écoulé entre le moment où une demande arrive et celui où elle est livrée. Un lead time de 8 jours en moyenne signifie qu'un client peut s'attendre à recevoir sa demande une semaine après l'avoir formulée.
Le cycle time mesure uniquement le temps de travail actif, une fois qu'on a commencé la tâche. Si le lead time est de 8 jours mais le cycle time de 3 jours, cela signifie que les tâches attendent 5 jours avant qu'on ne commence à travailler dessus.
Le throughtput compte simplement combien d'éléments sont livrés par semaine ou par mois. Une équipe qui livre régulièrement 20 tickets par semaine peut prévoir avec confiance qu'un backlog de 60 tickets prendra environ 3 semaines.
Le diagramme de flux cumulatif révèle les goulots d'étranglement. Si la zone "En test" s'élargit au fil des semaines, c'est que les testeurs sont débordés et qu'il faut rééquilibrer l'équipe.
Quel contexte pour quelle méthode ?
Scrum excelle quand...
Scrum brille dans les situations où la prévisibilité et l'alignement sont essentiels. Si vous développez un produit avec des dépendances fortes entre équipes, des parties prenantes qui veulent des points réguliers, et des objectifs claires à atteindre par périodes, Scrum apporte cette structure rassurante.
Les équipes produit travaillant sur des fonctionnalités complexes nécessitant de la coordination trouvent dans Scrum un cadre qui force la collaboration. Les sprints créent des jalons naturels pour synchroniser les efforts et valider l'avancement.
Kanban convient mieux quand...
Kanban s'impose quand le travail arrive de façon imprévisible et que la priorité change fréquemment. Les équipes de maintenance, de support, ou d'infrastructure apprécient la flexibilité de pouvoir traiter les urgences sans casser un sprint en cours.
Pour des équipes matures qui n'ont pas besoin de la structure imposée par Scrum, Kanban offre l'agilité d'adapter le processus en continu. Pas besoin d'attendre la fin d'un sprint pour changer de cap ou ajouter les priorités.
Les environnements où le flux est continu, comme les opérations DevOps ou les équipes platform, bénéficient de l'approche "pull" de Kanban : chacun tire le prochain élément quand il a de la capacité, plutôt que de s'engager sur un volume fixe en début de sprint.
Les idées reçues à déconstruire
"Scrum est trop lourd pour ma petit équipe." En réalité, Scrum peut être adapté. Une startup de 4 développeurs peut faire des sprints d'une semaine avec des cérémonies allégées : 30 minutes de planning, 10 minutes de daily, 30 minutes de review-rétro combinées. C'est l'esprit de structure régulière qui compte, pas la durée exacte des réunions.
"Kanban, c'est juste un tableau à post-it." Beaucoup d'équipes découvrent Kanban en collant des post-it sur un mur et pensent avoir adopté la méthode. Mais sans limites WIP claires, sans mesure du lead time, sans amélioration continue basée sur les métriques, ce n'est qu'un tableau de visualisation, pas du Kanban.
"Il faut choisir une seule méthode." Des dizaines d'équipes pratiquent avec succès un hybride appelé Scrumban. Elle gardent les sprints et les cérémonies de Scrum pour la structure et l'alignement, mais ajoutent un tableau Kanban avec des limites WIP pour mieux gérer le flux quotidien. Une équipe de 12 personnes d'une scale-up lyonnaise témoigne avoir réduit son temps de cycle de 40% en combinant les deux approches.
Comment trancher pour votre équipe
Plutôt que de choisir selon une préférence personnelle, posez-vous ces questions concrètes :
Votre travail arrive-t-il par vague ou en flux continu ? Si vous avez des releases trimestrielles avec des phases de conception puis de développement, Scrum apporte le rythme adapté. Si les demandes arrivent tous les jours de façon aléatoire, Kanban gérera mieux cette imprévisibilité.
Vos parties prenantes ont-elles besoins de jalons réguliers ? Les démos de fin de sprint rassurent les sponsors et créent des moments de feedback. Kanban livre en continu mais n'a pas ces points de synchronisation naturels.
Votre équipe a-t-elle besoin de structure d'autonomie ? Une équipe junior ou une nouvelle équipe qui se forme appréciera souvent le cadre clair de Scrum. Une équipe mature qui sait s'auto-organiser se sentira à l'étroit et préférera la souplesse de Kanban.
Pouvez-vous figer les priorités pour 2 semaines ? Si votre métier l'impose de réagir en quelques heures aux urgences clients, un engagement de sprint devient une contrainte frustrante. Kanban permet de prioriser au jour le jour.
Commencez par un essai de 3 mois avec l'approche qui semble la plus adaptée. Mesurez ce qui compte pour vous : délais de livraison, satisfaction d'équipe, qualité du code, prévisibilité. Et surtout, écoutez votre équipe. Ce sont eux qui vivent la méthode au quotidien, leur ressenti est le meilleur indicateur de l'adéquation entre votre contexte et la méthodologie choisie.
L'agilité qu'elle soit incarnée par Scrum ou Kanban, n'est pas une religion. C'est un ensemble de pratiques au service d'un objectif : livrer de la valeur régulièrement, avec une équipe épanouie et des clients satisfaits. La meilleure méthodologie est celle qui vous rapproche de cet objectif.