Changer pour la méthode Scrumban ?

Le Scrumban est une méthodologie récente qui combine le Scrum et le Kanban. Elle a été créée pour faire une transition du Scrum au Kanban.

Si cette méthodologie agile peut être très intéressante dans certains cas, elle peut aussi apporter son lot de problèmes. Le Scrumban a pour but de mieux gérer un flux tendu comme par exemple la correction de bugs.

Certaines équipes vont l’utiliser aussi dans des contextes où la planification de travail sur 2 semaines est impossible ; nous pourrions citer les équipes réseaux, les équipes supports…

Les gains et pertes du Scrumban par rapport au Scrum

Cette méthodologie permet de garder les notions d’itérations proposées par le scrum tout en ayant une planification en quasi temps réel. Cette façon de s’organiser apporte son lot de gains pour certaines équipes mais comporte des risques à ne pas négliger.

Scrumban : gestion du backlog venant du kanban

Nous utilisons généralement cette méthodologie lorsque l’équipe est incapable d’organiser son travail en Sprint de deux semaines ; cela est souvent du au contexte qui impose de nombreux changements de dernières minutes. Cette méthode agile apporte justement une capacité de gestion de flux tendu.

Si le Scrumban propose des itérations (on va plutôt choisir 2 semaines), il ne propose plus ce concept de sprint backlog. Le Product Owner donnera des items à l’équipe de réalisation tout au long des sprints quand ceux-ci auront fini les travaux en cours.

La gestion des items dans cette méthode est la même que dans le kanban (article sur les bases du Kanban). Contrairement au scrum, le scrumban sera un travail réalisé en flux tiré et non plus en flux poussé.

Article : Différence entre le flux poussé et le flux tiré

Il faut d’ailleurs suivre l’avancée des demandes en tenant un diagramme de flux continue qui repartira à 0 à chaque itération afin de bien visualiser l’avancement des travaux ; on peut en déduire d’ailleurs une capacité de traitement par les équipes.

Scrumban : une priorisation en temps réel

Pour être le plus agile possible, le Product Owner réalisera de la priorisation en temps réel. A chaque nouvel item créé, il reverra la priorisation de son backlog pour livrer un maximum de valeur le plus tôt possible.

Article : Livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée

Cela impliquera beaucoup plus de rigueur et un travail encore plus en juste-à-temps par rapport au scrum. Le Product Owner devra donc être extrêmement organisé pour être en capable de suivre la bonne cadence. Il n’aura pas plus de travail en soit mais il devra être encore plus multitâche qu’en scrum.

Scrumban : les cérémonies et atouts du Scrum

Le Scrumban permet cependant de garder toutes les cérémonies du Scrum sans exception afin de garder un cadre d’organisation solide. La méthode garde aussi les 3 rôles clés du scrum : scrum master, product owner et équipe de réalisation ; il est vrai que le rôle de scrum master apporte tellement quand il est bien tenu que le supprimer serait douloureux pour l’équipe qui passe en Scrumban.

Mise en situation du Scrumban

Je suis personnellement assez méfiant à la mise en place de cette méthode car elle est souvent mise en place pour avoir beaucoup plus de réactivité et donc de répondre à une demande business pressante. C’est souvent le cas dans les entreprises où le mindset agile n’est pas encore assimilé.

Pour ma part , je l’ai déjà conseillé pour des équipes qui ont une obligation de répondre à des demandes impossibles à planifier comme par exemple dans les équipes de support. Certes, dans ce type d’organisation, nous avons d’énormes silos mais la méthode permet d’améliorer considérablement le fonctionnement de ces équipes.

La suppression de silos dans les grandes entreprises met des années à se mettre en place et la mise en application de cette méthode est un plus pour les individus.

J’ai eu l’occasion de mettre en place le Scrumban dans un contexte intéressant très particulier.

L’équipe de 13 personnes que j’avais, se voyait régulièrement confrontée à un grand nombre de perturbations (des demandes s’insérant dans le sprint backlog en cours de Sprint [bugs et petites évolutions]). Après une proposition de ma part, l’équipe a accepté de se diviser en 2 : une équipe de 8 développeurs en Scrum et une équipe de 3 développeurs en Scrumban.

L’équipe de Scrumban avait le rôle de gérer tous les bugs et les petites évolutions alors que l’équipe Scrum avait pris le rôle de gérer les projets. Les deux équipes partageaient par contre les mêmes cérémonies et les membres du Scrumban changeaient à chaque itération dans le but de ne jamais isoler personne.

D’ailleurs, les équipes partageaient les mêmes Scrum Master et Product Owner.

Ce choix de faire du Scrumban a été très bénéfique car il a permis d’avoir des Sprint (pour l’équipe scrum) très stables ; cela a permis de beaucoup mieux gérer les plannings qui sont liés au Sprint.

Conclusion

Dans certains contextes le Scrumban peut-être bénéfique dans les organisations mais il faut faire attention à bien réfléchir avant de l’appliquer.

Dans certaines entreprises où l’Agile n’est pas encore culturellement accepté, ceci peut-être un retour à de mauvaises pratiques non Agile. Le mieux c’est de se faire accompagner par un coach Agile pour savoir si ce changement est judicieux dans votre contexte.