Imaginé en 2009 pour aider les équipes à passer en douceur de Scrum à Kanban, Scrumban est devenu un framework à part entière. S’il se présente comme une méthodologie hybride, Scrumban n’est pas pour autant l’addition de Scrum et de Kanban. Que retrouve-t-on des deux modèles ? Comment pratiquer Scrumban ? Initiez-vous à cette méthodologie en suivant les conseils de Coline, Scrum Master chez Wemanity.
1. Scrumban, le mix parfait entre Scrum et Kanban
Les frameworks Scrum et Kanban permettent tous deux de faire de la gestion de projet, mais relèvent chacun d’une logique bien particulière. Scrumban articule les deux frameworks en conservant les avantages de chacun d’entre eux.
Scrum et Kanban, deux approches différentes
Inspiré du Lean, Kanban est une méthode agile qui s’appuie sur un management visuel fort. C’est un cadre de cadencement hérité de l’industrie, et uniquement lié au concept de flux tiré. La production est donc déclenchée par la commande, ce qui vient limiter l’encours et rend possible le traitement des difficultés au fil de l’eau, dans une logique d’amélioration continue. Kanban est également connu pour sa dimension de management visuel. Dans ce mode de gestion de projet, les tâches sont en effet affichées à la vue de tous sur un tableau, de telle sorte que l’équipe suit l’avancement du projet en temps réel.
À l’inverse, Scrum fonctionne en flux poussé. Les tâches à accomplir sont définies au démarrage, avec un cadencement au sprint. Le framework se distingue par ailleurs par l’existence de rôles à distribuer et d’évènements à programmer.
L’articulation opérée dans Scrumban
Flux tiré ou flux poussé ? Dans Scrumban, c’est finalement la logique de flux tiré propre à Kanban qu’on retrouve. Le modèle emprunte en revanche bon nombre des éléments fondateurs de Scrum pour le reste. L’équipe est ainsi composée d’un Scrum Master, d’un Product Owner et de développeurs, tous ayant les mêmes responsabilités que dans une équipe Scrum. Comme dans Scrum, le travail s’organise avec un cadencement, une approche itérative et des délais courts, mais en utilisant un tableau Kanban.
Précision utile toutefois : contrairement à ce qu’on pourrait penser, Scrumban ne consiste pas à pratiquer Scrum d’un côté, et à avoir un outil de management visuel d’un autre ! « En Scrum, on peut aussi faire du management visuel » précise Coline. « Dans Scrumban, les tâches sont réalisées dès qu’elles sont faisables et embarquées au fur et à mesure. Au-delà de l’utilisation du tableau Kanban, l’équipe travaille donc différemment, sans que tout ne soit prévu à l’avance pour l’ensemble de la durée du sprint. »
Les avantages de Scrum et Kanban dans un seul framework
Les différences que présentent Scrum et Kanban leur donnent des atouts complémentaires. En pratiquant Scrumban, une équipe se donne donc l’opportunité de les cumuler !
Du côté de Kanban, la production à la demande permet d’optimiser les coûts, de détecter rapidement les difficultés et de les corriger. Le management visuel contribue quant à lui à instaurer un principe de transparence au sein de l’équipe. Il facilite la communication et sert notamment à visualiser les goulets d’étranglement. De façon globale, la méthodologie est reconnue pour améliorer la gestion du flux de travail et accélérer la résolution des anomalies en production.
S’agissant de Scrum, ce sont surtout les événements qui sont intéressants selon Coline : «Scrum est très cadré, avec des événements incontournables venant rythmer l’itération, chacun ayant son intérêt. La sprint review offre par exemple la possibilité de recueillir des feedbacks et de s’engager dans une démarche d’introspection, ce qui est précieux. Plus généralement, les événements Scrum permettent de garantir les trois piliers du framework, à savoir la transparence, l’inspection et l’adaptation. »
La rencontre de Scrum et Kanban présente enfin l’avantage d’allier la possibilité de disposer d’un cadre tout en conservant une certaine flexibilité. Autrement dit, de gommer la rigidité et la course à l’objectif souvent reprochés à Scrum.
2. L’essentiel à savoir avant de tester Scrumban
Scrumban s’adapte au contexte de production et de transformation. Pour autant, certains fondamentaux doivent être respectés pour pratiquer Scrumban.
La constitution de l’équipe
Si les rôles sont les mêmes que dans Scrum, l’équipe doit cependant bien comprendre le framework et intégrer ses particularités, notamment la mise en place d’un flux continu d’éléments. Cela vaut particulièrement pour le Product Owner, qui doit adopter une posture différente de celle qu’il a dans Scrum selon Coline : « Le Product Owner a toujours la responsabilité de prioriser le product backlog et l’ensemble des tâches à embarquer durant l’itération. Pour autant, il n’y a pas d’objectif de sprint. L’équipe se responsabilise au global.»
Par ailleurs, mieux vaut pratiquer Scrumban avec une équipe mature : « Le plus souvent, il s’agit de proposer Scrumban à une équipe Scrum souhaitant basculer sur Kanban, sachant qu’il est plus rare de proposer Scrumban à une équipe ne connaissant que Kanban. Pour que l’expérience soit concluante, il est à mon avis préférable que l’équipe soit à l’aise avec Scrum. L’idéal est même qu’elle soit auto organisée. Les membres de l’équipe doivent non seulement connaître les bonnes pratiques Scrum, mais aussi savoir prendre du recul sur leur travail et celui des autres. »
L’organisation du travail
Dans Scrumban, il n’y a pas de sprint backlog : le Product Owner distribue les tâches au fur et à mesure. Il attend ainsi que les développeurs aient terminé le travail en cours pour les solliciter à nouveau, dans les limites TEC (travail en cours) définies préalablement avec l’équipe.
C’est ainsi une logique de priorisation en temps réel qui prévaut, comme l’explique Coline : « On a un certain nombre de WIP (« Work In Progress » ou “travail en cours”), qu’on ne peut pas dépasser. On maximise le « done » (ce qui est fait) avant de pouvoir embarquer de nouvelles tâches. On fluidifie ainsi le travail et on limite la surcharge »
Le management visuel avec un Kanban Board
Pour travailler en Scrumban, l’équipe doit disposer d’un tableau représentant le workflow, avec des colonnes correspondant aux différentes étapes d’avancement.
Concrètement, il s’agit de prévoir les colonnes « à faire » (« to do »), « en cours » (« in progress ») et « fait » (« done »), en ajoutant une colonne « test ». L’utilisation du tableau est ensuite très simple. Chaque tâche est notée sur une carte Kanban, laquelle prend la forme d’un Post-it® (papier ou digital selon le support). Les tâches sont ensuite déplacées d’une colonne à une autre par les membres de l’équipe, jusqu’à être terminées et positionnées dans la colonne de droite. L’équipe est également libre de créer des codes couleur ou de classer les tâches par colonne en fonction de leur priorisation, éventuellement en ajoutant des numéros.
« Il est recommandé, parallèlement au tableau Kanban, de créer et utiliser un diagramme de flux cumulés » conseille Coline. « Grâce à ce graphique, on visualise les demandes qui s’accumulent. » Le board doit aussi faire apparaître clairement les limites WIP, c’est-à-dire la quantité de travail minimale et maximale autorisée.
Les cérémonies à prévoir
En Scrumban, il n’existe pas de planification de sprint. Il n’y a donc pas vraiment de réunion de sprint planning telle qu’elle existe dans Scrum. Dans la mesure où le Product Owner fixe un objectif sans présenter de users stories à développer, la réunion de démarrage se présente davantage comme une « sprint objective ».
L’équipe peut en revanche travailler en adoptant les autres événements Scrum :
- le daily, pour entretenir une communication fluide ;
- la sprint review, pour présenter les nouveautés sur le produit et obtenir des feedbacks pour prioriser et/ou ajuster les éléments déjà développés,
- la sprint retrospective, pour dresser le bilan du cycle de développement et dégager des axes d’amélioration.
Les indicateurs à suivre dans Scrumban
Ce sont les indicateurs de Kanban qui sont utilisés. Vous devez ainsi vous intéresser au Lead Time, c’est-à-dire au temps s’écoulant entre l’entrée d’une tâche dans le tableau Kanban à son classement dans la colonne « done ».
Le Cycle Time mérite aussi qu’on s’y attarde : « Il s’agit de regarder combien de temps une tâche reste dans une colonne. C’est important pour déceler les tâches chronophages et s’interroger sur les causes. »
Scrumban est-il fait pour votre équipe ?
Si Scrumban présente des atouts, il ne convient pas pour autant dans tous les contextes. « Certaines équipes testent le framework pour passer à Kanban, mais font le choix de conserver Scrumban », commente Coline. « En revanche, le modèle n’est pas magique ! Il ne viendra pas régler les difficultés rencontrées par une équipe dans l’utilisation de Scrum par exemple. Il faut donc l’utiliser parce qu’on souhaite profiter à la fois des atouts de Scrum ou de Kanban et parce que le projet s’y prête. Scrumban est ainsi adapté aux projets pour lesquels il est difficile d’évaluer la charge de travail au démarrage. »
Comme tout outil, Scrumban ne présentera de véritable utilité que si le mode de fonctionnement qu’il instaure répond à vos besoins spécifiques, quitte à l’adapter pour que votre équipe trouve ses marques.
