Bye Bye Scrum

J’arrête Scrum.

Ce n'est pas un billet de premier avril qui aurait un peu de retard : j'arrête volontairement et définitivement l'utilisation de Scrum.

Il y a 4 ans, j’annonçais que, après quelques années de bricolages méthodologiques agiles, j’avais pris une approche relativement formelle pour passer à Scrum. Compte-tenu de mon contexte d’alors, je pense que c’était la bonne chose à faire.

Au fil du temps, l’équipe a gagné en compétence sur les pratiques agiles. De début 2007 à mi 2010, cinq releases de notre principal produit se sont succédées et, dans les derniers temps, les sprints se suivaient sans le moindre souci à gérer. En juin 2010, nous avons démarré une nouvelle ligne de produit avec un changement technologique assez conséquent.
D'un point de vue gestion de projet, le premier impact visible (et attendu) fut le changement de vélocité. Sur le produit précédent, le graphe de vélocité ressemblait à une mer d'huile. Sur les premiers mois du nouveau produit, il donnait plutôt dans la coupe d'une étape pyrénéenne du tour de France. Cela n'avait rien d'affolant : le contexte avait changé et il fallait quelques mois pour stabiliser la pertinence des estimations.
Ce n’est devenu plus problématique qu’en novembre lors de l’approche de la première release. La dernière itération avant la date butoir fut vécue comme une sorte de fin de projet où il fallait absolument livrer toutes les fonctionnalités prévues.

Je ne sais si j’ai été influencé par mes lectures d’alors^[1] ou par quelques présentations intéressantes sur Kanban lors de l’agile tour mais j’ai pris -sans en parler à quiconque- une décision.
Puisque les fins d’itérations sont si mal vécues, c’est qu’elles n’ont pas que du bon. J’allais donc désormais m’abstenir d’envoyer des invitations pour la moindre réunion relative à une itération. Si un backlog ou une revue de sprint venait à manquer à quelqu’un, il ou elle le ferait probablement savoir…

Depuis quatre mois, nous n’avons plus formalisé la moindre itération.

A-t-on des problèmes pour définir le travail à réaliser ? Non. Il y a en permanence 2 ou 3 éléments du backlog de produit qui sont en cours de réalisation. Dès qu'un est terminé, celui qui suit par ordre de priorité prend sa place et est immédiatement découpé en taches.
A-t-on des problèmes pour rendre visible l'avancement du travail ? Non. Dès qu'un élément du backlog est terminé, il est présent dans le build du produit, lequel est immédiatement disponible pour qui voudrait l'essayer.

Progressivement, notre mode de fonctionnement passe d’un cadencement par les itérations à un flux qui s’écoule de manière plus régulière. La métaphore du “sprint” était en fait très bien choisie. On avait juste oublié qu’il est plus facile de gérer son effort dans une course de fond que dans une succession de sprints.

Bien sûr, tout cela n’est pas aussi simple. La disparition des itérations entraine des contraintes plus importantes sur certains aspects du processus.
L'intégration continue est un de ces aspects : la nécessité d'un build à jour et en état livrable est quasi-permanente. Heureusement, les efforts consentis sur la mise en oeuvre sans concession d'un développement piloté par les tests commencent à porter leurs fruits.
La planification des estimations doit, elle aussi, s’adapter au flux. Il n’y a plus de “début de sprint” où on peut estimer tout ce qui aurait pu entrer dans le backlog de produit pendant le déroulement du sprint précédent.

La définition de la vélocité et, plus généralement, du plan de release est probablement le changement le plus significatif.
Pour la vélocité, on a pour l'instant fait très simple. Quand on a des itérations de 4 semaines, la vélocité, mesurée en fin d'itération, c'est la somme des points des éléments du backlog terminés au cours des 4 dernières semaines. Et quand on n'a plus d'itérations ? Et bien, rien ne nous empêche de continuer à prendre la même mesure !!! On a une vélocité calculée sur une fenêtre glissante qui change chaque jour. Si le flux des éléments de backlog s'écoule régulièrement à travers l'équipe de développement, cela ne change rien par rapport à une mesure de vélocité par itérations.
D'ailleurs, il faut bien comprendre que la vélocité ne sert, au final, qu'à une seule chose : proposer une date de release la plus réaliste possible. Quand on a des itérations, la taille du backlog de release divisée par la vélocité nous donne le nombre d'itérations restant à effectuer pour terminer la release. Quand on n'a plus d'itérations, on divise toujours la taille du backlog de release par la vélocité, puis on multiplie par la taille, en jours, de la fenêtre de calcul de la vélocité et on obtient une approximation guère moins exacte du nombre de jours restant avant la release…

Finalement, la suppression des itérations et le passage à un processus de flux n’a rien de bien compliqué. Le point à surveiller le plus crucial est le maintien du flux. On doit en permanence garder à l’esprit qu’il vaut toujours mieux achever ce qui est déjà commencé que de commencer autre chose. Concrètement, cela veut dire que si un développeur termine quelque chose, il devrait, avant de prendre une nouvelle tache, toujours se demander s’il ne peut pas aider un collègue à terminer une tache en cours.
Ce n’est pas grand chose mais je crois que c’est une notion fondamentale. Quand on fonctionne par sprints, on a tendance à remplir un backlog de sprint avec des taches et à ne plus trop se préoccuper de la valeur de chacune de ces taches. Pourtant, à un instant donné, une tache qui permet de terminer la réalisation d’une histoire utilisateur a énormément plus de valeur qu’une autre tache qui ne fait que démarrer la réalisation d’une autre histoire.
Le but d'une méthode agile n'est-il pas de fournir, dans un délai le plus court possible, de la valeur pour les utilisateurs tout en conservant un rythme viable sur une longue durée ?

Il y a là, je pense, matière à réflexion pour toute équipe pratiquant le développement itératif.
En ce qui me concerne, le pas est franchi. Scrum, c’est fini. Désormais, tout se passera dans le flux.