Pourquoi ce sujet. Scrum finit souvent par désigner l'agilité tout entière. C'est un cadre parmi d'autres, avec des règles précises et une fonction : rendre le travail, les décisions et les retours visibles. Une équipe expérimentée peut ensuite choisir un pilotage plus direct par le flux.
Le cadre complet, avant d'en discuter quoi que ce soit.
Scrum tient en trois familles et une unité de temps. Les trois familles sont les artefacts, les rendez-vous et les rôles. L'unité de temps est le sprint, et elle contient tout le reste.
| Artefact | Ce que c'est | Qui le tient |
|---|---|---|
| Product backlog | la liste ordonnée de tout ce qui pourrait être fait | le PO |
| Sprint backlog | ce que l'équipe embarque pour ce sprint, et son objectif | les développeurs |
| Incrément | ce qui est terminé et utilisable à la fin du sprint | les développeurs |
La Definition of Done est attachée à l'incrément. C'est la liste des conditions qu'un travail doit remplir pour compter comme terminé. Tant qu'un élément ne la remplit pas, il retourne au backlog.
Le release plan circule souvent comme un quatrième artefact. Le Scrum Guide n'en contient que trois. Le plan de release vient de la pratique ; son usage est détaillé dans « Estimer n'est pas s'engager ».
| Rendez-vous | Quand | Ce qu'on y décide |
|---|---|---|
| Planification | au début du sprint | l'objectif, et ce qu'on embarque pour l'atteindre |
| Mêlée quotidienne | chaque jour, 15 min | ce qui bloque, et comment on s'organise aujourd'hui |
| Affinage | en continu | découper et préciser ce qui arrive plus tard |
| Revue | à la fin du sprint | ce qui est fait, et ce que ça change pour la suite |
| Rétrospective | après la revue | une amélioration de la façon de travailler |
La revue porte sur le produit. La rétrospective porte sur l'équipe. Confondre les deux est l'erreur la plus fréquente, et elle vide la rétrospective de son contenu.
| Rôle | Décide de | Ne décide pas de |
|---|---|---|
| Product Owner | l'ordre du backlog, ce qu'on ne fera pas | comment c'est construit |
| Scrum Master | rien du produit | ni le contenu, ni la technique |
| Développeurs | comment c'est construit, ce qui tient dans le sprint | l'ordre de priorité |
Le Scrum Master ne décide de rien et il n'encadre personne. Son travail est de faire tourner le cadre et de lever ce qui bloque l'équipe. La colonne du milieu est vide exprès, et c'est ce qui surprend le plus les dirigeants.
La boucle est fermée. Tout se répète à l'identique tous les 15 jours ou tous les mois. Cette régularité est le produit principal de Scrum.
Deux règles de Scrum existent parce que l'équipe débute.
Rien dans le développement logiciel ne réclame un cycle de 2 semaines. Le chiffre est arbitraire. Il a été choisi parce qu'il est assez court pour corriger vite, et assez long pour finir quelque chose.
Le sprint installe un rendez-vous fixe pour reposer la question « qu'est-ce qu'on fait maintenant ». Une équipe qui a pris l'habitude se pose la question en continu, et le rendez-vous devient bizarre.
« Scrum est le pédiluve de l'agilité. On y passe pour entrer, et on n'y reste pas. »
Le Scrum Guide a ajouté cette phrase à sa révision de 2020, dans la section Increment :
« an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. » The Scrum Guide, révision 2020
Livrer une fonctionnalité terminée le mardi est donc explicitement permis.
La deuxième règle qui a une date de péremption est le Scrum Master à plein temps.
Au début, il enseigne. Il rappelle les règles, il tient les rendez-vous, il empêche le retour aux anciennes habitudes. Ce travail se termine, parce qu'une équipe finit par connaître les règles.
Ensuite, il travaille sur ce qui bloque l'équipe depuis l'extérieur : les dépendances, les validations qui traînent, les arbitrages qui ne viennent pas. Ces obstacles-là ne disparaissent pas tout seuls.
Le rôle maigrit du côté de l'équipe et grossit du côté de l'entreprise. Un Scrum Master qui n'a plus rien à faire côté équipe a fait son travail.
L'étape où le sprint se dissout.
Le terme vient de Corey Ladas, dans Scrumban — Essays on Kanban Systems for Lean Software Development, publié en 2008. L'idée de départ était de faire passer une équipe Scrum vers un système de flux sans tout casser d'un coup.
| Ce qu'on garde | Ce qu'on ajoute | Ce qui tombe |
|---|---|---|
| les rôles, PO en tête | un tableau qui montre le flux | le sprint comme unité d'engagement |
| la rétrospective | une limite de travail en cours | la planification en bloc |
| le backlog ordonné | la mesure du délai de traversée | l'estimation systématique |
Le changement de fond est dans la troisième colonne, première ligne. En Scrum, l'équipe s'engage sur un lot pour la durée du sprint. En Scrumban, elle prend l'élément suivant quand une place se libère.
La planification cesse d'être un rendez-vous et devient une règle : quand il reste moins de 5 éléments prêts dans la file, on refait une passe d'affinage. C'est ce que Ladas appelle un déclenchement par seuil.
Le point d'arrivée. Peu de règles, toutes explicites.
La limite fait le travail. La colonne « en cours » est pleine à 3. La carte suivante attend. Pour la faire avancer, l'équipe doit terminer quelque chose, pas commencer quelque chose.
C'est la règle qui surprend le plus. Elle interdit de commencer du travail. Une équipe qui a 12 chantiers ouverts en même temps les finit tous en retard, parce que chacun attend les autres. En ramenant à 3, chaque élément traverse plus vite, et le délai devient prévisible.
David Anderson les formule ainsi, dans cet ordre :
| Pratique | Ce que ça donne concrètement |
|---|---|
| Visualize visualiser le travail, le flux et les risques | un tableau où chaque élément en cours est une carte visible de tous |
| Limit WIP limiter le travail en cours | un nombre écrit en tête de colonne, qu'on ne dépasse pas |
| Manage Flow gérer le flux | on mesure le temps de traversée, et on s'occupe de ce qui stagne |
| Make Policies Explicit expliciter les règles | ce qui autorise une carte à passer dans la colonne suivante est écrit |
| Implement Feedback Loops mettre en place des boucles de retour | des rendez-vous de revue à une cadence choisie, la rétrospective en fait partie |
| Improve Collaboratively améliorer ensemble, par l'expérimentation | on change une règle, on regarde l'effet sur le délai, on garde ou on annule |
Kanban ne supprime pas les règles. Il demande de les rendre explicites. Une équipe qui tient une rétrospective toutes les 3 semaines l'a décidé et l'a affiché.
Anderson ne présente pas Scrum comme une étape à dépasser. Sa méthode commence par « start with what you do now » : on part de l'organisation existante, quelle qu'elle soit, et on la fait évoluer.
La progression Scrum, Scrumban, Kanban est ma lecture à moi.
Le passage de l'un à l'autre change ce qu'on attend de vous.
| Scrum | Kanban | |
|---|---|---|
| Quand vous pouvez changer l'ordre | entre deux sprints | à tout moment, avant qu'une carte démarre |
| Ce que vous voyez | un incrément à la revue | l'état du flux en permanence |
| La question que vous posez | qu'est-ce qui est fait ce sprint ? | combien de temps met une demande à traverser ? |
| Ce qu'on vous demande | de tenir le sprint sans y injecter d'urgences | d'accepter qu'on refuse de commencer |
La dernière ligne est la plus difficile. En Kanban, la réponse à une demande urgente peut être « on la prend, et on arrête autre chose ». Le choix remonte, et il devient visible.
D'où il vient : de l'idée qu'une échéance rapprochée fait avancer le travail. Le sprint donne une échéance toutes les 2 semaines, et ça se voit.
Ce que Kanban en fait : il remplace l'échéance par une mesure. On sait qu'une demande met en moyenne 9 jours à traverser, et on répond avec ce chiffre. La prévision vient de l'historique.
D'où il vient : d'une mesure de la productivité par le nombre de chantiers ouverts. Une équipe qui a beaucoup de choses en cours a l'air occupée.
Ce que Kanban en fait : il mesure ce qui sort, pas ce qui est commencé. Baisser la limite augmente le débit, parce que les allers-retours entre tâches disparaissent.