Les trois vraies options

Scrum fonctionne mieux lorsque votre équipe livre des fonctionnalités selon une cadence prévisible. Les sprints de deux semaines forcent une conversation de planification tous les quatorze jours, une démo qui rend les progrès visibles et une rétrospective qui fait remonter les frictions avant qu'elles ne se figent. Vous obtenez des rôles définis — un propriétaire de produit qui garde le backlog, un scrum master qui garde le processus et des développeurs qui gardent l'engagement.

La structure est le but. Les équipes produit qui construisent vers des objectifs trimestriels ont besoin du rythme de « nous avons planifié ces huit tickets, nous en avons terminé sept, voici pourquoi ». Les parties prenantes obtiennent des prévisions ancrées dans la vélocité historique plutôt que des suppositions optimistes. Les développeurs obtiennent la permission de dire « ce n'est pas dans ce sprint » sans combat politique.

Le coût de Scrum est la rigidité. Les changements de périmètre en milieu de sprint sont coûteux. Les cérémonies prennent du temps réel — une équipe de six personnes passera 4 à 6 heures par sprint en rituels. Si votre travail est piloté par les interruptions ou que vos priorités changent quotidiennement, cette rigidité devient un frein plutôt qu'un levier.

Kanban optimise le débit dans les environnements où le travail n'attendra pas la limite de votre sprint. Un ticket de support escaladé à 14 h ne se soucie pas que votre planification de sprint ne soit que jeudi. Kanban dit : visualisez le travail, limitez la quantité en cours à la fois et tirez l'élément de priorité la plus élevée suivant lorsque la capacité se libère.

Le tableau est le système. Les colonnes représentent les étapes (À faire, En cours, Révision, Terminé), et les limites WIP plafonnent le nombre de tickets pouvant se trouver simultanément dans n'importe quelle colonne. Une équipe de 3 personnes avec une limite WIP de 4 sur « En cours » ne peut pas commencer un nouveau travail tant que quelque chose n'avance pas. Cette contrainte est ce qui fait de Kanban plus qu'une liste de tâches — elle force l'équipe à terminer avant de commencer.

Kanban convient aux équipes d'opérations, aux équipes de plateforme et à tout groupe dont le travail entrant est imprévisible dans le temps mais relativement uniforme en taille. Il fonctionne également bien comme tremplin — les équipes incertaines à propos de Scrum peuvent exécuter Kanban pendant un mois pour développer des habitudes de flux avant de superposer les sprints.

Toutes les équipes n'ont pas besoin d'une méthodologie maintenant. Une équipe de 3 personnes assise dans la même pièce, livrant un produit, avec un backlog court et une conversation quotidienne — cette équipe a déjà des boucles de rétroaction. Ajouter des cérémonies de sprint ou des tableaux Kanban par-dessus ne crée pas de valeur ; cela crée des frais généraux pour les frais généraux.

Les fondamentaux de ce cours — discipline du contrôle de source, tickets significatifs, estimation de base et compréhension partagée de ce que signifie « terminé » — suffisent pour bien livrer pour les équipes où le coût de coordination est faible. Le signal que vous avez besoin de plus de structure n'est pas « nous avons lu sur Scrum et cela semble professionnel ». C'est une douleur concrète : transferts manqués, surprises chroniques au moment de la démo, travail qui reste inactif parce que personne ne savait qu'il était bloqué, ou nouveaux membres de l'équipe qui ne peuvent pas monter en compétence sans une semaine d'observation.

Si ces problèmes ne se produisent pas, restez ici. Revisitez cette décision dans trois mois ou lorsque l'équipe dépasse cinq personnes.