Scrum n’est pas une méthode agile

Bien que Scrum fasse partie des termes les plus courants lorsqu’on aborde l’agilité, il ne s’agit pas pour autant d’une méthode agile. Rappelons en préambule que Scrum est apparu en 1986 dans une publication de deux universitaires japonais décrivant via la métaphore de la mêlée de rugby une nouvelle méthode de développement de produits. L’idée de créer une équipe multidisciplinaire a ensuite été reprise par Ken Schwaber en 1996, qui a théorisé les principes de ce cadre tel qu’on le connaît aujourd’hui. À cette mêlée, il a ajouté sa conviction que l’ensemble des tâches menant à la réalisation d’un projet complexe ne peut pas être planifié parfaitement dans un environnement imparfaitement prévisible.

Scrum répond à la complexité en s’appuyant sur trois piliers permettant une approche empirique : transparence, inspection et adaptation. Ces trois piliers sont incarnés en cérémoniaux rythmant les sprints, ces itérations d’une à quatre semaines au cours desquelles nous retrouvons :

- Le daily-meeting : chaque matin, les membres de l’équipe se retrouvent pour quinze minutes et abordent à tour de rôle les tâches traitées la veille, les problèmes rencontrés et les tâches qu’ils traiteront dans la journée. Chaque membre de l’équipe se doit d’être transparent sur les problèmes qu’il rencontre pour mieux les résoudre collectivement.

- Le sprint planning : en début de sprint, la Scrum Team définit un objectif de Sprint et dresse une liste de tâches à traiter durant l’itération. Il en résulte un Sprint backlog composé de tâches bien spécifiées et priorisées.

- La revue : en fin de sprint, la Scrum Team (Product Owner, développeurs et Scrum Master) se réunit pour examiner ce qui a été développé (l’incrément) et récolter un maximum de retours qui seront qualifiés en tâches pour les prochaines itérations.

- La rétrospective : la revue est au « quoi » ce que la rétrospective est au « comment » : l’équipe de développement recense et capitalise sur les problèmes rencontrés durant le sprint afin d’améliorer son organisation et être plus efficace. La rétrospective est un élément-clé de l’amélioration continue et de la quête du « zéro-déchet ».

Scrum est donc un cadre destiné à rythmer le développement : à chaque sprint ses réunions de cadrage, de clôture, encadrant le travail sur des tâches définies en amont. Et pas de changement pendant la période ! Sauf en cas d’urgence : incident de production, pivot remettant en cause les tâches du sprint, etc. Quotidiennement, faire le point sur les en-cours et les points de blocage pour avancer au mieux. On produit, on apprend, on s’améliore. L’équipe devient meilleure au fil des itérations, et la vélocité augmente. Sans jamais négliger la qualité !

Kanban est une méthode agile

La méthode Kanban a été inventée par Taiichi Ōno, ingénieur japonais à qui l’on doit également le système de production du toyotisme. Le nom signifie « panneau » ou « étiquette », et désigne la fiche de commande fixée sur le conteneur destiné au fournisseur, qui déclenche la production et assure le suivi de sa progression. Cette méthode de gestion des stocks dite « à flux tiré » permet de minimiser les stocks, et donc diminuer les coûts et le gaspillage. Le but est de diminuer le nombre de kanbans en circulation pour diminuer l’en-cours et permettre de produire à la demande. C’est bien ici le besoin qui tire la production. Zéro déchet, zéro stock. On voit donc clairement le parallèle en gestion de projet : diminuer l’en-cours permet d’augmenter la concentration des équipes, donc la qualité du livrable, mais également de livrer rapidement et plus régulièrement.

Qu’est-ce que Scrum et Kanban ont en commun ?

Scrum et Kanban mettent tous deux l’amélioration continue au cœur du process. Ils permettent aussi d’aborder la complexité avec plus d’aisance, en séparant en tâches simples des macro-demandes. Le management visuel est également un facteur commun : les tâches sont matérialisées sur un tableau pour fluidifier grandement le flux des travaux à travers le processus de développement.

Quelles sont leurs principales différences ?

Le rythme

Scrum est plus rythmé que Kanban : le Sprint est une unité de temps dédiée à résoudre les tâches sélectionnées par l’équipe lors du planning afin d’atteindre un objectif défini. L’équipe de développement opte pour un nombre donné de points de complexité, et toute nouvelle demande ne pourra pas être traitée avant la fin du Sprint. Ce que l’on perd en agilité est gagné en concentration pour l’équipe, qui n’est pas poussée à attaquer de nouveaux sujets par intermittence. Les points de complexité sont calculés sur la base de 1 point = la tâche la plus simple possible, chaque tâche est évaluée sur cet étalon. Les estimations s’affinent itération après itération, à mesure que l’équipe gagne en séniorité sur le projet.

Kanban en revanche n’inclut aucune période délimitée dans le temps ou d’itération. Tout s’y passe en flux continu : la production, l’amélioration continue, la priorisation des nouvelles demandes. Nul besoin d’attendre la fin d’un Sprint pour attaquer de nouveaux sujets.

Kanban paraît plus adapté pour traiter un grand nombre de sujets différents : la livraison en continu permet d’échelonner les plans de tests. Si tout est livré en fin de Sprint, cela crée une saisonnalité dans le planning qui peut amener à des bouchons en cas de volume élevé.

Les outils de management visuels

La différence de cadence entre Scrum et Kanban est visible sur les tableaux respectifs : pour Scrum, le flux de travail est entièrement décrit, depuis l’étape « À faire » jusqu’à celle du « Réalisé », où toutes les tâches devront figurer en fin de Sprint. Les tâches restantes seront reportées sur le Sprint d’après, au côté des nouvelles demandes.

Le tableau de Kanban comporte également des colonnes, mais chacune a une limite stricte de tâches qu’elle peut accueillir. Rappelons-nous qu’un en-cours plus faible garantit de répondre au besoin en temps réel. Chaque tâche suit son cours et les nouvelles demandes sont ajoutées au fil de l’eau. Les tâches sont réévaluées lorsqu’elles sont finies, ainsi on ne mesure pas la vélocité comme dans Scrum, mais plutôt le délai entre émission du besoin et réponse apportée.

En conclusion, les méthodes agiles permettent de pallier la complexité croissante des projets avec le souci de l’efficacité et du progrès. Elles proposent un panel d’outils pour organiser le travail afin de faciliter la vie des développeurs.

Bien qu’ils ne soient pas de même nature, Scrum et Kanban ont de nombreuses similitudes du point de vue du management visuel et de l’amélioration continue.

Ce sont deux approches de la gestion de projet centrées sur le produit. Il n’y est pas fait mention de « chef de projet », mais de « Product Owner ». L’objectif est bien ici de réduire les cycles afin de développer rapidement les prochaines fonctionnalités à mettre en production. Le besoin est constamment en évolution. Finis les cahiers des charges entraînant un effet tunnel dévastateur, place aux incréments délivrés régulièrement. Quant à savoir à quelle école se vouer, tout dépend, finalement, de son besoin !

Par Jordan Goyon - Scrum Master - Big Data chez Mind7 Consulting