SCRUM vs KANBAN : Quelle est la méthode la plus adaptée ?

Longtemps considérée comme une méthode permettant de maîtriser efficacement les délais de livraison, les coûts de conception et le contrôle qualité, la méthode dite du « cycle en V » semble être de plus en plus difficile à appliquer dans l’écosystème digital. Rigide de part son déroulé, les équipes projets ont désormais besoin d’adapter rapidement leurs solutions digitales, et de favoriser l’amélioration continue tout au long de la vie des projets.

C’est ainsi, et dans un contexte où les attentes utilisateurs ne cessent de s’affiner et de s’affirmer, que les entreprises doivent faire preuve d’un grand niveau de flexibilité. Compréhension et écoute sont devenues les mots-clés pour apporter des réponses adaptées.

« Mais dit moi Jamy, ça sonne très « méthodes agiles » tout ça ! ». C’est très juste ! Basées sur des principes de collaboration, d’ouverture au changement et de transparence de l’information visant à fluidifier les interactions des talents d’une équipe, les méthodes Agiles (Scrum, Kanban, Scrumban…) tirent leur épingle du jeu … Elles ne se limitent plus aux équipes techniques et digitales. Elles séduisent de plus en plus de services dans les entreprises afin de répondre au paradigme suivant : comment pouvons-nous faire mieux au quotidien, en répondant de manière plus juste aux attentes et en observant rapidement des résultats visibles et mesurables ?

Bien que similaire en apparence, les différentes méthodologies comme SCRUM et KANBAN s’articulent autour d’attentes et de fonctionnement différents. Elles n’impliquent pas les mêmes philosophies, ni les mêmes acteurs, ou procédés.

La méthode Scrum (« mêlée ») est incontestablement la méthode Agile la plus connue et la plus utilisée dans l’écosystème actuel. Elle est considérée comme une méthode de management de projet structurée et rapidement déployable. La méthode Scrum offre la possibilité de piloter les avancées d’un projet sous la forme d’itérations (plus communément appelées « Sprints »). Les Sprints durent en moyenne 1 à 3 semaines et reposent sur un objectif précis : délivrer continuellement de la valeur aux parties prenantes (équipes métiers, clients, utilisateurs) toutes associées à un même produit/service. Concrètement, le SCRUM c’est l’itération au service du projet.

La méthode Scrum repose sur 3 rôles clés présents au sein d’une même équipe :

1. Le Scrum Master

• Facilitateur : il garantit la fluidité des échanges au sein de l’équipe ;
• Garant : il assure le respect de la méthodologie Scrum ;
• Motivateur : il pousse l’équipe vers une amélioration continue.

2. Le Product Owner

• Expert : il connait le métier et communique les règles fonctionnelles ;
• Organisateur : il priorise les tâches à développer ;
• Communiquant : il échange avec les parties-prenantes externes à l’équipe Scrum.

3. L’équipe de développement

• Garante : elle assure la mise en place du volet technique de la solution digitale ;
• Hétérogène : elle regroupe des métiers d’experts (Architectes, QA, Développeurs…) ;
• Structurante : elle porte la vision des évolutions techniques futures.

L’équipe Scrum est considérée comme « un tout » dans lequel chaque acteur joue un rôle essentiel quant au bon déroulé des développements.

La méthodologie Scrum repose sur des valeurs humaines, méthodologiques et structurelles. Elle permet de :

• Communiquer ouvertement autour des bonnes et mauvaises pratiques.
• Accélérer la création de valeur en livrant des fonctionnalités proches du besoin utilisateur ;
• Favoriser les prises d’initiatives au sein de l’équipe ;
• Responsabiliser l’ensemble des acteurs de la chaîne de valeur ;
• Réduire le « Time-to-market » en adoptant une position de l’évolution par le test ;
• Contrôler la qualité et la cohérence des livrables ;
• Offrir une importante visibilité opérationnelle et stratégique ;

Schématiquement, nous pouvons représenter le cycle itératif de la méthode Scrum de la manière suivante :

• La sélection des tâches à développer repose sur la priorisation de l’ensemble des actions à mener. Toutes les tâches sont importantes ? Oui ! Mais procurèrent-elles le même niveau de valeur pour les utilisateurs ? Pas forcément. C’est ici que le Product Owner intervient. Garant du Backlog (liste complète des taches à développer), il priorise pour chaque sprint les tâches prioritaires à adresser selon la capacité de production de l’équipe de développement.
• Le développement et la recette s’appuient sur une collaboration permanente entre l’équipe de développement, le Product Owner et le Scrum Master. L’objectif est simple : minimiser les frictions et les événements bloquants afin de garantir la livraison des tâches associées au Sprint.
• La validation est souvent assurée par le Product Owner et les parties-prenantes externes si le besoin est exprimé.

• Une méthode « rapide » à mettre en place selon l’échelle de votre entreprise ;
• Des livraisons plus fluides et des capacités de production consolidées ;
• Une véritable source d’inspiration pour des services « non agilisés » ;
• Une communication fluidifiée entre les équipes Scrum et les équipes métier ;
• Des étapes de développement portées sur la création de valeur et la satisfaction utilisateur.

• Il s’agit d’une méthodologie qui nécessite un accompagnement et une acculturation importante ;
• SCRUM est portée sur la rigueur et la ritualisation de l’activité qui peut ne pas correspondre à la vision portée par vos équipes.

La méthode KANBAN (« étiquette ») intègre également la famille des méthodes agiles. Bien que conceptuellement proche de la méthode Scrum, la méthode KANBAN diffère par son approche. La méthode KANBAN c’est consiste à un développement en flux continu, elle est régie par des règles fondamentales :

• La limitation des tâches à effectuer en un temps donné (tâches à finir ou TAF) ;
• La réduction du gaspillage ;
• L’amélioration continue ;
• La visualisation du flux de travail ;
• L’identification et la résolution des points de frictions.

Souvent associée à un support de type « tableau » qui porte le même nom que la méthode, l’équipe qui est responsable des développements peut, d’un simple regard, contrôler l’avancée des tâches, l’apparition de points bloquants dans le flux de travail ou la formation de goulots d’étranglement.

Contrairement à la méthode Scrum, le Kanban ne nécessite pas l’intervention de rôles précis. Vos actions s’articulent alors entre le Chef de Projet et l’équipe de développement.

Le KANBAN (tableau de suivi du flux de travail) permet de monitorer avec précision l’avancée des opérations et s’articule communément autour de 4 étapes clés :

• Etape 1 : « TO DO » qui est un regroupement de tâches à développer ;
• Etape 2 : « IN PROGRESS » qui correspond à l’ensemble des tâches en cours de développement ;
• Etape 3 : « TEST » qui indique au Chef de Projet que la tâche est prête pour une recette ;
• Etape 4 : « DONE » qui signifie que la tâche est achevée est n’attend plus que son déploiement.

Attention : Il n’est pas rare de constater que les différents membres de l’équipe ont tendance à favoriser et à s’orienter naturellement vers les tâches déjà maitrisées/connues. Afin de répondre au principe d’amélioration continue insufflée par la méthode KANBAN, il est important de prendre en considération la montée des compétences de chacun en variant la nature des tâches sélectionnées par les différents membres de l’équipe.

• Une méthode encore plus flexible que le Scrum ;
• Un suivi du flux de travail facilité méthodologiquement et visuellement ;
• Une charge de travail contrôlée qui permet de garantir des livraisons continues ;
• Une identification simplifiée des goulots d’étranglement ;
• Une méthode qui offre la possibilité de piloter un projet avec une feuille de route peu détaillée ;
• La méthodologie KANBAN est facilement personnalisable au niveau de l’équipe ;

• La méthode KANBAN n’est pas adaptée à tous les services de l’entreprise ;
• Cette méthodologie nécessite un haut niveau d’acculturation aux méthodes agiles ;
• Difficultés à identifier le lien logique entre les différentes tâches ;
• La méthode KANBAN rend plus complexe la gestion du planning / de la roadmap.

Pour choisir entre SCRUM vs KANBAN, vous devez identifier la méthodologie de travail qui correspond le mieux à votre culture d’entreprise, à vos projets et à la culture de vos équipes. Passer d’un pilotage « rigide » à un pilotage « agile » n’est pas simple. Très souvent, il est nécessaire d’encadrer ce changement afin de garantir le succès de votre transition vers le modèle qui vous correspond.

Besoin d’un accompagnement ? Kanbios se tient à votre disposition pour vous épauler dans votre projet.