Kanban vs. Scrum : un Cadre de Décision, pas une Guerre de Religion
Peu de sujets en management d'ingénierie génèrent autant de chaleur et aussi peu de lumière que le débat Kanban vs. Scrum. J'ai assisté à des réunions où des gens par ailleurs rationnels débattaient de la durée des sprints avec la passion de constitutionnalistes débattant d'amendements. J'ai vu des équipes échouer avec Scrum et conclure "l'agile ne fonctionne pas", alors que le vrai problème était qu'elles utilisaient un marteau sur une vis.
Voici ce que j'ai appris après des années à diriger et conseiller des équipes d'ingénierie : la méthodologie importe bien moins que de savoir si elle correspond à votre type de travail, la maturité de l'équipe et le stade du produit. Scrum n'est pas meilleur que Kanban. Kanban n'est pas meilleur que Scrum. Le bon est celui qui aide votre équipe spécifique à livrer de la valeur avec le moins de friction.
Comprendre la Différence Fondamentale
Scrum est un framework construit autour d'itérations de durée fixe (sprints). L'équipe s'engage sur un périmètre de travail au début de chaque sprint, y travaille pendant 1 à 4 semaines et livre un incrément potentiellement publiable à la fin. Il vient avec des rôles prescrits (Product Owner, Scrum Master, Équipe de Développement) et des cérémonies (planification du sprint, standup quotidien, revue du sprint, rétrospective).
Kanban est une méthode construite autour du flux continu. Il n'y a pas d'itérations. Les éléments de travail entrent dans un tableau, se déplacent à travers des étapes, et sortent quand ils sont terminés. Le mécanisme central sont les limites de WIP — des plafonds sur le nombre d'éléments pouvant être dans une étape simultanément.
La différence fondamentale : Scrum regroupe le travail en boîtes de temps. Kanban traite le travail comme un flux continu.
Quand Scrum Convient
Scrum fonctionne mieux quand votre équipe a besoin de rythme, de prévisibilité et de cycles de planification structurés :
- Développement produit avec des jalons clairs
- Équipes qui ont besoin de responsabilité externe
- Équipes nouvelles ou en formation
- Travail transverse avec des dépendances
Quand Kanban Convient
Kanban fonctionne mieux quand votre travail est continu, variable en taille et piloté par les interruptions :
- Maintenance et opérations
- Équipes de support et SRE
- Équipes avec des taux d'interruption élevés (plus de 30% de travail non planifié)
- Équipes matures et auto-organisées
Le Cadre de Décision
Choisissez Scrum quand :
- Le travail est principalement planifié (plus de 70% de la capacité)
- L'équipe est nouvelle ou récemment réorganisée
- Les parties prenantes ont besoin de cadences de livraison prévisibles
- Le produit est en développement actif
- L'équipe compte 3 à 7 personnes
Choisissez Kanban quand :
- Le travail est principalement réactif (plus de 50% est non planifié)
- L'équipe gère plusieurs types de travail
- Le cycle time compte plus que la prévisibilité
- L'équipe est mature et auto-organisée
Considérez Scrumban (hybride) quand :
- Vous avez un mélange de travail planifié et non planifié
- Vous voulez le rythme des sprints mais le flux de Kanban
- Votre équipe est en transition
Scrumban : le Juste Milieu Pratique
En pratique, la plupart des équipes avec lesquelles je travaille finissent par pratiquer une version de Scrumban :
- Cadence de sprint pour la planification et les rétros. Vous avez encore des cycles de deux semaines pour la planification, la revue et la rétrospective.
- Tableau Kanban avec limites de WIP pour l'exécution quotidienne. Au lieu d'un backlog de sprint rigide, le travail s'écoule à travers le tableau.
- Pas d'engagement de sprint — un objectif de sprint à la place. L'équipe a un objectif mais pas une liste rigide d'histoires engagées.
- Métriques des deux mondes. Suivre la vélocité pour la planification de la capacité et le cycle time pour l'efficacité du flux.
La Variable Réelle : Maturité de l'Équipe
Les équipes immatures luttent avec Kanban parce qu'il exige de l'autodiscipline. Les équipes matures luttent avec Scrum parce que l'overhead ressemble à de la bureaucratie.
La progression que je vois le plus souvent : commencer avec Scrum, évoluer vers Kanban à mesure que l'équipe mûrit, s'établir sur un hybride Scrumban.
Erreurs Courantes
- Faire Scrum sans rétrospectives
- Faire Kanban sans limites de WIP
- Changer de méthodologie pendant une crise
- Adhérence rigide au framework
Chez Conectia, nos ingénieurs ont travaillé avec les trois approches, car la réalité du travail de conseil senior est que vous vous adaptez à ce qui fonctionne pour l'équipe.
Besoin d'ingénieurs senior qui s'adaptent à votre processus plutôt que de le combattre ? Parlez à un CTO — nos ingénieurs LATAM s'intègrent à votre flux de travail, que vous utilisiez Scrum, Kanban ou quelque chose entre les deux.
