J’ai trouvé la métaphore ultime pour expliquer à un client le fonctionnement des Sprints de Scrum.

Comme vous le savez le Client, le Scrum Master et l’Equipe se réunissent au début de chaque Sprint au cours d’une réunion de 2 heures afin de fixer la liste des développements pour le prochain Sprint. Autour de la liste des fonctionnalités à développer (le product backlog) l’objectif en 2 heures est que le Client finalise avec l’Equipe la liste des développements à venir pour le prochain Sprint. Ensuite un des principes de Scrum est que lorsque l’équipe développe, elle ne doit pas être interrompue. Ce principe permet à l’équipe de travailler efficacement sans être perturbée en permanence par ce que j’appelle des « fausses urgences ». Le Client est en quelque sorte tenu de respecter cette règle. Et croyez-moi, au final cela fonctionne mieux que d’interrompre en permanence une équipe de développement.

Revenons au titre de ce billet. Comment expliquer à un Client que l’équipe ne peut produire qu’une quantité limitée d’éléments dans les 2 semaines à venir ? Comment lui expliquer qu’il doit alors faire un choix et donner une priorité pour chaque élément ? Comment lui expliquer qu’il ne pourra pas changer le contenu du sprint ?

Prenez une machine à laver le linge.

Vous avez un tas de linge sale : voici votre Product Backlog. Votre famille « alimente » en permanence ce Product Backlog chaque jour. De la même façon en Scrum les clients peuvent mettre à jour le product backlog en permanence.

Ensuite prenons notre lave-linge : il ne peut laver qu’une certaine quantité de linge à chaque programme. Par exemple 5 Kg. Et bien de la même façon, une équipe ne peut produire qu’une certaine quantité de fonctions par itération. Un Sprint de Scrum est donc égal à un lavage en machine. Pour expliquer à un client pourquoi l’équipe refuse de prendre plus d’éléments, je me sers de cette image. Je peux aussi lui dire que sa voiture n’a que 40 litres d’essence dans le réservoir. Il doit s’en contenter. Il faut donc que le client comprenne que « la capacité de production est limitée » et que c’est l’équipe qui annonce cette capacité.

Ensuite regardons ensemble ce que fait quelqu’un qui prépare une nouvelle machine : il prend le tas de linge sale et ensuite il va le trier en prenant soin de laver en premier les vêtements qu’il lui faut pour le lendemain, et il écartera les vêtements qui peuvent attendre la prochaine machine. C’est de la gestion de priorité. Tout comme Scrum. Je pousserai bien le vice jusqu’à expliquer qu’un Sprint de callibrage où l’on recherche une solution, un Sprint de release où l’on prépare une version, me font penser à un programme « Coton » et un programme « Blanc Programme Long »…

Enfin vient le temps du lavage, ce qui nous permet d’expliquer 2 notions : la non-modification d’un sprint et la durée fixée.

Tout d’abord il n’est pas possible d’arrêter un programme en cours de lavage pour y ajouter une chemise oubliée. Tant pis pour vous, elle sera lavée avec la prochaine machine. Même pire, je pense que si vous pouviez mettre en pause un programme, cela serait un risque pour l’ensemble du linge déjà en cours de lavage : risque de surcharge de la machine, risque que la chemise ne soit pas bien lavée finalement…
Durant un Sprint de Scrum il n’est pas possible de changer le contenu du Sprint. Vous devez laisser l’équipe terminer son travail. La gestion des patches et des bugs urgents doit être prévue en dehors du temps alloué à Scrum. Si votre activité de correction de bug représente 4 jours sur 10 en moyenne, alors votre équipe ne doit « faire du scrum » que sur une base de 6 jours, même si le sprint dure bien 10 jours.

La durée fixée en Scrum est aussi très importante car elle permet par observation de suivre l’activité de l’équipe et de créer des statistiques afin de pouvoir ensuite fonctionner de mieux en mieux.

Enfin je ne pousse pas plus loin la métaphore, pensez à Scrum lorsque vous lancerez votre prochain programme en « Coton délicat 40 degrés avec essorage »

3 réflexions sur « Scrum : une histoire de lave-linge »

  1. Cette métaphore je l’appliquerai plutôt au traitement des bugs (le vrai linge sale d’une équipe de dev).
    Pour la production nouvelle on pourrait aussi bien utiliser la liste de course avec un budget fixe, faut faire son choix et être capable de faire un vrai repas avec ce qu’on a acheté.
    Qu’en penses-tu ?

Les commentaires sont fermés.