ScrumBan

Introduit par Corey Ladas dans son livre Scrumban, Essays on Kanban systems for lean software development, publié en 2008, Scrumban allie des aspects de Scrum à la gestion du flux de production de la méthode Kanban.

Inspiré du Lean Software Development, l’auteur cherche à optimiser le flux de production, en utilisant mieux les ressources disponibles et en retirant de Scrum ce qui lui paraît superflu : la redondance des fonctions de management, la polyvalence des individus, le rôle de Product Owner, le Sprint Planning, l’estimation détaillée des user stories, etc.

• Les bases de Kanban

  Scrumban reprend de Kanban le travail de définition de la chaîne de valeur, la visualisation du flux de production qui s’appuie sur un management visuel central et la division du travail en “éléments de travail” (ou tâches) qui peuvent être réalisées de façon autonome les uns après les autres, par différents métiers. 

   

  On retrouve également les règles du système qui limitent la quantité de travail à chaque étape du flux de production.

   

  Dans Scrumban, l’indicateur essentiel à suivre, repris de Kanban, est le temps de traversée du cycle de production. Selon l’auteur, le burn down chart devient superflu.

• Des aspects de Scrum

  Scrumban reprend de Scrum le rythme de planification, de revue et de rétrospective à intervalles réguliers, qui peut être de deux semaines ou plus.

   

  Le framework stipule aussi l’organisation de Daily Standup Meetings, sauf que, à la différence de Scrum, le facilitateur de l’événement énumère les tâches et non les membres de l’équipe.

• Les principes du Lean Software Development

  Dans l’objectif de ne pas faire de travail qui puisse se révéler inutile, Scrumban préconise de seulement préparer les éléments de travail qui entrent dans le prochain cycle de production. Ainsi, l’équipe de développement est toujours alimentée des meilleures tâches à réaliser à l’instant t. 

   

  De plus, selon l’auteur, il est inutile d’estimer chacun des éléments de travail, l’essentiel que la somme de tous les éléments de travail contenu de la backlog du cycle à venir soit réalisable au cours de celui-ci.

• Une organisation plus hiérarchique

  Contrairement à Scrum qui recommande la constitution de petites équipes autonomes – 3 à 7 personnes –, Scrumban préconise la constitution d’équipes à la gestion plus hiérarchique, qui englobent toute la chaîne de valeur, de la conception au déploiement. Une équipe Scrumban peut ainsi compter entre 20 et 50 personnes.

   

  L’organisation Lean s’articule ainsi autour d’expertises, dont le travail est divisé par nature : compétences ou appétences des individus. Le fonctionnement est, par conséquent, plus hiérarchique que dans Scrum.

• Une attention particulière portée à la gestion des flux entrants

  Comme il ne doit pas entrer dans le système davantage de tâches que ce qu’il est capable de supporter, une attention toute particulière est portée sur la gestion et la priorisation des éléments de travail entrant.

   

  Les éléments du backlog sont évalués en permanence, sous la forme d’un vote continu qui reflète les intérêts de toutes les parties prenantes. Quand une place se libère dans le système de production, l’élément qui possède le plus de votes entre dans le flux de production.

   

  Une demande critique, requérant une attention immédiate, peut survenir de temps en temps. C’est pourquoi Scrumban accepte de traiter une et seulement une urgence à la fois, cette carte joker est appelée Silver Bullet.