SCRUM vs KANBAN

Agile

Vous avez choisi l’agilité pour votre projet informatique, le périmètre fonctionnel est défini, il est temps de démarrer. Quelle agilité mettre en place ?

Ce billet va présenter deux méthodes agiles connues en les comparant. La première, Scrum, est sûrement la plus connue et utilisée actuellement, la seconde, Kanban, vient du monde de l’industrie.

Scrum

Scrum est donc une méthode de gestion de projet. Cette méthode est définie par un ensemble de règles et rôles à respecter (Cf. article Scrum sur Wikipedia).

Kanban

Kanban est une méthode originaire du monde industriel (Toyota dans les années 1950) permettant de travailler de façon agile. L’essence de kanban est le découpage des tâches et une certaine visualisation du workflow.  Pour ce faire, la méthode prescrit un découpage du travail sous forme de fiches. Ces fiches navigueront ensuite sur un tableau à colonne, chacune d’elles représentant une étape du développement. Chaque colonne à un nombre maximum de fiches à ne pas dépasser (chiffre en rouge dans l’exemple ci-dessous).

Ceci permet de visualiser rapidement les goulets d’étranglements dans un projet.

En s’appuyant sur l’illustration ci-dessous :

Imaginons qu’il y ait 5 tâches dans la colonne « A traiter » et une seule dans la colonne « Analysées ». Cela indique que l’analyse des tâches ne suit pas le rythme d’arrivée du besoin.

Faut-il renforcer l’équipe d’analyse ? Faut-il se réorganiser et faire une pré-analyse du besoin ? etc…

Exemple :

La mesure principale servant à optimiser le processus est le temps nécessaire à une fiche pour parcourir le tableau. Dans l’exemple ci-dessus cela représente le temps que mets une tâche depuis la découverte du besoin (Colonne « A traiter ») à la livraison en recette. En faisant la moyenne des temps de parcours des différentes fiches on peut obtenir une moyenne appelée temps de cycle moyen.

Après cette brève présentation nous allons analyser les points communs de ces méthodes.

Points Communs

Tout d’abord, ces deux méthodes mettent en pratique l’agilité et sont « Lean ». L’agilité a été abordée dans l’article cité plus haut tandis que l’approche « Lean » est une approche d’optimisation du rapport coût/rapidité/valeur Produite. Cela se traduit par des livraisons rapides et fréquentes du produit et un fonctionnement « juste à temps ». La livraison des fonctionnalités se fait au moment où on l’attend, ni avant, ni après.

Ces deux méthodes limitent le nombre de travaux. On ne peut pas ajouter indéfiniment des tâches à réaliser. Dans Scrum, la limite est au niveau des sprints et dans kanban, au niveau d’une étape projet.

Toutes les deux prônent le découpage du travail en tâches unitaires (Story en Scrum).

Le planning des releases est ajusté en continue en fonction des retours d’expériences (après chaque sprint pour Scrum). Ce pilotage par retour d’expérience régulier est possible grâce à l’auto-organisation et à l’autonomie des équipes.

Tout cela rend ces deux méthodes empiriques, il faut les pratiquer et s’ajuster selon le déroulement du projet. Par exemple, c’est en pratiquant Kanban qu’on trouvera les bonnes valeurs du nombre limite de tâches par étapes du projet.

Après avoir décrit des points communs de ces deux méthodes, étudions certaines différences significatives.

Différences

Scrum est une méthode plus normative que Kanban :

Kanban ne préconise aucun rôle particulier (Product Owner, Scrum Master …). Les rôles s’adaptent au projet, il n’y a aucune obligation sur ce point.

De plus Scrum impose une durée fixe pour ses itérations (la durée d’un sprint), alors qu’elle est ajustable avec Kanban. En effet aucunes durées n’est imposées. Les livraisons et les retours d’expériences sont faits en fonction de choix et d’événements projets. La découpe des nouveaux besoins en tâche peut se faire de façon mensuel alors que la livraison du produit peut être faite à chaque fois qu’une fonctionnalité utile est terminée.

Concernant le suivi d’avancement, ces deux outils utilisent un tableau composé de colonnes dans lesquelles naviguent des tâches (représentées par des fiches ou Post-it). Chacune de ces colonnes représente une étape du projet. Kanban limite le nombre de tâche par colonne donc par étape alors que Scrum limite le nombre tâche par tableau. En effet Scrum possède un Scrum Board par sprint

Avec Scrum ce tableau est réinitialisé à chaque itération, ce qui n’est pas le cas avec Kanban. En effet le tableau perdure le temps du projet. Dans ces deux méthodes le tableau de suivis ne représente donc pas la même échelle de temps : un sprint pour Scrum et le projet « entier » pour Kanban.

 

Scrum impose une équipe multidisciplinaire, c’est-à-dire une seule équipe pour traiter un Scrum Board. Kanban autorise tout à fait plusieurs équipes à partager et utiliser un seul tableau de suivi. Il suffit de définir les règles d’utilisation et de partage.

Aussi Kanban n’impose aucune priorisation, celle-ci est optionnelle, Scrum lui impose une priorisation afin de mieux choisir les stories à développer pendant un sprint. Les tâches (stories) présentent dans le Backlog sont donc priorisées.

 

Pour terminer avec les différences entre ces deux méthodes, il faut étudier la mesure par défaut en vue de l’amélioration du processus. Kanban utilise le temps de cycle cité en partie 2 de cet article alors que Scrum utilise la vélocité. La vélocité correspond à la somme des estimations des stories d’un sprint.

Scrum mesure donc par défaut, la quantité d’estimation réalisée durant un sprint alors que Kanban étudie le temps moyen d’une tâche.

 

Voici un tableau résumant ces différences :

Après avoir étudié les points communs et les différences de ces deux méthodes nous voyons qu’aucune de ces deux méthodes n’est exhaustive.

Comme aime à le dire les experts en méthodologie, Kanban et Scrum sont des outils et non des recettes miracles. Ils peuvent se compléter l’un l’autre. Kanban peut même être une bonne première étape pour une migration vers l’agilité.

 

Pour aller plus loin :

http://www.infoq.com/resource/news/2010/01/kanban-scrum-minibook/en/resources/KanbanAndScrum-French.pdf

http://www.aubryconseil.com/post/Pourquoi-kanbaniser-du-Scrum

3 Differences Between Scrum and Kanban You Need to Know

 

(Article rédigé par Adrien COURBE en 2016 pour la première version de notre blog)

(Visited 204 times, 1 visits today)
Suivez nous sur Twitter
Envoyez nous un mail

Comments

comments