En tant que coach agile, je suis régulièrement amenée à proposer des cadres de travail Agile qui correspondent le mieux au contexte de l’équipe ou du client. Je constate que régulièrement le management dans ces entreprises a entendu parler de Scrum et nous engage pour mettre en place ce cadre de travail en particulier. Pourtant, il ne convient pas toujours et lorsque j’amène la perspective d’utiliser Kanban, les personnes sont souvent perplexes, car pour elles, Scrum et Kanban, c’est bonnet blanc et blanc bonnet. Après tout, on utilise bien un tableau avec des colonnes dans les deux cas, non ?

Vous l’aurez compris, je caricature un peu la situation qui a cependant un fond de vérité. Il me semblait donc intéressant de mettre par écrit les différences majeures de ces deux cadres pour comprendre dans quel cas l’un sera plus adapté que l’autre.

En résumé

Laissez-moi d’abord vous rappeler ce que sont Scrum et Kanban dans les très, très grandes lignes.

Scrum

Pour ceux qui n’auraient toujours pas vu ce fameux schéma résumant le cadre Scrum, le voici :

L’équipe va travailler autour d’un produit en itération, appelé des sprints, afin de délivrer un incrément de la plus haute valeur possible. Le sprint est une enveloppe de temps qui peut durer de 2 à 4 semaines (cette durée étant fixe d’itération en itération).

Un sprint est composé de plusieurs événements :

• Sprint planning pour démarrer le sprint et définir ce qui va être fait durant le sprint

• Le Daily Scrum, ayant lieu chaque jour

• La Revue de sprint, à la fin du sprint

• La Rétrospective de sprint, à la fin du sprint

Kanban

Kanban peut sembler plus souple que Scrum à première vue. Cependant, les quelques règles édictées doivent être scrupuleusement appliquées pour en voir les bienfaits.

En résumé, cela donne :

Un peu plus en détail, nous avons :

• Visualiser : visualiser le flot de travail sous forme de tableau. Une colonne par activité.

• Limiter le travail en cours (WIP Limit) : il s’agit de la clé de Kanban. Le nombre de tickets pouvant se trouver dans chaque colonne est limité. Un nombre est atteint ? Il n’est plus possible de placer un nouveau ticket dans cette colonne, il faut désengorger le flux.

• Rendre les politiques explicites : les politiques sont les définitions claires de chaque colonne et chaque couloir (lignes, swimlane). Le but étant d’enlever les doutes qu’il pourrait y avoir dans l’équipe quand un ticket peut être mis dans telle colonne ou non, par exemple.

• Évoluer expérimentalement et collaborativement : au sein de l’équipe, il est nécessaire de prévoir des moments pour s’améliorer en se basant sur ce qui a été vécu, par exemple, à l’aide de rétrospective.

• Gérer le flot : grâce aux WIP Limit, nous allons pouvoir faire des statistiques et calculer le temps nécessaire à une demande pour traverser le tableau et en tirer des statistiques.

Il peut y avoir plusieurs événements (planification, triage, revue), mais l’événement obligatoire est le daily. Il est souvent conseillé d’avoir une séance de priorisation et de rétrospective également.

Les principales différences

Produit vs services

Là où Kanban est orienté “livraison de services”, Scrum est résolument orienté Produit.

Si l’équipe s’occupe d’un seul et unique produit, il sera nettement plus puissant d’utiliser Scrum pour avoir une logique d’ensemble, pouvoir utiliser la notion de “But de sprint” afin de livrer le plus de valeur possible et de motiver l’équipe.

En sens inverse, essayer à tout prix de motiver une équipe autour d’un but de sprint qui n’en est pas un, alors que l’équipe touche à de nombreux domaines différents, de nombreux produits différents, cela n’a pas de sens.

Limiter le temps vs Limiter le travail en cours

Dans Scrum, nous allons limiter le travail par le temps, les sprints. Qu’est-ce que l’équipe va pouvoir réaliser dans le sprint à venir ? À l’intérieur de l’itération, libre à elle de s’organiser afin d’atteindre le but du sprint.

Dans Kanban, nous allons limiter le travail en cours par activité (pour chaque colonne, nous allons définir un Work In Progress Limit – WIP Limit). Si une colonne est pleine, il faut trouver un moyen de désengorger le flux. Toute la puissance de Kanban est basée là-dessus.

Flux tiré vs Flux poussé

Pour Kanban, étant donné les WIP Limits, le flux devient automatiquement un flux tiré, à savoir qu’on va prendre une tâche dans une colonne uniquement lorsqu’il y a de la place à disposition. C’est pour cette raison aussi que lors du daily, nous allons lire le tableau Kanban de droite à gauche. De cette manière, nous nous posons toujours la question de la tâche qui peut être terminée en premier. Quel est l’élément le plus avancé en termes de travail qui peut être fini au plus vite ? En faisant le travail dans ce sens, nous allons libérer de l’espace dans les différentes colonnes ce qui permettra ensuite de “tirer” de nouvelles tâches.

Pour Scrum, par contre, il est d’usage de parler de Flux poussé, à savoir que lorsque nous avons terminé le travail sur une tâche, nous pouvons pousser la tâche directement dans l’activité suivante. Libre à la personne qui s’occupe de l’activité suivante de la traiter quand elle le pourra.

Mesurer vs Estimer

Dans Scrum, il est prévu lors du Sprint Planning d’effectuer des estimations de chacun des besoins et de définir ensuite ce qu’il est possible de prendre dans le sprint à venir. Les estimations sont libres (il est souvent d’usage d’utiliser des Story Points ou des jours). Avec le temps, il est possible, en principe, de calculer la vélocité de l’équipe et de savoir avec une plutôt bonne prédictibilité ce qui pourra être pris dans le sprint.

Dans Kanban, il n’y a pas d’estimation prévue lors de la séance de priorisation. La seule question que l’on se pose est sur la granularité : est-ce que la tâche est suffisamment petite et correspond à l’échelle que l’équipe s’est fixée. Par exemple, si la granularité fixée par l’équipe est de 5 jours, nous allons simplement valider que la tâche prend bien 5 jours ou moins avant de l’ajouter dans les éléments sélectionnés. Le travail qui sera fait ensuite dans Kanban sera de compiler des chiffres qui permettront de mesurer le temps moyen que prennent les tâches. À partir de ces chiffres, il sera possible de définir des temps de traitement moyens et également d’analyser les tâches qui prennent plus de temps, d’en comprendre le pourquoi et de s’améliorer pour la prochaine fois. Ces statistiques ne sont pas disponibles de suite et il faudra attendre plusieurs mois avant d’avoir des données qui permettront de faire des projections. Il est peut-être bon d’insister que sans WIP Limits, ces données ne seront jamais exploitables.

Quelques points d’attention à la mise en place de Kanban

Selon mon expérience, lorsque les équipes passent d’un travail en mode Scrum vers Kanban, il faut être attentif à certains points en particulier :

• Suivre une formation : afin de pouvoir intégrer au plus vite les bons réflexes. Il est fortement recommandé d’introduire Kanban avec une formation, une multitude de questions émanant de ce changement de cadre.

• Discipline : semble être le mot clé pour garantir la réussite de ce cadre de travail. Douloureuse au début, il est nécessaire de serrer les dents jusqu’à ce que les parties prenantes ainsi que l’équipe aient tous intégré les bons réflexes.

• Les WIP Limit : trouver le bon dosage pour les WIP Limit est compliqué. Il faut à la fois avoir suffisamment de bande passante et à la fois que cela soit suffisamment contraignant pour en voir les bénéfices. De plus, l’équipe a beau comprendre théoriquement les bienfaits des WIP Limits, cela peut être vu comme un frein et une contrainte trop forte que l’on aura juste envie de contourner. Il faut donc rester attentif à cela et expliquer encore et encore pourquoi c’est important.

Conclusion

Malgré les différences détaillées ici, Scrum et Kanban sont deux cadres qui se basent sur des principes similaires. Nous retrouvons les notions d’itération, d’inspection et d’adaptation.

Un cadre n’est pas meilleur que l’autre, cela dépendra de votre contexte. Pour savoir quel cadre est sûrement le plus adapté pour vous, il faut se poser la question : “Est-ce que je travaille pour livrer des services ou est-ce que je travaille autour d’un produit ?”.

Il est également possible de mixer certaines des pratiques des différents cadres. Il existe d’ailleurs un guide Kanban pour les équipes Scrum.

Dans un cas comme dans l’autre, ce qu’il faut retenir c’est que les règles imposées sont somme toute assez minces, mais il faut les suivre pour vraiment voir les bienfaits de ces outils. Faire Kanban sans les WIP Limits, ce n’est pas Kanban. Faire Scrum sans rétrospective, ce n’est pas Scrum. Ce sont deux exemples parmi tant d’autres.