Découvrons ensemble les principaux aspects de Kanban et de Scrum pour savoir quand utiliser l’un ou l’autre dans votre quotidien.

Scrum

Scrum est-ce qu’on appelle un cadre de travail ou Framework Agile (lire notre article dédié pour découvrir ce framework).

Sa définition, que l’on retrouve dans le Scrum Guide, est la suivante :

“Scrum est un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes.”

Le terme Scrum signifie « mélée » en anglais et reprend l’image d’une équipe de rugby qui avance vers un objectif commun.

Kanban

Pour bien comprendre ce framework, découvrez notre article dédié. Kanban nous vient directement du Japon et signifie « carte signal ».

Il permet de visualiser les activités dans un flux, via un Kanban board, tout en limitant le travail en cours et en s’alignant au rythme du plus lent (théorie des contraintes).

Kanban fonctionne sur la base de flux tiré (à l’opposé d’un flux poussé) dans l’objectif de limiter les stocks ainsi que le gaspillage.

Finalement, l’amélioration continue est au centre du processus Kanban.

Un point commun

Avant de se plonger dans ce qui opposent ces deux concepts, j’aimerais rappeler qu’il repose sur les mêmes principes de base.

Tous les deux apportent de la transparence au travail effectué ou livré par les équipes, ce qui permet d’inspecter et d’adapter dans l’objectif de s’améliorer.

Dans Scrum, nous retrouvons ce concept dans les 3 piliers qui sont : la transparence, l’inspection et l’adaptation.

Dans le cadre de Kanban, le board apporte la transparence nécessaire à l’inspection et l’adaptation du processus de travail.

Les différences

La notion de cadence (ou timebox)

La première différence entre Scrum et kanban est liée à la cadence. Dans Scrum on avance par itérations, nommées sprints, de 2 à 4 semaines au bout desquels nous avons un livrable (incrément). Chaque itération contient un planning, des daily meetings, une revue et une rétro.

Lorsqu’un sprint est démarré et que le travail est défini, il n’y a plus de changement de priorité provenant de l’extérieur de l’équipe.

Pour Kanban, c’est un flux continu. Pas de début ou de fin. On dépile les éléments de travail au fur et à mesure et selon la priorité. Des nouveaux éléments peuvent apparaitre à tout moment.

Les règles et normes

Scrum est un framework, ce qui signifie qu’il y a des règles à suivre pour faire du Scrum. Par exemple, le Daily Scrum doit durer maximum 15′. Un sprint démarre toujours par un planning et se termine par une rétrospective.

Kanban est beaucoup moins prescriptif. Il n’y a pas de règles, mais plutôt des bonnes pratiques implicites. Par exemple, limiter le travail en cours sur les étapes du processus ou visualiser le flux avec un board physique.

Les rôles

Les rôles sont une autre différence flagrante entre ces deux « outils ».

En effet, il n’y a aucun rôle officiel dans Kanban alors que nous en comptons 3 dans Scrum : Scrum Master, Product Owner et Developer.

Néanmoins, on retrouve souvent un rôle de « Kanban master » dans les équipes qui fonctionnent avec cette méthode de travail. Il saura mettre de l’huile dans les rouages du système pour s’assurer que l’ensemble fonctionne au mieux. Il existe aussi le rôle de « Service request manager » qui amène un rôle d’arbitre des priorités et maintient la vue d’ensemble.

Les mesures

Finalement, pour terminer notre comparaison, nous pouvons nous pencher sur les mesures-clés utilisées.

Pour Scrum, nous retrouverons la valeur produite ainsi que la vélocité de l’équipe. Cette dernière est mesurée à chaque fin de sprint en faisant la somme des éléments terminés. Tout au long du Sprint, nous suivons l’évolution de celui-ci à l’aide d’une « burndown chart », qui nous donne de la transparence sur la capacité de l’équipe à atteindre l’objectif visé ou non.

Pour Kanban, nous parlerons de temps de cycle, c’est à dire le temps nécessaire pour qu’un élément parcourt l’entier du processus. Nous utilisons régulièrement un « cumulative flow diagram » pour visualiser l’état, le nombre de tickets, des différentes étapes du processus.

La volonté de Kanban étant de limiter le travail en cours (Work In Progress), des contraintes en nombre maximum d’éléments par étape sont définies en équipes dans l’objectif d’avoir le flux le plus tiré et continu possible.

Kanban ou Scrum : et si vous ne parvenez pas à choisir?

Un bon départ et de se poser la question suivante :

Est-ce que vous avez beaucoup de volatilité dans vos priorités (est-ce qu’elles changent tous les jours) ?

Si la réponse est oui, fonctionner en Scrum dans votre contexte actuel semble être compliqué. Vous devriez donc partir sur la mise en place de Kanban.

Et si vous n’arrivez (toujours) pas à choisir ? Vous pouvez aussi jeter un oeil à Scrum-ban qui marie les deux mondes.