Scrumban, un bon compromis entre Scrum et Kanban

Blogues

Scrumban, un bon compromis entre Scrum et Kanban

Un peu de Scrum, un peu de Kanban, beaucoup d'efficacité 

La quatrième édition de notre Petit-déj Agile s'est déroulée le 25 janvier au matin. Au menu du jour, une méthode de plus en plus utilisée par les équipes de développement et qui combine deux autres méthodes agiles : Scrumban, pour Scrum et Kanban. Pourquoi mélanger ces deux méthodes ? Dans quel contexte peut-on l'utiliser ? Qu'est-ce que cela apporte à l'équipe ? Toutes ces questions ont été abordées durant notre meetup, et nous allons vous en faire un résumé dans ce nouvel article.

C'est quoi, Scrum ?

Avant d'aller plus en détail dans Scrumban, il est judicieux de se pencher sur les deux méthodes dans lesquelles il prend ses sources. Nous avons déjà parlé assez en détail de la méthodologie Scrum dans un précédent post. Mais une petite piqûre de rappel ne fait jamais de mal !

Scrum, c'est ce qu'on appelle un framework, un cadre de travail. Celui-ci inclut la notion d'itérations courtes (sprints), qui durent en général de 2 à 4 semaines, pour réaliser un produit morceau par morceau. Ces itérations sont rythmées, ponctuées par des réunions appelées "cérémonies" ou "rituels", comme les daily scrum, des réunions quotidiennes, les revues de sprint à la fin d'une itération ou encore les rétrospectives pour améliorer la façon de travailler de l'équipe. Scrum induit aussi la notion d'incrément : au terme de chaque sprint, on améliore le produit, on peut ajouter ou supprimer des items selon les retours du client.

Dans la méthodologie Scrum, trois rôles sont mis en avant : le Product owner (PO), le Scrum master (SM) et l'équipe de développement. Pour résumer rapidement, le PO est identifié en tant qu'expert du besoin. C'est lui qui va traduire les besoins du client et se poser en tant que garant du produit. Le SM est, lui, le garant de la méthodologie, mais il est aussi un facilitateur : il facilite et provoque les événements Scrum lorsqu'il le faut (daily meeting, revues de sprint, planification...). Enfin, l'équipe de développement est là pour réaliser le produit selon les user-stories présentes dans le backlog de sprint. Ces rôles sont indispensables dans une équipe Scrum.

C'est quoi, Kanban ?

La méthodologie Kanban est une méthode de gestion du travail à flux tirés inventée dans les années 1950 par Toyota. Il s'agissait d'un simple tableau des tâches (à faire, en cours, terminé) avec des fiches cartonnées, qu'il fallait changer de colonne à mesure que le travail avançait. Cette technique de flux tirés (pas de nouvelle demande tant qu'il n'y a pas de place dans le board) permet de limiter les gaspillages et d'être le plus efficace possible dans son travail.

 

Beaucoup d'équipes aujourd'hui travaillent avec ce tableau des tâches, puisqu'il permet à tous de visualiser le travail en cours, dans un souci de transparence. Mélanger Scrum et Kanban est aujourd'hui nécessaire pour certaines équipes qui ont du mal à mettre en oeuvre Scrum. C'est un bon compromis, puisqu'on va garder des éléments des deux méthodes pour en créer une nouvelle plus adaptée à la réalité des projets.

Scrumban, le compromis entre Scrum et Kanban

La méthode Scrumban fait son apparition en 2009, proposée par Corey Ladas dans son essai "Scrumban : and other essays on kanban systems for lean software development". Elle est censée aider les équipes Scrum à transiter vers les concepts Kanban et Lean. On va garder un peu des deux méthodes Scrum et Kanban pour créer ce nouveau cadre de travail :

- De Scrum, on conserve les itérations ryhtmées et les rôles clés de PO, SM et équipe de dev

- De Kanban, on garde la méthode de gestion à flux tirés

Bien évidemment, chaque équipe va adapter cette méthodologie à son contexte et son environnement de travail. C'est l'un des principes mêmes des méthodes agiles, à savoir l'adaptabilité.

On peut mettre en place Scrumban pour différentes raisons. Par exemple, dans un contexte de travail où on ne peut pas vraiment prédire le travail à venir sur les deux ou trois semaines à venir, notamment dans les équipes de support. Cela permet d'atteindre les objectifs plus facilement. On peut aussi mettre en place Scrumban dans les contexte d'agilité à l'échelle, lorsque plusieurs équipes Scrum travaillent ensemble sur un même projet.

Dans Scrumban, on ne fait pas de planification de sprint. En revanche, il faut tout de même que les développeurs sachent quoi faire durant leur sprint. On va donc plutôt parler d'objectif de sprint : le PO va donner les objectifs du sprint que doit réaliser l'équipe sur les deux semaines à venir. On ne fait plus de poker planning en Scrumban : le découpage des user-stories en sous-tâches se fera au fur et à mesure que les développeurs réalisent les US. Il n'y a donc, par extension, plus besoin de calculer la vélocité de l'équipe, puisque l'on travaille selon la méthode de flux tirés issue de Kanban. Le PO ajoutera une US dans le board à chaque fois qu'un dev en terminera une. Scrumban bénéficie des rituels et rôles de Scrum, comme nous l'avons expliqué précédemment dans l'article. La méthode est donc toujours rythmée par les daily scrum, les revues de sprint, les rétrospective... Et l'équipe reste la même que celle de Scrum : un PO, un SM et une équipe de dev. 

Cette méthodologie se révèle vraiment intéressante pour les équipes Scrum qui veulent transiter aisément vers les concepts de Kanban. Les indicateurs de cette méthodes sont très efficaces pour suivre la production, mais aussi pour mettre en place des sprints stables et rythmés.

00

Plus d'entrées de blog

thumbnail
thumbnail
Ajouter des commentaires
Powered by Liferay - Copyright © Beorn Technologies 2020 - Mentions légales