12 façons originales de foirer vos sprints

Je ne les aime pas particulièrement, mais il semble que les sprints aient le pouvoir de rassurer les gens. C'est vrai que c'est concret, les sprints.

Quand une équipe souhaite travailler ainsi, je ne l'en décourage pas et l'aide au contraire à en tirer le meilleur parti, même si ce n'est pas ce que je ferais, moi. Comme toujours, mieux vaut que l'équipe tire ses propres conclusions, et, qui sait, on n'est pas à l'abri que ça marche.

Donc si vous voulez vraiment faire des sprints, faites-les bien. Et pour ce faire, le mieux est encore de s'instruire des erreurs des autres. Voici donc un joli florilège d'erreurs en matière de sprints, autrement dit les mille et une façons de vous planter en faisant des sprints. Inutile de préciser que tout cela est du vécu, sinon ça ne serait pas drôle.

Ah là là… mais pourquoi les avoir nommés ainsi ? Quand Usain Bolt a signé le record du monde du 100m en 9.58 secondes, le 16 août 2009 lors des Championnats du monde d'athlétisme à Berlin, guess what? Il n'a pas enchaîné sur un deuxième 100m, ni un troisième, ni un quatrième. À partir de là, vous avouerez qu'on pouvait trouver un meilleur nom pour désigner l'effort à fournir durant un sprint agile. On n'est même pas sur un marathon, parce qu'un marathon a une fin, alors qu'un produit n'en a pas (du moins pas a priori). Le bon effort pour un sprint est donc l'effort le plus élevé qui reste soutenable sans perspective de fin. On est plus sur de la marche rapide… de la marche tout court, en fait.

En revanche, le terme a du sens si l'on considère qu'un sprint sert à focaliser les efforts sur un sujet métier durant un temps donné.

Avoir plusieurs objectifs de sprint ou, pire, un par développeur, c'est comme n'en avoir aucun. On reprend : l'objectif de sprint constitue le focus principal de l'équipe. Il permet de fédérer les efforts, évitant que les sujets s'étalent sur plusieurs sprints et ne débouclent jamais. Un objectif clair permet donc de livrer de la valeur plus rapidement. Cet objectif est le plus souvent de nature fonctionnelle, mais l'équipe peut juger nécessaire de consacrer un sprint à du refactoring, pour apurer la dette technique.

L'objectif est donc la raison d'être des sprints. En avoir plusieurs, c'est prendre le risque que les objectifs se confondent avec le Sprint Backlog. Or ce sont 2 choses totalement différentes : l'objectif est une direction, tandis que le Sprint Backlog est ce que l'équipe estime être en mesure de produire dans cette direction le temps d'un sprint.

Et pour finir d'enfoncer le clou : on ne déroge pas à l'objectif, sauf cas de force majeure (certains bugs ou bien un revirement brutal de priorité, mais franchement, si vous ne pouvez pas attendre quelques jours…)

Un bug survient. On le corrige, ça prend du temps et l'objectif du sprint vole en éclats. Classique. Alors on reprend à zéro.

Les bugs ont le bon goût d'être imprévisibles : on ne sait pas quand ils vont arriver, ni la charge de travail que va occasionner leur résolution. Pour cela, il faut mener une investigation technique et parfois fonctionnelle (de nombreux bugs révèlent des défauts de conception). Comment les prendre en compte au moment de planifier un sprint ? Il n'y a pas vraiment le choix, vous devez allouer de la bande passante à leur investigation, j'entends par là une enveloppe de temps fixe. Ensuite, plusieurs cas de figure peuvent se présenter :

Les sprints permettent 3 choses :

Vous comprenez donc aisément que des sprints longs annulent leurs propres bienfaits. Alors "long", c'est quoi ? À mon sens, 3 semaines, c'est déjà trop, mais 1 semaine, c'est compliqué aussi parce que vous passez plus de temps en réunion qu'à développer. Je vous laisse deviner ce qui me paraît être la bonne durée 😉

Au final, un sprint, c'est comme un teckel : tout se passe au début et à la fin, entre les 2, ça sert à rien…

Là, on tient un concept. Un sprint, c'est une unité de temps, typiquement 2 semaines, et un engagement de moyens : si, à la fin, vous n'avez pas atteint l'objectif, cherchez à comprendre pourquoi et tirez-en les conséquences pour les prochains sprints. Mais si vous rallongez le sprint pour atteindre l'objectif, c'est que vous êtes tenus à un engagement de résultat, autrement dit que le sprint est défini par un périmètre fonctionnel. Ce n'est donc pas un sprint, c'est un lot. Et n'essayez pas de m'avoir avec l'inter-sprint : déclarer le sprint comme terminé et attendre un peu avant d'en commencer un nouveau, c'est pas très très joli.

Les petits malins auront trouvé la parade : repousser simplement le reste-à-faire de sprint en sprint and let's call this a day! Et tant qu'à faire, institutionnaliser la chose en programmant d'étaler la fonctionnalité sur plusieurs sprints, avec mise en production à l'échéance. Oui, sauf qu'encore une fois ça ne sert à rien, vu que le principe est d'aller en production à chaque sprint pour pallier l'effet tunnel et la loi de Parkinson. À ce rythme-là, ne faites pas de sprints et assumez de faire des lots ! Une seule chose à retenir : si vous voulez faire des sprints, vous devez découper votre travail très finement, en User Stories  (la clé : une User Story doit apporter de la valeur à l'utilisateur, donc pouvoir être mise en production).

Là encore, un grand classique. Effectivement, valider un travail prend du temps, qu'il s'agisse de validation fonctionnelle (recette) ou technique (revue de code). Décaler cette validation au prochain sprint va à l'encontre de l'objectif du sprint courant, puisque vous ne pourrez pas considérer votre travail comme terminé (cf. Definition of Done). Et d'autre part, cela vous met dans la 💩 au sprint N+1, puisque tout le temps consacré à la validation du sprint N ne sera pas consacré à l'objectif du sprint N+1. Vous n'avez d'autre choix que d'anticiper, c'est-à-dire développer un peu moins pour avoir le temps de valider, mais aussi découper plus finement votre travail afin d'étaler cette validation tout le long du sprint et éviter la bousculade de fin de sprint.

J'avoue : ce point est feinteux. Le Scrum Guide évoque succinctement le "refinement" sans vraiment lui donner de place. Tout au plus est-il suggéré d'y procéder lors du Sprint Planning. Sauf que si vous attendez le lundi matin du début de sprint pour travailler fonctionnellement et techniquement sur vos User Stories, vous pouvez faire une croix sur votre soirée à l'opéra. Ainsi, la conception est le trou dans la raquette, le grand oublié, l'impensé de Scrum. Pourtant, elle représente une charge de travail significative et nécessite souvent des allers-retours avec les parties prenantes (utilisateurs, experts du domaine etc.), voire de réaliser un spike/POC. Si vous ne l'anticipez pas, plusieurs sprints à l'avance, vous êtes dans les choux au 1er jour du sprint.

Oui, mais comment dire : non. Je vois couramment des équipes faire des sprints et ajouter des "tickets" au Sprint Backlog au petit bonheur la chance, j'entends par là sans heuristique leur permettant de savoir si la charge de travail est réaliste ou non. Si vous faites des sprints, vous devez estimer vos User Stories et mesurer la vélocité sprint après sprint…

À moins que vous soyez dans une approche No Estimate, mais on ne fait pas du No Estimate en claquant des doigts. Le prérequis, incontournable  et ardu, est que vos User Stories soient fines comme du carpaccio, donc à peu près toutes équivalentes en termes de complexité. Ainsi, la vélocité ne s'exprime plus en story points mais en nombre de User Stories (oui, vous avez bien lu). Un nombre relativement grand, afin que les erreurs se compensent.

On le sait, l'erreur d'estimation augmente avec la valeur de l'estimation, parce que notre cerveau appréhende les nombres de manière logarithmique. Ainsi, si vous utilisez la suite de Fibonacci (1, 1, 2, 3, 5, 8, 13, 21…), un poids de 21 dans votre esprit n'est pas 7 fois plus grand qu'un poids de 3, mais peut-être seulement 3 ou 4 fois plus grand. Par conséquent, mettre dans votre Sprint Backlog des User Stories de poids 1 et d'autres de poids 21 n'a que peu de sens. Pensez-donc : l'erreur d'estimation sur 21 est peut-être de 5, 8 ou même 13 ! Si possible, découpez la User Story en utilisant les 2 termes inférieurs de la suite (21 = 13 + 8).

Cela peut sembler paradoxal, mais les estimations servent à se passer d'estimations. Votre objectif, sprint après sprint, doit être de découper votre travail en User Stories toujours plus fines. Au début, vous utiliserez une amplitude de 1 à 21. Soit, mais ne vous en contentez pas. Essayer de passer à une amplitude de 1 à 13 puis, quand cela sera bien stabilisé, à une amplitude de 1 à 8, et ainsi de suite. Quand les poids relatifs de vos User Stories se situeront tous entre 1 et 3, vous pourrez abandonner les estimations, parce que vous serez de fait dans une approche No Estimate.

Celle-ci est pour votre manager (😘) et sera l'occasion de rappeler, une fois de plus, que les mots ont leur importance :

Les estimations sont donc sans unité : on n'estime pas en jours, cela n'a physiquement pas de sens. Et si vraiment vous insistez, je vous pose la question : qu'est-ce qu'un jour ? 7 ou 8 heures de travail ? Avec ou sans réunions ?

En voilà une idée qu'elle est bonne ! Nous l'avons vu, la vélocité est la somme des poids relatifs des User Stories, elle aussi est donc sans unité. La vélocité est nécessaire pour construire le Sprint Backlog, mais on peut également interpréter sa variation dans le temps :

Si la tendance est interprétable, la valeur, en revanche, ne l'est pas en tant que telle. Comparer la vélocité de 2 équipes n'a aucun sens : 40 n'est pas mieux que 30. Quand une telle comparaison s'instaure dans une organisation, c'est soit le signe d'un management toxique ☠️, soit l'illustration de la loi de Goodhart ("lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure").

Quoi qu'il en soit, gardez toujours à l'esprit que la vélocité mesure seulement un output, sans rien dire de l'outcome.

Au final, il y a tellement de façons de foirer un sprint qu'on est en droit de se demander s'ils sont bien utiles et nécessaires. Personnellement, je les trouve artificiels, en ce sens qu'ils introduisent une temporalité qui n'a pas de sens pour le métier, et je m'en passe très bien.

Mais évitons le trop d'absolu : je serais réellement heureux qu'une équipe me dise qu'elle fait des sprints et que ça l'aide. Comme dirait notre ami Woody Allen, "Whatever Works!"

Et si vous avez envie d'aller plus loin dans la compréhension de ces sujets, ma formation L'agilité au marteau  pourrait vous intéresser 😊