La culture Agile et de nombreux termes qui lui sont associés – comme SCRUM et KANBAN – peuvent être difficiles à discerner.
Quelle est alors la différence entre SCRUM et KANBAN ?
Dans cet article, je vais décomposer ces notions pour vous aider à mieux comprendre ce qu’elles signifient.
Mais si le mode agile est nouveau pour vous, je vous recommande de commencer d’abord par ces articles:
Agile, SCRUM et KANBAN : 3 méthodologies différentes?
Les méthodologies dans le monde du développement numérique sont des scripts détaillés à suivre.
Si une situation se présente, une méthodologie présentera une documentation décrivant étape par étape, les actions à réaliser de manière stricte.
Mettre en application une méthodologie bride la créativité. L’autonomie et la réflexion sont remplacées par des tâches, des pratiques, des techniques et des outils indispensables.
En effet, les méthodologies dépendent de la prévisibilité d’une situation. Si les événements sont imprévisibles alors, cela nous amène à nous détacher de la documentation existante pour réfléchir par nous-même et innover.
De plus, les méthodologies traditionnelles sont fondées sur la planification et l’exécution des développements avec un haut degré de prévisibilité. Ce qui, en pratique, ne peut pas être appliqué puisque les développements ne peuvent être anticipés de manière précise.
C’est pour cela que la pensée Agile a été développée.
On entend beaucoup les termes “Méthodologies Agiles”, cependant, ce sont des termes génériques pour décrire une philosophie.
Découvrez dans cet article ce qu'est le Manifeste Agile.
Scrum et Kanban, quant à eux, sont deux cadres de travail qui permettent d’appliquer la pensée Agile.
Ce qui signifie que si vous vous voulez développer des produits avec une philosophie Agile, alors, Scrum et Kanban sont deux “façons de le faire”.
Qu’est ce que SCRUM et KANBAN ?
Le terme « Agile » est donc un terme globale et non une méthodologie, mais qu’est ce qu’il en est de SCRUM et KANBAN ?
Définition de SCRUM
Le guide SCRUM le définit comme étant:
« Un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive et créative des produits de la plus haute valeur possible. »
C’est une manière d’appliquer la pensée agile en mettant l’accent sur le travail d’équipe et la progression itérative du produit. Son objectif est de fournir des nouvelles fonctionnalités toutes les deux à quatre semaines.
En utilisant Scrum, l’équipe de développement découpe facilement son produit en tâches. Elle devient plus agile et découvre comment réagir rapidement et répondre aux imprévus.
Scrum propose de suivre une routine durant chaque itération ou sprint :
- les daily scrum meetings ou DSM tous les jours
- une planification de sprint en début d’itération
- une rétrospective de sprint à la fin.
Nous reviendrons sur la routine SCRUM dans un article dédié.
Définition de KANBAN
Kanban a été initialement développé par Taiichi Ohno, ingénieur industriel chez Toyota, pour créer un processus de fabrication plus efficace.
Il a ensuite été appliqué au développement de produits par David J. Anderson dans son livre de 2010 Kanban: Successful Evolutionary Change for Your Technology Business.
Comme Scrum, Kanban encourage le travail à être décomposé en petites tâches.
Mais plutôt que de planifier le travail dans une itération ou un Sprint, les membres de l’équipe récupèrent la tâche la plus prioritaire dans le backlog qui est prête à être développée.
Les équipes vont utiliser un tableau Kanban pour visualiser ce travail à mesure qu’il progresse dans le flux de travail.
Il permet d’illustrer à la fois un processus et chaque fonctionnalité passant par ce processus.
L’objectif principal de la mise en œuvre de Kanban est d’identifier les goulets d’étranglement potentiel dans le processus et de les corriger.
Les équipes mettent en place KANBAN pour que le flux de travail se déroule sans problème à une vitesse optimale.
Dans ce tableau, le cadre Kanban limite la quantité de tâches autorisée dans chaque colonne.
Imaginons que seulement trois tâches peuvent être dans la colonne “en cours” et une dans la catégorie “à tester.”
Généralement, les développeurs sont connus pour préférer développer que tester, ici, Kanban les oblige à tester les tâches dans la catégorie “à tester” avant de démarrer un nouveau développement.
La méthodologie Kanban est conçue pour répondre à la problématique d’embouteillage dans une catégorie donnée.
KANBAN propose un processus à suivre.
1. Visualiser le travail
En créant un modèle visuel pour observer les tâches se déplaçant à travers les colonnes du tableau Kanban.
2. Limiter le travail en cours
Cela permet de réduire le temps que met une tâche à traverser entièrement le tableau en partant de la première colonne jusqu’à la colonne “terminé”.
3. Se concentrer sur le flux
En utilisant des limites de travail en cours et en développant des politiques axées sur l’équipe, vous pouvez optimiser le système Kanban pour améliorer la fluidité du travail.
4. S’améliorer en continu
Lorsque le système Kanban est en place, il sert de base à une amélioration continue. Il aide les équipes à mesurer leur efficacité en analysant le flux de suivi, les délais de qualification, etc.
La différence entre SCRUM et KANBAN : les 5 notions majeures
Scrum et Kanban sont tous les deux des systèmes itératifs qui reposent sur des flux de processus. Cependant, il existe quelques différences principales entre les deux:
Les rôles dans Scrum et Kanban
Dans Scrum, il y a un ensemble de rôles à implémenter. Voici les trois principaux :
- Le Product Owner qui est en charge du backlog et oriente l’équipe
- Le Scrum Master aide l'équipe à respecter les cérémonies Scrum et à lever tout blocage, sans dicter les délais
- Les développeurs qui traitent le travail convenu lors de la planification du Sprint.
Je vous présenterai ces rôles plus en détails dans un prochain article.
Kanban, quant à lui, vous permet de conserver votre structure actuelle sans apporter de changements drastiques. Il est conseillé de les implémenter, mais ils ne sont en aucun cas obligatoires :
- Le gestionnaire de prestation de services qui est chargé de veiller à ce que le flux soit en continu et qu’il n’y ait pas d’embouteillage parmi les tâches
- Le gestionnaire de demande de service qui a le rôle du chef d’équipe.
Les engagements dans Scrum et Kanban
Les équipes Scrum doivent s’engager sur une quantité spécifique de travail.
Il est important d’identifier toutes les tâches, de les hiérarchiser et de les estimer selon la valeur qu’elles apportent au produit.
L’engagement est facultatif pour les équipes suivant le cadre Kanban. Ainsi, les équipes travaillent à leur vitesse. Parfois, elles peuvent livrer plus tandis que d’autres fois, elles peuvent livrer moins dans la même durée.
Les cadences dans Scrum et Kanban
Les cadences sont des éléments importants de Scrum et Kanban. Pourtant, la façon dont elles sont mises en œuvre est différente.
Dans Scrum, elles sont définies par la longueur de chaque Sprint. Un Sprint typique dure deux semaines. Si chaque élément intégré dans le sprint est terminé, le sprint est considéré comme réussi.
Une fois l’itération terminée, le cycle redémarre immédiatement.
Dans Kanban, les cadences sont principalement liées aux réunions et sont facultatives.
Comme votre objectif est de maintenir un flux de travail continu, les cadences sont suggérées par des échanges entre les membres de l’organisation.
Les itérations : Scrum Vs Kanban
Étant donné que Scrum met fortement l’accent sur l’engagement de l’équipe, de nouveaux éléments ne peuvent pas être ajoutés en cours d’itérations.
Ce n’est que lorsque le sprint en cours est terminé que les tâches peuvent être intégrées dans le nouveau sprint.
Avec Kanban, de nouvelles tâches peuvent être ajoutées en permanence.
Lorsqu’une tâche passe du stade « en cours » au stade « terminée », une nouvelle tâche peut prendre immédiatement sa place.
Les équipes : Scrum Vs Kanban
Un backlog de sprint n’appartient qu’à une seule équipe à la fois. Scrum encourage les équipes multifonctionnelles. Chaque équipe possède toutes les compétences nécessaires pour réussir toutes les tâches pendant le sprint.
En comparaison, les tableaux Kanban peuvent être partagés par plusieurs équipes. Chacun est dédié à ses propres tâches.
En conclusion
J’espère que vous comprenez mieux la différence entre Scrum et Kanban. Mais lequel de ces deux cadres doit-on choisir pour notre produit?
Il n’y a pas de réponse exacte à cette question…
Chaque produit est différent ainsi que chaque entreprise. Certains choisiront KANBAN pour sa flexibilité (si leurs priorités changent souvent par exemple) et d’autres SCRUM pour sa priorisation et sa cadence.
Et si la meilleure solution était de fonctionner en SCRUMBAN ?
Faire du SCRUMBAN c’est combiner le meilleur des avantages des deux cadres.
Des équipes SCRUM vont utiliser un tableau KANBAN pour fluidifier leur flux.
Dites-moi en commentaire si vous voulez lire un article dédié au cadre SCRUMBAN !
« une fois le sprint démarré, pas de possibilité d’ajouter des tâches à développer ». La théorie est beaucoup plus nuancée, les ajouts sont possibles mais dans certaines conditions, heureusement
Bonjour Damien,
Merci pour ton feedback.
Je suis tout à fait d’accord avec toi. Nous allons corriger l’illustration.
Mohammed