Scrum et Kanban sont deux termes qui sont souvent utilisés (à tort) de manière interchangeable ou considérés comme les deux faces d’une même pièce. En réalité, il existe des différences importantes entre ces deux méthodologies Agile. Comprendre ces différences est essentiel pour choisir le chemin qui fonctionnera le mieux pour votre environnement.
Au menu de cet article :
- Qu’est-ce que Scrum en 3 mots ?
- Qu’est-ce que Kanban en 3 mots ?
- Quelles sont les différences en termes de planification et de cadence en Scrum et en Kanban ?
- Comment sont structurées les équipes en Scrum et en Kanban ?
- Quelles sont les différences entre le Scrum board et le Kanban board ?
- Quelle méthodologie va le mieux correspondre à vos besoins ?
1- Qu’est-ce que Scrum en 3 mots ?
Scrum est une méthodologie utilisée pour :
- organiser le travail en petits morceaux plus gérables
- qui peuvent être complétés par une équipe pluri-fonctionnelle (idéalement autour de 7 personnes)
- dans un délai prescrit appelé Sprint (généralement de 2 à 4 semaines)
Pour planifier, organiser, administrer et optimiser ce processus, Scrum s’appuie sur au moins trois rôles bien définis :
- Product Owner (PO) : responsable de la planification initiale, des priorités et de la communication avec le reste de l’entreprise
- Scrum Master : responsable de la supervision du processus lors de chaque Sprint
- Les membres de l’équipe : responsables de la réalisation de l’objectif de chaque Sprint, tels que la production de code logiciel (ex : les développeurs, les designers UX…)
Parmi les outils principaux utilisés par les équipes Scrum, on retrouve le Scrum Board – une représentation visuelle du flux de travail. Les petits morceaux du projet (tâches) à développer sont appelés des User Stories, qui se déplacent le long du tableau depuis le Backlog (la liste des tâches), vers le travail en cours (WIP, Work in Progress), jusqu’à la fin du tableau et des tâches terminées.
2- Qu’est-ce que Kanban en 3 mots ?
Kanban est également un outil utilisé pour organiser le travail dans un souci d’efficacité. Comme Scrum, Kanban décompose le projet en petits morceaux plus gérables et utilise un tableau (très similaire au Scrum board, d’où peut-être la confusion…) pour visualiser les tâches à mesure qu’elles progressent dans le flux de travail.
Là où Scrum limite le temps accordé pour accomplir un nombre de tâches, Kanban limite le nombre de tâches maximum qui peuvent être traitées en même temps.
Les deux méthodologies permettent de décomposer et de terminer efficacement des tâches volumineuses et complexes. Elles accordent aussi une grande valeur à l’amélioration continue du processus et focalisent sur un management de projet visuel et visible par tous les membres de l’équipe, qui est informée en coup de d’oeil des tâches en cours et à venir.
3- Quelles sont les différences en termes de planification et de cadence entre Scrum et en Kanban ?
Le système Scrum met fortement l’accent sur le respect du timing des Sprints et « impose » donc un processus précis à suivre jalonné de « cérémonies Scrum ». Très schématiquement :
- Le Product owner rédige les User Stories car il a la vision business et sait quelles fonctionnalités d’une application doivent être développées en priorité
- L’équipe Scrum attribue un nombre de points à chaque Story et à chaque Sprint. Par exemple, elle peut estimer que développer la Story « Ajouter un article au panier » comptera pour 3 points et qu’elle ne pourra accepter des Stories qu’à hauteur de 30 points pour le prochain Sprint
- L’équipe Scrum développe techniquement les Stories. Elle se réunit tous les matins pour faire le point (Daily meeting).
- A la fin du Sprint, une démonstration est organisée pour montrer au client les fonctionnalités développées (Review)
- Puis l’équipe Scrum debriefe (Retrospective)
L’idée étant de livrer un produit utilisable/vendable à chaque Sprint et de rajouter des fonctionnalités au fur et à mesure des Sprints, le schéma Scrum ressemble donc à une suite de boucles (itérations) répétant développement > livraison > test > feed-back > amélioration.
.
Le système Kanban, quant à lui, n’impose pas de rythme et met la priorité sur l’arrivée des Stories en un flux stable et constant. Il n’y a donc pas de Sprint et de Sprint Backlog (pas un nombre prédéfini de Stories à livrer dans un temps prédéfini).
Quand une Story bouge sur le Kanban Board, une autre prend sa place dans la limite de la capacité définie par l’équipe.
Kanban permet aussi plus de flexibilité en cas de changement impromptu. En effet, en Scrum, seules les Stories allouées au Sprint peuvent être développées pendant ce Sprint. En Kanban, les Stories peuvent être allouées ou « dé-allouées » selon le besoin et l’urgence, à n’importe quel moment.
Enfin pour terminer ce bref comparatif, il n’y a pas non plus de démonstration planifiée à intervalles réguliers et obligatoires comme en Scrum à chaque fin de Sprint ; Kanban base la livraison/démonstration sur les besoins ou à la demande.
4- Comment sont structurées les équipes en Scrum et en Kanban ?
Comme nous l’avons vu plus haut, dans les équipes Scrum, il y a au moins trois rôles qui doivent être attribués pour traiter efficacement le travail: le Product Owner, le Scrum Master et les membres de l’équipe. Chaque rôle a son propre ensemble de responsabilités, et ils doivent travailler ensemble pour atteindre un équilibre ordonné et efficace.
L’équipe Scrum doit également être cross-fonctionnelle, c’est-à-dire qu’une équipe doit disposer de toutes les ressources nécessaires pour terminer l’ensemble du travail des Sprints.
.
En Kanban, aucun rôle défini n’est obligatoire.
En pratique, il est relativement logique que quelqu’un serve de chef de projet ou de superviseur, en particulier pour des projets d’envergure ou complexes. Mais les rôles doivent théoriquement évoluer avec les besoins du projet et de l’organisation.
Une équipe Kanban n’est pas tenue d’être cross-fonctionnelle car le flux de travail Kanban est destiné à être utilisé par toutes les équipes impliquées dans le projet. Par conséquent, il n’est pas obligatoire de n’avoir qu’une seule équipe qui réunit toutes les compétences et partage toutes les tâches et responsabilités. Il est possible de faire travailler ensemble une équipe de spécialistes et une équipe distincte de généralistes sur différents aspects du même projet à partir du même tableau Kanban.
5- Quelles sont les différences entre le Scrum board et le Kanban board ?
Bien que vraiment très similaires, à première vue, le Scrum Board et le Kanban Board sont différents.
Sur un tableau Scrum (ou Sprint Board) :
- les colonnes découpent généralement le flux de travail en « A faire » (qui correspond au Sprint Backlog), « En cours », « En test », « Fini »,
- en début de Sprint, toutes les User Stories prédéfinies pour ce Sprint sont placées dans la colonne « A faire ». A la fin du Sprint, elles doivent toutes se retrouver dans la colonne « Fini » ou le Sprint sera considéré comme échoué,
- après la démonstration et la rétrospective du Sprint, le tableau est effacé et préparée pour le sprint suivant.
Sur un tableau Kanban :
Les colonnes indiquent également les états du flux de travail mais avec des différences essentielles :
- elles indiquent également le nombre maximal de Stories autorisées dans chaque colonne
- les colonnes peut-être divisée en « sous-colonnes » pour préciser l’état de la tâche
- il est possible d’y faire plusieurs lignes pour « classer » les tâches par demandes
Comme il n’y a pas de limitation de temps (pas de Sprint), les Stories arrivent au fur et à mesure selon leurs points et dans la limite autorisée par colonne (voire par ligne).
Le tableau n’est pas effacé à intervalle régulier car il n’y a pas de Sprint. Il reste rempli aussi longtemps que le projet progresse.
Le Kanban Board peut-être beaucoup plus compliqué qu’un Scrum Board, il convient donc de bien y réfléchir à l’avance pour que les équipes de développement puissent s’y retrouver facilement.
6- Scrum vs. Kanban, quelle méthodologie va le mieux correspondre à vos besoins ?
Scrum et Kanban sont des outils de processus puissants et éprouvés qui peuvent considérablement améliorer la gestion de votre projet. La meilleure option est de se familiariser avec les deux et d’expérimenter différents aspects des deux dans votre environnement de production. Il peut aussi être intéressant d’utiliser un hybride des deux et de passer en Scrumban (ce que font de nombreuses équipes).
SCRUM | KANBAN | |
---|---|---|
Fonctionnement | Cycles itératifs de 2 à 4 semaines | Flow de travail continu |
Processus bien défini à respecter | Cérémonies de Sprint | Non |
Equipe à constituer pour l’occasion | Oui : Product Owner, Scrum Master, Equipe Scrum | Non, plusieurs équipes distinctes peuvent travailler ensemble |
Outil de management visuel | Scrum board (simple) | Kanban board (simple à très complexe) |
Démonstration du produit régulièrement | A la fin de chaque Sprint (toutes les 2 à 4 semaines) | A la demande |
Flexibilité | Autorise relativement peu de changements, seules les Stories attribuées peuvent être développées par Sprint.
Pour des équipes qui ont des priorités stables et qui ne changeront pas (trop) dans le temps |
Les tâches peuvent rentrer et sortir du tableau de flux de travail plus facilement.
Intéressant pour des projets avec des priorités qui diffèrent de manière assez importante |
Laisser un commentaire