Scrum ou Kanban? Une méthode concrète pour bien choisir
Au milieu de 2021, bien des équipes avaient passé un an à travailler depuis la table de cuisine ou une chambre d'amis, et nombre d'entre elles se sont tournées vers un cadre agile pour garder la cadence pendant que tout le reste vacillait. La question revenait sans cesse : faut-il faire du Scrum ou du Kanban? La réponse honnête est qu'ils ne sont pas rivaux. Scrum est un cadre avec des rôles, des événements définis et un Sprint de durée fixe; Kanban est une méthode pour visualiser et limiter le travail en cours afin qu'il s'écoule. Bien choisir commence par comprendre le travail devant soi, pas par choisir un camp.
Ce à quoi ressemble une bonne pratique
Les bonnes équipes choisissent l'approche qui correspond à la nature de leur travail. Une équipe produit qui vise un objectif et peut s'engager sur un lot de travail ciblé pour une ou deux semaines s'épanouit souvent avec Scrum : le Sprint crée un rythme régulier, la revue de Sprint offre un point de contrôle aux parties prenantes, et la rétrospective force une amélioration honnête. Une équipe qui gère un flux constant de demandes imprévisibles — soutien, exploitation, gestion des incidents — réussit en général mieux avec Kanban, où les limites de travail en cours évitent la surcharge et où le temps de cycle devient la mesure qui compte.
Scrum choisi parce que l'équipe peut tenir un objectif de Sprint pendant le Sprint, et non parce que la direction aime le mot
Kanban choisi avec des limites de travail en cours explicites et une politique de circulation des éléments, pas seulement un tableau couvert de papiers collants
Une définition claire de « terminé » dans les deux cas, pour que « fini » veuille dire la même chose pour tout le monde
Des mesures utilisées pour apprendre — tendances de vélocité en Scrum, temps de cycle et débit en Kanban — plutôt que pour classer les personnes
Ce à quoi ressemble une mauvaise pratique
Les adoptions ratées partagent souvent un signe : l'équipe a copié les cérémonies mais a oublié leur raison d'être. Nous avons vu des équipes « Scrum » dont le backlog change en plein Sprint un jour sur deux, ce qui détruit la concentration que le Sprint est censé protéger. Nous avons vu des tableaux « Kanban » avec quarante cartes dans la colonne En cours et aucune limite, soit une simple liste de tâches peinte en trois couleurs. Dans les deux cas, on blâme le cadre alors que le vrai problème est que personne n'a changé la façon de décider.
Scrum de façade. Les mêlées quotidiennes deviennent des réunions de statut pour un gestionnaire, l'objectif de Sprint manque, et le Sprint devient un compte à rebours plutôt qu'un engagement.
Kanban sans bornes. Le tableau visualise le travail mais ne fixe aucune limite de travail en cours; on commence tout et on termine peu, et le flux ne s'améliore jamais faute de contrainte.
Théâtre du cadre. L'équipe applique chaque événement à la lettre mais traite la rétrospective comme facultative, si bien que les mêmes problèmes reviennent Sprint après Sprint.
Un test utile : si votre travail arrive par à-coups imprévisibles et que les priorités changent d'heure en heure, la cadence d'un Sprint vous combattra, et le flux continu du Kanban sera plus clément. Si votre équipe a besoin d'un objectif commun et de temps protégé pour l'atteindre, la structure de Scrum vaut son prix. Beaucoup d'équipes mûres finissent par mélanger les deux — en tenant les événements Scrum tout en appliquant des limites de travail en cours à leur flux — mais elles méritent ce mélange en maîtrisant d'abord l'un des deux.
Que vous montiez une équipe de livraison pour la première fois ou que vous démêliez un cadre qui ne vous sert plus, le conseil en livraison de programmes et de projets de XNM peut vous aider à choisir et à mener l'approche qui convient à votre travail.