Scrum et Kanban : Retrouvez les différences et les complémentarités de ces deux méthodes agiles
Le terme agile définit une approche de gestion de projet / produit empirique, c’est à dire qui résulte de l’expérience commune.
Plus que de méthode agile, on évoque plutôt une culture ou encore une approche agile.
Et on nomme méthodes agiles les différentes méthodes issues de ce courant.
L’agilité est régie par un Manifeste datant de 1993, qui repose sur la valorisation :
- Des individus et de leurs interactions plus que des processus et des outils,
- Des logiciels opérationnels plus qu’une documentation exhaustive,
- De la collaboration avec les clients plus que la négociation contractuelle,
- De l’adaptation au changement plus que le suivi d’un plan.
Exit donc les cahiers des charges techniques détaillés en amont du projet et les plannings à long terme.
Plusieurs méthodes agiles découlent de cette approche : Scrum, eXtreme Programming, Rapid Application Development, etc.
Ces méthodes se basent sur l’implication du client tout au long du projet, qui se déroule en phases itératives et incrémentales.
Et bien que l’adaptation soit clé, ces phases se déroulent selon un cadre bien précis.
Cet article s’appuie sur un talk de Judicaël Paquet, Coach Agile et rédacteur du blog My Agile Partner, ‘Scrum & Kanban — différences et complémentarités’. Dans ce talk il revient sur les différences et les complémentarités de la méthode Scrum et de l’approche Kanban.
Vous pouvez retrouver la vidéo de ce talk par ici.
Méthode agile : Scrum
Le terme ‘scrum’ vient du monde du rugby et signifie ‘mêlée’. En effet le scrum s’appuie fortement sur les notions de collectif, d’esprit d’équipe et de solidarité.
Scrum est la méthode agile la plus populaire, notamment au sein des DSI. Il s’agit de la méthode la plus utilisée et donc la plus documentée et éprouvée.
Son cadre comprend :
- Des itérations courtes et répétitives (appelées sprint) et leurs cérémonies — les itérations durent 2 à 4 semaines, souvent 2 semaines, et sont rythmées et égales,
- Une équipe composée de 3 rôles clés,
- Un backlog contenant toutes les demandes fonctionnelles à traiter.
La réponse au besoin client est basée sur une approche incrémentale et l’amélioration continue. L’objectif est de s’améliorer au fur et à mesure des itérations, en s’adaptant, en ôtant des points inutiles ou en ajoutant des évolutions suite aux tests par exemple.
Bien au-delà du cliché de l’organisation par post-it, il s’agit d’être agile sur l’ensemble du scope produit tout en suivant un process très structuré.
La méthode Scrum repose sur ces 3 piliers :
- La transparence
Toute l’équipe et les parties prenantes peuvent visualiser la répartition des tâches et l’avancement du projet grâce au management visuel et aux différentes cérémonies qui jalonnent le projet. Et au-delà du travail réalisé, l’on partage aussi les succès et les difficultés rencontrées.
- L’inspection
Il ne s’agit pas de contrôler mais de s’harmoniser pour avancer dans la même direction et s’améliorer en équipe. - L’adaptation
Les rôles clés de la méthode Scrum
- Le Scrum master
Ce rôle est souvent incompris et associé à tort à un rôle de chef de projet.
Il s’agit à la fois d’un rôle de facilitateur, qui aide l’équipe à lever les obstacles de tout type (logistique et matériel, organisation, …), mais aussi d’animateur lors des cérémonies et également de médiateur au besoin.
Il facilite le travail mais veille également à l’excellence et au respect de la stratégie.
Le Scrum Master est aussi au service de l’entreprise et il l’accompagne dans l’adoption de la méthode Scrum : en planifiant les implémentations de Scrum au sein de l’entreprise, en aidant les employés et les parties prenantes à comprendre et adopter la méthode Scrum ainsi que le développement empirique de produits et en collaborant avec d’autres Scrum masters. - Le product owner
Véritable responsable fonctionnel, il est chargé de créer et de maintenir le backlog (listing de l’ensemble des demandes fonctionnelles du projet).
Il n’y a pas de cahier des charges complet établi dès le départ du projet, mais des lots de demandes qui sont définies et réalisées au fur et à mesure des sprints.
Le product owner est alors responsable de la priorisation fonctionnelle des demandes à prendre en charge lors des sprints, en accord avec les parties prenantes. - La ‘dev team’, composée des professionnels responsables des livrables à la fin de chaque sprint
En l’absence de chef de projet dans cette organisation, les développeurs sont autonomes et auto-organisés, et assument ensemble la responsabilité et les décisions techniques du projet. En plus du développement, ils réalisent donc aussi la documentation et l’architecture technique et sont responsables de la qualité technique. Pour ce faire, il convient idéalement d’avoir une équipe composée de développeurs pluridisciplinaires.
Les étapes et cérémonies de la méthode Scrum
- En premier lieu, le client fait part de son besoin et de ses demandes a minima au product owner, voire à l’ensemble de l’équipe.
Au besoin un priority meeting peut être organisé pour valider les points prioritaires. Cela est d’autant plus souvent nécessaire lorsqu’il y a de nombreuses parties prenantes. - À l’issue de ce point, le product owner prépare le backlog avec les différentes demandes fonctionnelles définies.
- Le sprint démarre alors par un sprint planning, lors duquel le product owner présente les demandes fonctionnelles à essayer de réaliser (selon la capacité de travail de l’équipe) à l’ensemble de l’équipe. Il s’agit d’un échange ouvert, lors duquel les demandes validées sont alors découpées en sous-tâches techniques par les membres de la dev team pour déterminer le travail à réaliser pendant le sprint.
Il faut noter qu’il s’agit d’objectifs, mais que si certains points ne sont pas terminés à la fin du sprint, ce n’est pas dramatique, on fera alors le nécessaire pour s’améliorer et le réaliser au prochain sprint. La qualité prévaut sur le délai de la livraison. - S’ensuit un sprint, généralement de 15 jours, qui comprend chaque jour une daily de 15 minutes. Ce point quotidien a pour but de s’harmoniser et de partager ce qui a été accompli. Ce sont essentiellement les développeurs qui prennent la parole pour dire ce qu’ils ont fait la veille, ce qu’ils ont prévu de faire aujourd’hui, et alerter s’ils rencontrent un problème.
- À la fin du sprint, une review est organisée. Lors de ce point de 30 minutes — 1h, le product owner et la dev team présentent le travail réalisé et l’avancement des objectifs aux parties prenantes, si possible en s’appuyant sur une démo. C’est l’occasion de récupérer du feedback sur le travail accompli.
- L’équipe se retrouve ensuite lors d’une rétrospective tous ensemble, pour faire une introspection du sprint réalisé et acter des axes d’améliorations à mettre en place.
Idéalement le Scrum master anime ce point de manière différente à chaque session par le biais d’ateliers variés.
Par exemple, en demandant à chacun sur un tableau commun de remplir les colonnes : ‘Qu’est-ce qui vous a rendu énervé/ vous a attristé/ vous a rendu super heureux lors de ce sprint ?’. Une fois que chacun a rempli les colonnes, on analyse les retours et on réfléchit ensemble aux axes d’amélioration. - Si nécessaire, le product owner peut organiser un product backlog refinement. Ce point d’1 heure maximum, qui peut être réalisé chaque semaine, a pour but d’affiner le backlog pour les sprints à venir.
On revient sur les tâches à réaliser ou à suivre, pour échanger et réaliser des estimations.
Les indicateurs de la méthode Scrum
L’indicateur principal, que l’on peut mettre en place pour la méthode Scrum, est la vélocité de l’équipe. Il s’agit de comptabiliser le nombre de point d’effort des tickets réalisés et passés en done à la fin de chaque sprint.
L’indicateur est observé uniquement au niveau de l’équipe, et non au niveau individuel.
Pour que cet indicateur soit plus pertinent, il convient de le coupler au taux de présence jour/homme. Car selon les disponibilités de l’équipe, une personne en vacances par exemple, la vélocité peut fortement varier d’un sprint à l’autre, sans que cela soit représentatif de la productivité de l’équipe.
Il s’agit d’un indicateur de suivi plus qu’un objectif à atteindre.
Le Kanban, une approche agile
Kanban signifie ‘enseigne, panneau’ en japonais.
Le terme tire son origine des fiches cartonnées utilisées dans la mise en œuvre de cette méthode de gestion.
Apparu chez Toyota dans les années 1950, le Kanban consiste à déplacer des fiches cartonnées sur un tableau, en les passant d’une colonne à une autre. Chaque fiche correspond à une tâche et chaque colonne à une étape. On déplace alors les fiches d’une étape à une autre sur le tableau pour visualiser l’état d’avancement.
Les tableaux peuvent être complexes, mais le principe reste toujours de représenter l’avancement des tâches pour créer des flux.
Cette méthode de gestion est issue de la philosophie du lean management dans le but d’optimiser la performance.
Il s’agit de management visuel qui permet de représenter l’état d’avancement d’un travail. Le management visuel est à dissocier des outils de gestion de projet tels que Jyra ou Trello, qui eux comprennent des descriptions et des règles fonctionnelles complètes. Ces outils sont complémentaires au management visuel, mais les tableaux Kanban permettent d’être compris rapidement par tous, alors que ces autres outils sont plus orientés IT.
Le Kanban n’est pas à proprement parler une méthode agile puisqu’elle ne répond pas aux différents principes du manifeste agile, mais elle s’y apparente.
L’objectif de la méthode Kanban est de faciliter le workflow des équipes en adaptant le volume des tâches à accomplir, mais sans rituel et avec moins de cadrage que la méthode Scrum.
Cette méthode de gestion gagne depuis en popularité, et se retrouve parfois utilisée dans la méthode Scrum.
Le Kanban est une méthode de gestion de flux tirés avec stock intermédiaire, contrairement au Scrum qui est une méthode de gestion en flux poussé.
Autrement dit, dans la méthode Scrum à chaque début de sprint on place dans un tableau un ensemble de demandes à réaliser qui sont ensuite traitées au fur et à mesure du sprint. Dans la méthode Kanban, on se base sur la prédiction pour définir un nombre maximum de tickets à traiter pour chaque catégorie de tickets et pour chaque étape. Par exemple, il ne peut y avoir maximum que 5 tickets affichés dans la colonne ‘To do’ dont 3 tickets concernant l’avancement du projet et 2 tickets concernant des bugs et idem pour les autres colonnes. Autre exemple, si dans la colonne ‘Test’ je ne peux avoir que 3 tickets, cela oblige à faire des tests réguliers pour continuer l’avancée du projet.
La philosophie de l’approche Kanban repose aussi sur le partage des ressources. Ainsi les développeurs peuvent être amenés à travailler avec GitFlow, qui permet de gérer le travail en équipe avec la mise en commun du travail réalisé et des livraisons (à ne pas confondre avec Git qui lui est un outil de versioning).
Les rôles clés de l’approche Kanban
Le Kanban n’a pas de rôle défini mais peut être intégré à une méthode Scrum ou à une autre méthode agile.
On retrouve toutefois le principe des sticks buddies, qui signifie que des travailleurs peuvent s’associer par pair pour déplacer les fiches de son binôme en cas de travail à distance de celui-ci par exemple.
Les indicateurs de l’approche Kanban
Les principaux indicateurs de cette approche sont :
- Le diagramme de flux cumulés
Il s’agit de cumuler le nombre de demandes à chaque étape (to do, test, etc.).
Ce diagramme permet de suivre les écarts, de visualiser les retards et les tâches qui s’accumulent, ainsi que la capacité des développeurs. Et ainsi de prendre des décisions sur la priorisation des demandes ou la taille de l’équipe par exemple.
Il peut être tenu et mis à jour par n’importe qui dans l’équipe.
- Le lead time
Cet indicateur représente la durée (en nombre de jours) d’une demande de sa formulation à sa mise en production.
Si l’on passe 1h sur la demande un jour, puis 2h le lendemain, on comptabilise 2 jours.
Le lead time d’une demande permet de juger si les délais de traitement d’une demande augmentent ou raccourcissent. - Le cycle time
Il représente également la durée d’une demande, mais dans ce cas, de sa prise en charge par un développeur à sa mise en production.
Cet indicateur permet de montrer la capacité de travail des développeurs : si le cycle time est trop long, il peut indiquer une surcharge de travail, et il peut donc être judicieux de revoir la limite à mettre sur les nombres de tickets — inversement s’il est trop court, il peut révéler une situation de travail dans l’urgence, ce qui signifie que l’équipe à moins de temps de réflexion et potentiellement moins d’excellence technique.
Il n’y a pas de cycle time ou de lead time, parfait mais ils permettent de suivre la progression de l’équipe. - Le cycle time by card
Il permet de comparer et suivre les cycle time de l’ensemble des tickets (avec en abscisse les tickets 1, 2, ... et en ordonnée le nombre de jours de réalisation pour chaque ticket).
Cet indicateur permet de visualiser le nombre de tickets qui dépassent l’écart type et de prendre le temps d’analyser les causes de ce dépassement. En en comprenant les raisons (si lié au degré de complexité par exemple), il est ainsi plus facile de proposer des axes d’amélioration si nécessaire.
À noter que ces indicateurs peuvent aussi être utilisés dans le cadre de la mise en place d’autres méthodes agiles, comme Scrum par exemple.
Méthode agile Scrumban : Combinaison du Scrum et du Kanban
Les méthodes Scrum et Kanban combinées se nomment le Scrumban. Cette méthode agile est de plus en plus populaire car elle s’appuie sur deux approches complémentaires.
La méthode Scrumban reprend seulement certaines parties de chacune des disciplines.
On conserve les rôles clés et itérations rythmées (bien que plus limitées) du Scrum avec des cérémonies, et on y ajoute la méthode des flux tirés avec stock intermédiaire du Kanban.
Les cérémonies de la méthode agile Scrumban
En Scrumban, on ne planifie pas les tâches à réaliser 2 semaines à l’avance donc il n’y a pas de sprint planning. Malgré tout on ne laisse pas les développeurs sans visibilité.
Le sprint planning est alors remplacé par un sprint objectives. Lors de cette cérémonie, l’équipe définit des objectifs sur lesquels elle aimerait aller d’ici à dans 2 semaines. Et aucune gravité si ces objectifs ne sont pas atteints, car il s’agit d’objectifs théoriques afin de partager une vision commune.
Il n’y a pas de découpage des tâches réalisé lors de ce point. Soit cette pratique est abandonnée, soit elle est réalisée en live au fur et à mesure des demandes. C’est à la dev team de choisir et d’ajuster au besoin.
La priorisation se fait, elle aussi, au fur et à mesure des demandes et de l’avancement du projet.
Concernant les autres cérémonies, comme pour la méthode Scrum, on conserve à l’identique : la daily, ainsi que le sprint review et la rétrospective, et si nécessaire priority meeting et product backlog refinement.
Les indicateurs de la méthode Scrumban
Il est possible de se baser sur l’ensemble des indicateurs déjà présentés pour la méthode Scrum et Kanban.
Généralement ce sont les indicateurs de la méthode Kanban, qui sont repris car ils sont souvent mieux compris et valorisés par la direction, et de plus les indicateurs Scrum, axés sur la planification n’ont donc plus lieu d’être dans une approche à flux tirés.
Afin de créer des roadmaps théoriques, les indicateurs suivants sont les plus utiles :
- Le cycle time moyen de chaque ticket,
- Le taux de demandes traitées par type de demandes (user story, bug, tâche technique, spike, …),
- Le débit de traitement.
Quand et pourquoi utiliser la méthode agile Scrumban ?
Il est intéressant de se tourner vers la méthode agile Scrumban dans les cas de figure suivants :
- Lors des projets pour lesquels la planification et le découpage du travail sont difficiles à prévoir sur des périodes de15 jours.
Par exemple, une équipe de data scientists en phase d’exploration va fonctionner sur de la recherche sans savoir en avance vers où elle va aller, puisque ce sont les résultats de la recherche qui vont influencer le projet. Il est donc compliqué d’évaluer leur travail et de leur proposer un sprint de 2 semaines, et leur to do se remplit donc au fur et à mesure de ce qu’ils découvrent.
Autre cas, si vous êtes principalement sur du traitement de bugs, il sera également difficile de toujours évaluer le travail à effectuer et le temps nécessaire à l’avance. - Lors de projets de taille plus importante avec plusieurs équipes agiles travaillant ensemble.
En effet une équipe Scrum est généralement composée de 7 à 9 développeurs maximum. Sur des projets de grande envergure nécessitant un plus grand nombre de développeurs, on peut alors faire travailler plusieurs équipes agiles ensemble sur le même projet. Cette pratique se nomme l’agilité à l’échelle et peut s’appuyer sur des frameworks agiles créés pour ce type d’organisation : SAFe, LeSS, Scrum of Scrum, etc.
Il peut alors arriver qu’une partie des équipes travaillent en Scrum et l’autre en Scrumban en toute complémentarité, selon les missions et les spécificités de chaque équipe. - Ou encore tout simplement pour des équipes qui ont une philosophie d’optimisation Kanban, et qui souhaitent profiter et s’appuyer sur les cérémonies de la méthode Scrum.
Métissage des méthodes agiles
Il est intéressant de noter que les différentes méthodes agiles s’influencent les unes les autres.
La méthode Scrum a intégré des points d’autres méthodes agiles, et notamment des pratiques de l’eXtreme Programming, telles que le poker planning et les user story, ou encore le TDD et le code review pour favoriser l’excellence technique.
Il est également tout à fait possible de proposer aux équipes de mélanger elles-mêmes les différentes pratiques agiles en sélectionnant les pratiques qui leur correspondent le mieux dans chaque méthode, puisque celles-ci sont complémentaires.
Il ne faut pas les forcer à adopter ce type de méthodologie, mais on peut montrer aux équipes un panel de ce qui existe et leur proposer d’intégrer des pratiques. Il faut que la proposition soit acceptée et non imposée afin qu’elle soit correctement adoptée et qu’il y a ait une réelle envie de l’appliquer.
Par exemple, imposer le pair programming pourrait faire baisser la productivité d’un développeur si cela ne correspond pas à sa manière de travailler. Dans ce cas, il convient plutôt de ne pas le pratiquer ou de le pratiquer uniquement ponctuellement lors de l’onboarding de nouveaux collaborateurs sur le projet par exemple.
Si vous avez trouvé cet article instructif et que vous souhaitez en découvrir plus sur l’agilité, je vous invite à découvrir nos autres articles du même sujet :
De plus, nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
