Scrum, Kanban ou Scrumban : choisir selon le contexte

Informatique de gestion · Bachelor 3

Comparaison de Scrum et Kanban, hybride Scrumban et critères de choix selon le travail.

Introduction

Scrum et Kanban partagent une philosophie agile (livraison fréquente, amélioration continue, visualisation du travail), mais ils s'organisent différemment. Scrum fonctionne par itérations de durée fixe (sprints) avec trois rôles (Product Owner, Scrum Master, développeurs), des événements définis et un engagement de l'équipe sur un objectif de sprint. Kanban n'impose ni rôles ni itérations : il part du processus existant, rend le travail visible et limite le travail en cours, avec un flux continu.

Le choix dépend de la nature du travail. Scrum convient à un développement de produit avec des objectifs à échéance, des fonctionnalités à découper et une équipe stable. Kanban convient mieux à la maintenance, au support ou à l'exploitation, où les demandes arrivent de façon imprévisible et doivent être traitées à mesure. Changer les priorités en cours de sprint est découragé en Scrum, alors que Kanban l'admet naturellement, dans la limite du WIP.

Scrumban combine les deux : sprints ou cadence régulière, plus tableau avec limites de WIP et réapprovisionnement à la demande. Il sert souvent de transition ou aux équipes mixtes développement-maintenance. Aucun cadre n'est universel, et une adoption mécanique sans comprendre les principes tourne au rituel vide.

Objectifs d'apprentissage

  • Comparer rôles, événements et mesures de Scrum et Kanban
  • Choisir une approche selon le type de travail
  • Décrire Scrumban et ses usages
  • Expliquer le traitement des changements de priorité
  • Reconnaître les risques d'une adoption mécanique

Concepts clés

Cadence versus flux
Scrum découpe le temps en sprints ; Kanban fait circuler le travail en continu.
Engagement
Scrum : objectif de sprint ; Kanban : respect des limites de WIP.
Rôles
Scrum a des rôles définis ; Kanban n'en impose pas.
Scrumban
Hybride : tableau et WIP avec cadence régulière.
Nature du travail
Produit planifié ou demandes imprévisibles ?

Conclusion

Scrum et Kanban ne s'opposent pas : l'un cadence, l'autre fluidifie. Le bon choix vient de la nature du travail, de la prévisibilité des demandes et de la maturité de l'équipe.

Scrumban offre un chemin intermédiaire, à condition de garder les principes qui donnent du sens aux pratiques.

Cartes

Quelle est la différence de rythme entre Scrum et Kanban ?
Scrum utilise des itérations de durée fixe ; Kanban fonctionne en flux continu.
Quels rôles Scrum définit-il ?
Product Owner, Scrum Master et développeurs.
Kanban impose-t-il des rôles ?
Non, il s'applique au processus existant sans rôles prescrits.
Quelle mesure suit-on typiquement en Scrum et en Kanban ?
Scrum : vélocité et burndown ; Kanban : lead time, cycle time, débit.
Comment chaque cadre traite-t-il une demande urgente ?
Scrum la place en général au prochain sprint ou discute avec le PO ; Kanban l'insère via une classe de service dans la limite du WIP.
Pour une équipe de support, que choisir ?
Plutôt Kanban : les demandes arrivent de façon imprévisible et sont traitées en flux.
Pour un nouveau produit avec jalons ?
Plutôt Scrum : objectifs de sprint, démonstrations régulières et priorisation du backlog.
Qu'est-ce que Scrumban ?
Un hybride qui garde une cadence (planification, rétrospectives) et utilise tableau, WIP et flux à la demande.
Quel danger dans une adoption mécanique ?
Appliquer des rituels sans comprendre leur finalité, ce qui crée des réunions vides et peu de valeur.

Glossaire

Sprint
Itération de durée fixe pour livrer un incrément.
Flux continu
Travail tiré sans itérations imposées.
Scrumban
Mélange de Scrum et de Kanban.
Limite de WIP
Plafond du travail en cours.
Vélocité
Quantité de travail livrée par sprint.
Classe de service
Catégorie de demande avec règles de traitement propres.