« Kanban ou Scrum ? » est la question la plus fréquente en début de journée. La réponse tient au type de travail, pas à une préférence de méthode.
Ce qui les différencie vraiment
Scrum organise le travail en itérations de durée fixe, avec un engagement pris au début et un incrément livré à la fin. Kanban n'a ni itération ni engagement de périmètre : il régule le flux continu en limitant ce qui est en cours.
Scrum définit des rôles et des cérémonies obligatoires. Kanban n'en impose aucun, et se superpose à l'organisation existante. C'est ce qui le rend adoptable sans réorganisation.
Le rapport au temps
Scrum découpe le temps pour créer un rythme ; Kanban mesure le temps pour révéler les blocages. Dans un sprint, la question est « tiendra-t-on l'engagement ? ». En Kanban, elle est « combien de temps une demande met-elle à traverser, et où attend-elle ? ».
Comment choisir
Si votre travail arrive par vagues imprévisibles, si les priorités changent en cours de semaine, si vous traitez des demandes plutôt que des lots, Kanban est le bon point de départ. Si vous construisez un produit par incréments planifiables avec une équipe stable, Scrum a du sens.
Et les deux ensemble
C'est courant, et souvent mal fait : on garde les cérémonies de Scrum en ajoutant un tableau, sans limiter le travail en cours. On obtient alors la charge des deux méthodes et l'effet d'aucune. Sans limite de WIP, un tableau n'est qu'une liste de tâches affichée au mur.