Différences entre Kanban et Scrum

Quelles sont les différences entre Scrum et Kanban

Introduction: Scrum ou Kanban, Kanban ou Scrum…

Comment faire pour choisir entre les deux méthodes agiles les plus populaires?

Avant de lire cet article, vous devez connaitre les bases des deux méthodes Scrum et Kanban.

Généralement, on a tendance à utiliser le Scrum pour le développement d’une application et le Kanban est plus fréquemment utilisé pour les projets en TMA (Tierce Maintenance Applicative), c’est à dire la maintenance d’une application effectuée par un prestataire externe à l’entreprise, souvent en mode « Ticketing« .

Mais rentrons plus dans les détails…

Les différences entre les tableaux Scrum et Kanban

Les tableaux Scrum et Kanban, bien qu’ayant des similitudes, sont tout de même assez différents.

En effet, le tableau Scrum (ou Scrum Board) est un outil de visual management permettant notamment de connaitre et changer le statut de chaque user story.

Les Scrum boards, au travers des différents projets, ont souvent des colonnes assez similaires :

  • A faire (Todo)
  • En cours (In progress)
  • Terminé (Done)

Le tableau Kanban (ou Kanban Board) est également un outil de visual management mais cette fois-ci permettant de visualiser un workflow.

Il permet de séparer les statuts en plusieurs états « En cours » et « Fait ».

Il intègre la notion de WIP (Work In progress Limite) n’existant pas en Scrum classique (même si bien sur, vous pouvez l’utiliser).

Le kanban board a tendance à évoluer beaucoup plus en fonction du projet car il est une représentation visuel du workflow projet.

Livraisons et itérations en Scrum et en Kanban

Le Scrum est régi par des itérations d’une même durée :Sprint, alors que le Kanban propose plus de souplesse.

Les livraisons peuvent être faites toutes les N étiquettes par exemple, mais il n’y a pas d’obligation.

C’est à vous, équipe, en accord avec votre client, de décider du rythme de livraison le plus adapté à votre projet.

Estimations en Scrum et en Kanban

En Scrum, le calcul de la vélocité est un exercice capital, car il permet de connaitre sa capacité de travail lors d’un sprint.

Les éléments Scrum (souvent des user stories) sont régulièrement estimées. Cette estimation, croisée avec sa capacité de travail sur un sprint (vélocité), permet de créer une prévision sur le contenu de la livraison en fin de sprint.

Constamment pendant le sprint, la charge de travail restante est  réévaluée et renégociée pour que le but du sprint soit atteint.

Toute cette démarche chronophage n’existe pas vraiment en Kanban.

Une estimation initialement peut être faite pour connaitre le temps de passage pour traverser le Workshop (tableau), mais ça s’arrête là.

Gestion du temps en KANBAN

Kanban board avec estimation

Comme vous le voyez sur l’image ci-dessus, il est possible en Kanban d’intégrer une solution pour l’estimation des étiquettes.

Dans cet exemple, lors de la création d’une étiquette, le créateur positionnera son étiquette dans le haut du tableau s’il estime qu’il faudra à l’étiquette environ 3 jours pour traverser le tableau (workflow) ou en bas s’il estime que le temps de réalisation est proche de 8 jours.

Que se passe t’il si la macro estimation est supérieure à 8 jours?

On essaie de diviser l’étiquette en plusieurs étiquettes d’une durée inférieure ou égale à 8 jours.

La gestion des anomalies en Scrum et en Kanban

Une autre grande différence entre Scrum et Kanban est la gestion des anomalies.

En effet, imaginez que vous travaillez en Scrum. Votre équipe a déjà réalisé plusieurs sprints et certaines des livraisons (releases) précédentes sont en exploitation.

Jusque là tout va bien.

Puis un beau jour, vous êtes en plein sprint, et un bug CRITIQUE apparaît sur la version de l’application en exploitation! Et c’est la cata…

Alors que faites-vous?

Vous arrêtez les développements en cours pour vous concentrer sur la mise en place d’un patch?

Scrum ne prévoit pas vraiment ce type d’intervention, alors que le Kanban est typiquement fait pour.

Cependant, il existe tout de même des solutions de contournement en Scrum pour gérer les corrections des anomalies « en prod ».

Vous pouvez par exemple allouer une partie de la vélocité de votre sprint à des corrections.

Évidement, ce n’est pas toujours idéal, il faut que la charge de travail soit relativement prévisible et il faut intégrer de nouveaux processus et règles de travail:

  • Ajoute-t-on les anomalies au Scrum Board?
  • Crée-t-on un statut spécial pour les anomalies?
  • Doit-on les estimer?
  • Quel(s) membre(s) de l’équipe doit stopper son travail ?
  • Quel est le processus de mise en exploitation?
  • Comment gère-t-on les branches de travail?

Rien d’insurmontable évidement, mais il faut y penser sinon l’équipe risque de « mal » corriger l’anomalie ET en plus de ça, de perturber le sprint en cours.

Planification en Scrum et en Kanban

Le Kanban n’est pas fait pour réaliser des plannings de réalisation à moyen ou long terme.

Il est issu de la « philosophie » Lean (gestion sans gaspillage). Mais il est possible d’intégrer une notion de planification de type « Sprint » comme le montre l’exemple ci-dessous :

Notion d'itération et de planification avec Kanban

Sprint en Kanban

Mais difficile d’aller beaucoup plus loin avec le Kanban…

Mise en place du Scrum et du Kanban

La mise en place du Kanban peut être progressive. Le tableau, qui est a la fois une solution de gestion du process/workflow et du visual management, peut évoluer tranquillement, au fur et à mesure que l’équipe devient mature. Mais la mise en place peut rester basique dans un premier temps.

Le Scrum nécessite un peu plus de préparation: créer le backlog, former les équipes aux différents rôles, fixer une vélocité, décider de la durée des itérations, estimer une partie des User Stories… Pour cela (entre autre) on fait souvent un sprint d’initialisation (ou sprint 0).

Pour plus d’informations sur la méthodologie Scrum, vous pouvez lire l’article correspondant.

Les goulots d’étrangement

Le Kanban permet d’éviter ou de repérer certains goulots d’étranglement plus simplement qu’en Scrum.

En effet, tout le système du Kanban repose sur le fait d’éviter au maximum tous les blocages possibles dans le flux, avec notamment le Work In progress Limit, l’utilisation d’avatars, la subdivision des colonnes « En cours » / « Fait »…

En conclusion

Chers chef d’équipes, vous avez maintenant je l’espère, quelques informations supplémentaires pour décider de la méthode de travail que vous allez mettre en place avec votre équipe.

Mais au final, pourquoi choisir?

Il n’est pas toujours nécessaire de faire un choix entre ces deux méthodes!

Vous pouvez prendre le meilleur de chaque monde, intégrer vos anciens process et utiliser votre expérience pour les faire évoluer.

Aucun site ne vous donnera la solution parfaite correspondant à votre environnement projet. Inspirez-vous de l’existant, adaptez, réfléchissez et vous obtiendrez forcement une solution géniale!

A lire aussi :

Publicités