Scrumban : la fusion des frameworks Scrum et Kanban, un hybride agile

Print Friendly, PDF & Email
Wordcloud avec Scrumban comme sujet principal

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!

Expliquant comment apporter un peu plus de Lean dans Scrum en passant par Kanban : Corey Ladas, Scrum-ban[1]

 

Historique

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[2] ainsi que sur le guide de Claude Aubry[3], qui en expose ses origines ainsi que sa place au sein des méthodologies du mouvement agile[4].

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

K. Schwaber and J. Sutherland, The Scrum Guide[2]

À 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 [un des pères fondateurs de la méthodologie (ndlr)] 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é.

H. Takeuchi and I. Nonaka, The new new product development game[5]

Autre similitude avec Kanban[1], 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

 

Scrum

Loin de ne rien avoir à dire sur Scrum, nous orienterons ici le lecteur intéressé vers l’article éponyme (Scrum[6], 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).

A graphical view of Scrum implemented at a team level within an organization.

Fig: Scrum Framework

Scrum is a simple framework for effective team collaboration on complex software projects.[7]

Scrum en trois points

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[8] (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 :

  •  — une équipe auto-organisée avec ces trois rôles
  •  — des sprints et leurs évènements connexes
  •  — un backlog, i.e. le travail à faire

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.

 

Kanban

Tout comme pour Scrum, nous reprenons ici un article précédent sur Kanban[10] (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 :

Table : Kanban (5 properties, 5 principles)
source: Dimitri Ponomareff, Scrumban — Blending Agile, Scrum and Kanban into a methodology that works for you[8]
Properties Principles
  1. Visualize the workflow.
  2. Limit WIP.
  3. Measure and manage the flow.
  4. Make process policies explicit.
  5. Improve collaboratively using models and empirical evidene.
  1. Start with what you do now.
  2. Agree to pursue incremental, evolutionary change.
  3. Respect the current process, roles, responsibilities, and titles.
  4. Encourage acts of leadership at all levels.

Nous nous permettrons  alors de résumer l’approche Kanban comme suit :

  •  — Kanban est un système visuel de gestion du flux de travail (workflow management) visant une amélioration graduelle et continue de ce flux.
  •  — Kanban permet de mettre en place la planification, le travail, la revue et la mesure de la production de façon continue; c’est-à-dire en flux continue de production.

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.

Claude Aubry, Scrum: Le guide pratique de la méthode agile la plus populaire, 4èmeéd., Dunod, 2015

Vers Scrumban…

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

 

Crédits: Thierry Sorg, Scrum.org
Sources:
  1. Corey Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development, Lulu.com, 2008, ISBN-13: 978-0578002149
    [RET]
  2. K. Schwaber and J. Sutherland, The Scrum Guide, scrumguides.org, 11.2017 [dernière visite: 21.08.2020] [RET]
  3. Claude Aubry, Scrum: Le guide pratique de la méthode agile la plus populaire, 4èmeéd., Dunod, 2015, ISBN-13: 978-2100742165
    [RET]
  4. Manifesto for Agile Software Development, agilemanifesto.org, 11-13.02.2001 [dernière visite: 21.08.2020] [RET]
  5. H. Takeuchi and I. Nonaka, The new new product development game, Harvard Bussiness Review, Jan-Feb 1986
    [RET]
  6. Thierry SORG, Scrum: valoriser l’équipe pour améliorer le développement, gbnews.ch, 09.2020 [dernière visite: 02.12.2020] [RET]
  7. Scrum.org, [dernière visite: 09.09.2020] [RET]
  8. Dimitri Ponomareff, Scrumban — Blending Agile, Scrum and Kanban into a methodology that works for you, kanbanzone.com, 21.09.2017 [dernière visite: 04.12.2020] [RET]
  9. Ajay Reddy, The Scrumban [R]Evolution: getting the most out of Agile, Scrum, and Lean Kanban, Agile Software Development Series, Addison-Wesley, 07.2015, ISBN-13:978-0134086217
  10. Thierry SORG, GBN Talk 4: Kanban, gestion des workflows et amélioration continue — p.2, gbnews.ch, 07.2019 [dernière visite: 28.09.2020] [RET]
  11. Thierry SORG, GBN Talk 4: Kanban, gestion des workflows et amélioration continue — p.1, gbnews.ch, 07.2019 [dernière visite: 28.09.2020]
Thierry Sorg Thierry Sorg

Someone told me it may be a challenge for me to write technical articles for non-IT people... Guess what! I'm writing!

I'm a computer scientist with a previous background in ERP development and a taste for teaching.
I'm a scientist in the heart, so if it can be seperated in small pieces and then studied during hours with a magnifying glass, it will interest me. There's no doubt!

I think there is a good place to write my motto just after the very next colon: rather than programming solutions, I love to solve problems.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.