Scrum ou Kanban ? Guide du débutant pour choisir ce qui convient
Les équipes qui découvrent l'agilité demandent souvent si elles devraient utiliser Scrum ou Kanban, comme si l'un avait raison et l'autre tort. La réponse honnête, c'est qu'il s'agit d'outils différents pour des situations différentes. Comprendre ce que chacun est vraiment, plutôt que les slogans qui les entourent, rend le choix simple.
Ce qu'est chacun
Scrum, tel que défini par le Guide Scrum sur scrum.org, est un cadre bâti autour d'itérations de durée fixe appelées Sprints, généralement d'une à quatre semaines. L'équipe s'engage sur un objectif de Sprint, travaille à partir d'un Backlog de produit ordonné par un Product Owner et se réunit selon un rythme défini : la planification de Sprint, la mêlée quotidienne, la revue de Sprint et la rétrospective de Sprint. Trois responsabilités portent le travail : le Product Owner, le Scrum Master et les Développeurs. L'idée est une cadence régulière d'inspection et d'adaptation, livrant un incrément utilisable à chaque Sprint.
Kanban est plus léger. Il ne prescrit ni rôles, ni itérations, ni cérémonies. Il visualise plutôt le flux de travail sur un tableau, limite ce qui peut être en cours en même temps et gère le débit de l'équipe. Ses deux pratiques centrales sont de rendre le travail visible et de plafonner le travail en cours, afin que l'équipe termine les choses avant d'en commencer de nouvelles, au lieu de tout jongler à demi-attention.
Comment les distinguer en pratique
Scrum fonctionne en blocs de temps ; Kanban fonctionne en flux continu, sans cycle imposé.
Scrum définit des rôles et des événements ; Kanban n'ajoute rien à vos rôles ou réunions existants.
Scrum limite le travail à ce qui tient dans un Sprint ; Kanban le limite directement par des plafonds explicites de travail en cours.
Scrum est conçu pour une livraison de type produit vers un objectif ; Kanban convient à un flux régulier de demandes variées.
Choisir sans dogme
Optez pour Scrum quand le travail peut se planifier en objectifs, que l'équipe est raisonnablement stable et qu'un rythme de livraison régulier aide les parties prenantes. Le développement de nouveaux produits et la livraison de fonctionnalités s'y prêtent bien. Optez pour Kanban quand le travail arrive de façon imprévisible et doit être traité au fil de l'eau, comme le soutien, l'exploitation ou la maintenance, où s'engager à l'avance sur un périmètre de deux semaines relèverait de la fiction.
Observez comment le travail arrive. Planifiable par lots oriente vers Scrum ; un filet constant de demandes variées oriente vers Kanban.
Évaluez votre goût pour la structure. Si des rôles clairs et un rythme fixe aidaient une équipe en formation, Scrum offre cet échafaudage clé en main.
Tenez compte de votre point de départ. Kanban peut se superposer à ce que vous faites déjà, ce qui en a fait une option en douceur pour les nombreuses équipes s'adaptant au télétravail et au mode hybride sans tout réorganiser d'un coup.
Rien n'est verrouillé. Beaucoup d'équipes commencent par Kanban pour mettre de l'ordre dans le chaos, puis adoptent Scrum une fois le travail assez planifiable pour fixer des objectifs, ou combinent les deux en utilisant un tableau et des plafonds de travail en cours à l'intérieur des Sprints. Le cadre est un moyen, pas la récompense. Le véritable but est une équipe qui termine un travail de valeur à un rythme soutenable et améliore sa façon de travailler en cours de route.
Si votre équipe se demande comment organiser sa livraison, le service-conseil en réalisation de programmes et de projets de XNM peut vous aider à adapter l'approche au travail et à la mettre en pratique.