
Scrumban : la fusion des frameworks Scrum et Kanban. Un système agile hybride, issu de la maîtrise des méthodologies qui le composent
Scrumban est un système Agile hybride. Scrumban, c'est la fusion des frameworks Scrum et Kanban.
Nous pourrions dès lors penser qu'une telle réunion consiste surtout à ne profiter que des avantages de chaque parent. Toutefois, une équipe agile — qu'elle soit Scrum ou Kanban — qui opte pour cet hybride cherche généralement, à améliorer sa capacité de travail, sa productivité ou la qualité de celle-ci, par le biais d'une adaptation de la méthodologie qu'elle pratique.
Pour mieux comprendre comment se compose cette hybridation, il convient de s'intéresser à l'historique de ces systèmes, puis d'expliciter, dans un deuxième temps, leurs principaux aspects. Un second article sera plus spécifiquement consacré à Scrumban en tant que tel afin de mettre en avant les implications de sa mise en place dans une organisation.
At this point, we are now operating a simple kanban pull system. We still have our time-boxed iteration and planning cycle, so perhaps we might call such a thing a Scrumban system!
Corey Ladas, dans son article Scrum-ban de 2008, décrit l'évolution possible d'une équipe Scrum vers un système Lean en intégrant Kanban dans leur framework. Bien que la paternité du terme lui soit attribuée, on le devine, l'historique de Scrumban est, en fait, l'historique de ces deux composants ou parents. Un précédent article donne l'historique de kanban. Pour ce qui est de l'autre parent, Scrum, cet article s'appuiera sur le Scrum Guide de Schwaber et Sutherland ainsi que sur le guide de Claude Aubry, qui en expose ses origines ainsi que sa place au sein des méthodologies du mouvement agile.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
À l'instar de Kanban, Scrum n'est pas si récent. En effet, le terme, dont la référence au rugby est notoirement connue, a été repris d'un article du Harvard Business Review de 1986 faisant état de méthodes mises en place par certaines compagnies américaines et japonaises pour rester compétitives dans le développement de leurs nouveaux produits. Les auteurs mettent en évidence le besoin de rapidité et de flexibilité des équipes de développement. Pour pallier cela, ces compagnies ont adopté une vision plus holistique du développement, où il n'est plus question d'opérations successives dans un projet ou sur un produit. L'idée est plutôt de prendre l'équipe de développement comme un tout qui porte le projet à son terme; de là, s'explique la comparaison avec une équipe de rugby.
Aubry rapporte l'anecdote selon laquelle le terme « scrum », bien qu'anglais et signifiant "mêlée", a été choisi par les auteurs car les japonais sont amateurs de rugby. Il rappelle entre autres que "Jeff Sutherland s'est appuyé sur cet article pour donner son nom à Scrum".
L'approche séquentielle traditionnelle autrement appelée "course de relais", pour développer un produit — illustrée par le système de planification de programme en phase — peut entrer en conflit avec les objectifs de vitesse et souplesse maximum. Au lieu de cela, une approche globale comme au rugby — où une équipe essaye de parcourir la distance en étant solidaire, se passant le ballon de main en main — peut mieux servir les exigences de compétitivité.
Autre similitude avec Kanban, Scrum n'a pas été directement lié aux méthodes agiles. En effet, même s'il a pour toile de fond une certaine indépendance du domaine dans lequel il est appliqué, il a souvent été déployé pour le développement informatique. Il faudra tout de même attendre de passer le cap des années 2000 pour voir Scrum associé au terme « agile », avec l'apparition du Manifeste agile
Loin de ne rien avoir à dire sur Scrum, nous orienterons ici le lecteur intéressé vers l'article éponyme (Scrum, septembre 2020). Il présente succinctement la méthodologie et discute quelques peu de son implantation dans des équipes de jeunes générations (Millenials ou génération Z).
Fig: Scrum Framework
Scrum is a simple framework for effective team collaboration on complex software projects.
Une définition de Scrum serait assez simple : c'est un framework dans lequel une structure légère et facile à comprendre est mise en place. Nous accepterons les termes de Dimitri Ponomareff, dans son article Scrumban — Blending Agile, Scrum and Kanban into a methodology that works for you (oct. 2017), qui résument cette structure comme composée de cinq évènements, trois rôles et trois artefacts. Autrement dit — et pour ceux qui connaissent un peu le sujet — Scrum est souvent vu comme ayant :
Afin de parachever cette définition, il doit être gardé à l'esprit que cette structure ne définit pas la façon de travailler. En tant que process framework, Scrum donne les règles qui lient les éléments de cette structure et il permet d'encadrer le travail d'une équipe.
Tout comme pour Scrum, nous reprenons ici un article précédent sur Kanban (juil. 2019), sur sa mise en place et les questions que cela soulève. Le lecteur intéressé pourra aussi s'orienter vers l'article, moins technique, de Françoise Baroffio donnant un exemple simple et concret de sa mise en place par le biais d'une expérience ludique : le Pizza Game, proposé lors du GBN Talk 4 par Robert Falkowitz. Les points essentiels du framework sont listés dans le tableau (en anglais) ci-après :
Nous nous permettrons alors de résumer l'approche Kanban comme suit :
Ces deux définitions semblent similaires. La seconde montre cependant Kanban au niveau d'une équipe de développement; c'est-à-dire la vision de Kanban comme une méthodologie agile pour le développement. La première définition, elle, montre plutôt Kanban comme une méta-méthode (même si elle n'en n'est pas une) qui s'appliquerait à un processus de développement.
On a vu que Scrum n'est pas vraiment une méthode, mais un cadre. Kanban n'est pas non plus une méthode agile, c'est une méthode d'amélioration de processus ou une méthode de gestion de flux.
Nous pouvons le voir, Scrum et Kanban ont des points communs, mais aussi des différences… ou plutôt, des divergences dans leurs mises en application. Si le but reste principalement le même pour tout framework, méthodologie ou approche de développement — qu'il soit informatique ou non —, il n'y a néanmoins pas de voie royale.
La suite de cette article se prêtera à l'exercice de l'état des lieux entre Scrum et Kanban, ainsi que sur la façon dont ils peuvent se mesurer. Le framework Scrumban ne sera pas présenté comme une simple accommodation de chacune des parties; la discussion montrera que c'est la recherche d'une maîtrise de la pratique de ces frameworks qui permet d'aboutir de façon réussie à leur fusion.
Lectures complémentaires :
Scrum : valoriser l’équipe pour améliorer le développement par Thierry Sorg
Using Scrum in Digital Communication by