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.