Scrumban : une méthode hybride entre Scrum et Kanban

La méthode Scrumban est l’une des méthodes agiles qui combine, comme son nom l’indique, les principes clés des frameworks Scrum et Kanban. On y retrouve donc des itérations courtes issues de la méthode Scrum ainsi qu’une dynamique d’amélioration continue évolutive et adaptative drivée par une bonne gestion des flux via la méthode Kanban.

En Scrumban, la priorisation des demandes utilisateurs ou métiers se fait au fur et à mesure de la capacité d’avancement de l’équipe produit. Il ne s’agit pas de planifier à l’avance les fonctionnalités à développer, comme on le pratique en Scrum, mais de prioriser les User Stories en temps réel afin de délivrer aux utilisateurs finaux le maximum de valeur dans les meilleurs délais.

Enfin, cette méthode ne précise pas les rôles attribués aux membres de l’équipe (au même titre que la méthode Kanban). Chaque membre est donc autonome et responsabilisé et c’est à eux qu’incombe le choix des tickets à réaliser au regard de leurs spécialisations.

Maintenant que les bases sont posées, allons plus dans le détail de cette méthode agile.

Dans quels cadres utiliser Scrumban ?

Il n’est jamais simple de choisir la méthode agile la plus appropriée pour le développement de son produit mais certains contextes sont propices à son utilisation.

1. La méthode Scrumban est généralement mise en place dans un contexte où il est difficile de prédire le travail à venir. Raison pour laquelle les équipes de support et de run sont très friandes de cette méthode.
2. Le contexte d’Agilité à l’échelle est également propice à l’usage du Scrumban puisque plusieurs équipes Scrum travaillent de manière resserrée sur un même produit. Il est donc plus simple de suivre l’avancement des équipes via un board visuel recensant l’activité de l’ensemble du train.

Comment passer à Scrumban ?

La maille de la User Story

Pour passer à la méthode Scrumban, le point de départ sera de mettre de côté la logique par tâches (issue du framework Scrum) au profit d’une logique par flux (issue du framework Kanban).

Représentation graphique du mix des deux frameworks Scrum et Kanban Source :

Il ne s’agit plus de découper des User Stories en sous-tâches fonctionnelles ou tâches techniques mais de faire avancer les User Stories dans leur ensemble du début à la fin du board visuel. Cette absence de détails permet à l’équipe produit de prendre des décisions efficaces au quotidien.

Les conséquences de la méthode Scrumban

1. On ne parlera plus en termes de pourcentage de complétion d’une tâche mais on s’attardera principalement sur l’état de la User Story (à faire, en cours, en revue…) et des éventuels points de blocage. Cela permet à l’équipe d’avoir une vision plus synthétique sur l’état d’avancement de la fonctionnalité au sein du workflow préalablement défini.
2. Les estimations ne sont donc plus chiffrées à la maille de la tâche, en points de complexité ou en taille de t-shirt, mais sont estimées à la maille de la User Story. De fait, un ticket correspond à une fonctionnalité et il y a donc autant de tickets que de fonctionnalités à développer sur le board visuel.
3. Pour finir sur les conséquences, les développeurs doivent “toucher à tout”. En effet, ils ne sont pas cantonnés à un périmètre technique spécifique comme on pourrait le voir classiquement dans une équipe produit. Ils sont, en revanche, responsabilisés sur l’ensemble du périmètre fonctionnel de la User Story. On ne parle donc plus de développeurs back end ou front end avec Scrumban : chaque développeur peut faire de tout et développe ainsi ses compétences techniques de façon 360° !

L’importance du board visuel

Le board de base

En Scrumban, la définition des différentes colonnes du board visuel de l’équipe par lesquelles les User Stories transitent est capitale.

Généralement, les équipes partent d’un board classique avec les colonnes : “A faire”, “En cours” et “Fini” auquel elles peuvent ajouter les étapes réelles du workflow par lesquelles les User Stories passent.

Source : formation Hubvisory

Il est important de noter que les ajouts de colonnes sur le board visuel ne sont pas toujours nécessaires, chaque projet ayant ses spécificités propres.

Par souci de praticité et dans la majorité des cas, chaque action d'une colonne est attribuée à un membre de l'équipe. Ainsi, le passage d’une colonne à une autre formalise le fait que la User Story passe à un autre état et est prise en charge par une autre personne de l’équipe. Cette convention permet de visualiser en un coup d'œil le “qui fait quoi ?”.

Le board enrichi de colonnes additionnelles

Suivant les sujets et les équipes produit, les colonnes fréquemment ajoutées à un board visuel classique peuvent être les suivantes :

• En revue (colonne située entre les colonnes “En cours” et “Fini”) : état durant lequel 2 développeurs travaillent sur un seul et même code (on parle régulièrement de pair programming) afin d’identifier efficacement les coquilles techniques et améliorations à y apporter.
• En recette (colonne située entre les colonnes “En revue” et “Fini”) : état durant lequel le Product Owner (PO) ou le Quality Analyst (QA) testent fonctionnellement - via les critères d’acceptance - les développements réalisés et identifie les bugs fonctionnels de la User Story.
• En rédaction (colonne située en amont du workflow de développement) : état durant lequel le Product Owner alimente l’itération afin de donner aux développeurs un maximum de visibilité sur les fonctionnalités à venir et d’anticiper ainsi les directions techniques du produit.

Source : formation Hubisory

Évidemment cette liste n’est pas exhaustive, chaque équipe est libre d’ajouter les colonnes représentant le mieux le workflow réel de son organisation. On peut toutefois inclure au board visuel des colonnes supplémentaires pour d’autres acteurs que les Product Owners et les Développeurs comme pour les UX / UI Designers, responsables métiers et / ou marketing, etc…

Les rituels relatifs à Scrumban

La fin des Sprints planning ?

En Scrumban, la quasi totalité des rituels du framework Scrum est conservée excepté le rituel du Sprint planning. En effet, comme le Product Owner alimente fréquemment la colonne “A faire” du board visuel, il n’y a donc pas à proprement parler de Sprint planning en début d’itération. L’équipe produit privilégiera alors des ateliers réguliers de présentation de User Stories (on peut même parler de “mini-grooming”) bien plus courts que des Sprints planning classiquement effectués sous Scrum.

Cette façon de faire permet à l’équipe produit de prendre plus de temps pour l’analyse des User Stories et d’éviter ainsi les nombreux allers/retours technico-fonctionnels.

La démonstration : l’équipe montre ce qui est terminé, et c’est tout !

En Scrum, il est important de présenter lors de la démonstration l’ensemble des fonctionnalités embarquées en Sprint planning.

En revanche, en Scrumban, l’équipe décide d’employer ce rituel de démonstration comme un “rendez-vous” durant lequel elle présente ce qu’elle a terminé pendant la période, et c’est tout ! En effet, il est très fréquent qu’en fin de sprint il reste des User Stories dans la colonne “En cours” du board visuel. Ces dernières ne sont donc pas présentées en démonstration et seront donc terminées lors de la prochaine itération.

Il n’est donc pas rare de se retrouver dans le cas de figure ci-dessous :

Source : formation Hubvisory

Comment tenir des objectifs produits sans cadre figé ?

C’est bien là que réside toute la complexité de Scrumban et que l’on constate la maturité d’une équipe produit.

Pour faciliter et simplifier la tenue des objectifs et maintenir une organisation d’équipe efficace sans cadre fixe, des limites WIP (Work in Progress) sont mises en place. Le principe derrière ces limites WIP réside dans le fait de limiter le travail en cours. On compte ainsi une tâche par Développeur et tant que cette tâche n’est pas terminée, autrement dit, tant que cette tâche n’est pas passée par toutes les étapes du workflow du board visuel, le membre de l’équipe ne passe pas à autre chose. La règle est donnée : on termine ce qui a été commencé.

Cette dynamique de flux tirés et de développement continu provoque une évolution profonde du rythme de travail du Product Owner qui doit alimenter au fur et à mesure l’itération en User Stories dans la colonne “A faire”. Ainsi il n’y a jamais de trou dans la raquette ou de pénurie de travail. Tous les membres de l’équipe produit ont toujours des tickets à se mettre sous la dent permettant d'asseoir un rythme de développement quotidien et constant.

Les avantages de la méthode Scrumban

Maintenant que les grands principes de cette méthode sont clairs, parlons des principaux avantages de Scrumban.

La méthode Scrumban a l’avantage :

• de s’adapter à des contextes où il est compliqué de quantifier et prévoir le travail à effectuer sur les semaines à venir,
• d’être flexible et adaptable en accueillant le changement ainsi que les nouvelles demandes au fil de l’eau et de ne pas respecter à la lettre la dynamique de sprint,
• de permettre à l’équipe de prioriser les fonctionnalités au fur et à mesure qu’elles arrivent suivant les demandes métiers (ou émanant des utilisateurs) et la capacité d’avancement de l’équipe,
• d’être moins génératrice de stress pour les membres de l’équipe qui choisissent leurs missions,
• de bénéficier des avantages des méthodes Scrum et Kanban et d'être ainsi l’une des méthodes les plus agiles.

Les inconvénients de la méthode Scrumban

Une méthode sans inconvénient ça serait bien trop facile.

Ci-dessous plusieurs réticences à partir sur la méthode Scrumban :

• la difficulté à gérer les objectifs à moyen et long terme,
• la complexité que peut générer l’auto-organisation des membres de l’équipe,
• la non-adaptation de la méthode à tous les types de contextes produit,
• la nécessité de disposer d’un certain niveau de maturité des membres de l’équipe pour maintenant un rythme constant quotidiennement.

Evidemment, les deux listes ci-dessous ne sont pas exhaustives mais permettent d’avoir une vue d’ensemble sur les contours de cette méthode.

En conclusion

La méthode Scrumban est l’une des méthodes agiles les plus agiles puisque son application permet aux équipes de s’auto-gérer, d’accueillir le changement et de prioriser le quotidien afin de répondre dans les meilleurs délais aux besoins des utilisateurs.

La flexibilité de cette méthode permet également à l’équipe produit de gagner du temps sur l’animation des rituels. Fini les Sprints planning interminables, bonjour aux ateliers courts et réguliers vecteurs de cohésion et de productivité !

A vous de jouer maintenant et d'insuffler la dynamique Scrumban à vos équipes produit (si le contexte le permet bien évidemment).