Kanban vs Scrum : points communs et différences

Agile par ci, agile par là… L’Agile est à la mode et revient tout le temps mais « Kanban vs Scrum? »… La question revient souvent.

En effet, dans la gestion de projet, les méthodes agiles ont le vent en poupe. Du Marketing, à la « start-up nation », on retrouve Agile dans les offres d’emploi, et jusque dans les discours politiques ! Afin de partager un peu de concret, penchons-nous sur Scrum et Kanban, les deux approches agiles les plus répandues.

Contrairement à Kanban, Scrum N’EST PAS une méthode!

Et non ! Même si c’est un des termes les plus courants lorsqu’on parle d’agilité, il faut vraiment comprendre Scrum, pour savoir que c’est une fausse étiquette qu’on lui colle.

N’oubliez pas tout ce que vous avez appris cependant. Scrum est bien Agile, mais ce n’est pas une méthode. On parle ici de cadre de travail qui définit un ensemble de cérémonials et de règles pour rythmer le développement.

Agile Kanban, quant à lui est bien une méthode qui peut être appliquée à la lettre et qui d’ailleurs vient de l’industrie. Dans le monde industriel, les processus sont définis, documentés et appliqués!

Kanban vs Scrum : les principales différences

•  Le rythme

Il y a plus de rythme en Scrum qu’avec Kanban!

L’itération (ou Sprint) définit justement le rythme et des jalons courts. Le sprint sert à organiser les tâches de l’équipe et définit l’objectif (le “Sprint goal”). La réunion du Sprint Planning est le rituel qui sert à partager la compréhension autour de cet objectif. Les développeurs évaluent la difficulté de l’objectif en adjugeant un nombre de points de complexité (ou de vélocité) à chaque tâche. En cas de nouvelle demande, sauf urgence ou point bloquant, elle ne sera prise en compte qu’au Sprint suivant. Même si cela fait perdre en agilité,  l’équipe gagne en concentration et reste focalisée sur son objectif.

Pour évaluer les points de complexité, on attribue 1 point à la tâche la plus simple à réaliser. Chaque tâche est ensuite évaluée par rapport cette référence. L’évaluation est souvent réalisée via le rituel du « Planning poker » (dont je vous reparlerai à l’occasion!).

Par contre, Kanban ne prévoit pas de période délimitée dans le temps. Il n’y a donc pas de sprint! Le projet est alors géré en flux continu. La production, la priorisation des demandes, l’amélioration continue sont gérées au fil de l’eau. On peut du coup prendre en charge de nouveaux sujets pendant le sprint si besoin!

Kanban me semble plus adapté lorsqu’on doit traiter de nombreux sujets différents. En effet, la livraison en continu permet plus facilement d’échelonner les plans de tests. Si on a une livraison complète à la fin du Sprint, il y a une sorte de « saisonnalité » qui se crée dans le planning. Ceci peut conduire à des « bouchons » mal anticipés. Et les goulets d’étranglement, ce n’est pas lean! ce n’est pas Kanban! Après tout, Kanban a été pensé dans l’industrie pour avoir des flux continus et traiter la demande de pièces détachées !

•  Les outils de management visuels

La différence de rythme entre Kanban vs Scrum se voit sur leurs tableaux respectifs.

En Scrum, on décrit le flux de travail de l’étape “A faire” (via le backlog et le backlog refinement) à “Réalisé”. Toutes les tâches requises devront alors avoir été effectuées à la fin du Sprint (dans un monde idéal, bien sûr!). Mais si besoin, on transfère les tâches restantes au Sprint suivant, avec les éventuelles nouvelles demandes.

En Kanban, le tableau de suivi comporte lui aussi des colonnes de suivi. Par contre, on limite le nombre de tâche que chaque statut peut compter. L’idée est de limiter les sujets en-cours afin de gagner en fluidité. Ainsi avec moins de tâches en-cours j’ai plus de réactivité en temps réel (et moins de suivi!… en Lean, le suivi et le contrôle c’est du Gaspi!). Chaque tâche est traitée et les nouvelles demandes sont ajoutées au fur et à mesure. Du coup, contrairement à Scrum, on ne mesure pas la vélocité (ou la complexité), mais plutôt le délai qu’il a fallu pour traiter une demande.

•  Les rôles

Dans l’approche Scrum, il faut forcément définir des rôles (même s’ils peuvent tourner). Un Scrum Master est requis pour assurer le respect des rituels. De même le Product Owner doit être désigné et représenter le client (ou l’utilisateur) final et faire des retours au plus tôt. Le troisième rôle c’est celui du Team Member, en particulier les développeurs, surtout quand on est sur un projet IT. Il nous est arrivés de définir un rôle de Tech Lead par rapport à l’équipe de Développement. Ce n’est pas requis dans la méthode (voire c’est proscrit!) mais j’ai trouvé ça plus efficace dans certains cas.

En Kanban, il n’est pas nécessaire de définir les rôles. L’équipe est autonome et chacun va piocher les tâches au fur et à mesure. Là encore, c’est un concept issu de l’industrie avec les UAP (Unités Autonomes de Production).

Kanban vs Scrum : en conclusion…

Ainsi, il y a des différences entre Kanban vs Scrum:

Mais les deux approches ont de nombreux points communs: responsabilisation, management visuel, amélioration continue, objectifs communs, rapidité… Elles pallient la complexité des projets et ont un souci de l’efficience. Elles donnent un cadre et des outils pour organiser le travail de l’équipe et faciliter la collaboration.

Du coup, comme vous le voyez, je ne les oppose pas tant que ça! Pour savoir à quelle école se vouer, tout dépend, finalement, de votre besoin ! Personnellement, j’applique un principe de pragmatisme! Après tout, en Agile, on apprend que le besoin bouge constamment. Donc je reste ouvert et je pioche dans chacune des approches en fonction de l’objectif!

Si vous souhaitez en savoir plus si les avantages de la mise en place d’une méthode Agile, découvrez le témoignage de Jérémy Amourous, DSI de Colissimo.

(Merci à Jordan qui a co-écrit cet article ! )