Sprint zéro : Est-ce agile ? Est-ce utile ?

Le sprint zéro en agilité, c'est un sujet qui divise.

Pour certains, c'est une notion anti-agile et pas vraiment utile, voire même "un peu une connerie" (Jean-Pierre Lambert, Scrum Life). Pour d'autres, c'est un passage obligé pour initier le projet et fixer les règles de travail de l'équipe. Et oui, il faut bien préparer les choses avant le premier sprint.

Alors qui a tort ? Qui a raison ?

Voyons ensemble dans l'article si le sprint zéro est vraiment anti-agile, ou si il a au contraire une certaine utilité.

Qu'est-ce que le sprint zéro ?

Le sprint 0 est un sprint "spécial" de cadrage sans durée définie et sans obligation de livrer à la fin du sprint, permettant de construire les bonnes bases d'un projet agile et de former l'équipe Scrum.

Cette notion est controversée et n'existe pas officiellement dans le guide Scrum.

Certaines équipes Scrum commencent en effet le développement d'un produit en faisant ce fameux Sprint 0 (appelé aussi Planning sprint ou Design sprint). En fonction des équipes, ce sprint peut durer de quelques jours (2 à 3 jours)  jusqu'à une durée de sprint classique.

Ils utilisent ce sprint zéro afin de discuter des aspects suivants :

• Architecture et design du produit
• Vision produit et création du product backlog
  
• Durée des sprints
  
• Détermination de la definition of done
  
• Établissement des règles de fonctionnement de l'équipe Scrum
  
• Mise en place du socle technique de base : serveurs, bases de données, pipeline CI/CD, éléments de sécurité, etc...
  

Que dit le guide Scrum sur le sprint zéro ?

Le guide Scrum ne fait aucune mention du sprint zéro. D'ailleurs, le guide nous dit très clairement que "le premier sprint n'est pas différent des autres".

Le premier a donc une durée similaire aux autres sprints, et se déroulent de la même manière, à savoir : un sprint planning, des daily scrum quotidiens de 15 minutes, une sprint review en fin de sprint ainsi qu'une rétrospective pour analyser le déroulement du sprint.

L'équipe Scrum doit donc pouvoir dès le jour 1 délivrer de la valeur business à son client et aux parties prenantes du projet.

Et là ça me pose souci, car j'ai l'impression que ce sprint zéro rentre en conflit avec ce qui est écrit dans le guide Scrum. Mais est-ce vraiment le cas ?

Pourquoi le sprint zéro a été créé ?

Le sprint zéro a été introduit afin de répondre à un besoin de cadrage dans les projets agiles.

Il permet ainsi :

• D'étoffer le product backlog, et d'amener le product owner et l'équipe de développement a travailler ensemble sur le sujet.
• D'apprendre à l'équipe à travailler ensemble.
• De définir les rôles et responsabilités de chacun.
• De former l'équipe au cadre de travail Scrum.
  
• De renforcer les pratiques agiles.
  
• De prévoir le budget de l'équipe.
  
• De travailler sur la roadmap produit.
• De réfléchir à l'architecture produit à mettre en œuvre.
• De produire des maquettes de design.
• D'installer tout le socle technique pour assurer le bon développement du produit.

Les défenseurs du sprint zéro affirment d'ailleurs que ce cadrage agile leur permet ensuite de livrer plus vite le produit au client.

On ne va pas se mentir, ça permet également de rassurer le management qui n'a pas la même sensibilité à l'agilité. ça permet de rester en terrain connu.

Mais dites, ça ne vous rappelle rien ? On dirait foutrement du waterfall déguisé. ça ressemble à s'y méprendre à une phase de cadrage classique avec les méthodologies de gestion de projet traditionnelles : Ne rien oublier et tout prévoir dès le début du projet.

Le sprint 0 est-il vraiment agile ?

Le sprint zéro n'existe pas et est anti-agile. Le guide Scrum n'en fait aucune mention, et ce sprint spécial de cadrage rentre directement en conflit avec les valeurs de Scrum.

Je m'explique.

1 ) Le sprint zéro est opposé à l'empirisme

Si on doit résumer Scrum en une phrase, ce serait : Délivrer de la valeur au client le plus vite possible.

Pour que ce soit possible, cela implique de se reposer sur l'empirisme, à savoir agir sur la base de faits et d'hypothèses vérifiés. Le produit émerge donc au fur et à mesure des sprints, en fonction de l'apprentissage de l'équipe Scrum et des retours utilisateurs collectés.

Sauf que le sprint zéro agit comme un sprint de cadrage, où l'on met un certain nombre de choses en place, où l'on prend des décisions au moment où on a le moins de connaissances.

Le sprint zéro va donc à l'encontre de l'empirisme.

2 ) Le sprint zéro ne respecte pas le guide Scrum

De plus, le guide Scrum précise spécifiquement que le premier sprint n'est pas différent des autres : il a la même durée.

Un sprint zéro de quelques jours ou de plusieurs semaines alors que les sprints classiques se déroulent en 1 semaine, ce n'est pas possible, car la durée de ce sprint spécial n'est pas en relation avec celle des itérations futures.

Pour rappel, les sprints doivent avoir une durée fixe, afin de créer un rythme de travail constant et durable.

3 ) Il n'est pas nécessaire de livrer quelque chose au sprint zéro

Autre justification qui m'irrite au plus haut point, le sprint zéro est un sprint spécial qui serait exempt de livraison aux parties prenantes. Étant donné qu'il s'agit d'un sprint de cadrage, l'équipe travaille sur les briques techniques et technologiques qui accueilleront par la suite le produit.

Oui mais voilà, là encore ça rentre en contradiction avec le guide Scrum.

En effet, chaque sprint doit donner lieu à un incrément de sprint, utilisable en l'état.

Or, ça n'a pas l'air d'être le cas ici avec le sprint zéro.

4 ) Le sprint zéro pose des briques difficilement modulables

Tout le principe de Scrum et de l'agilité est de pouvoir être flexible et s'adapter constamment. On va donc chercher à développer une architecture modulaire et évolutive pour le produit.

Et pour cela, pas le choix : ça doit se faire au fur et à mesure des itérations et des feedbacks. On parle alors d'une architecture émergente.

Le problème avec le sprint zéro, c'est qu'on pose des fondations que l'on va difficilement remettre en cause par la suite, sinon cela voudrait dire "qu'on a fait tout ça pour rien" ou "qu'il faut tout refaire".

Le danger de poser à l'avance tout le socle technique, c'est d'influencer ou de contraindre les choix futurs. On a ainsi tendance à rester sur ce qui a été prévu, même si ce n'est pas optimum.

Le sprint zéro devient ainsi une décision définitive, un engagement sur lequel on ne peut plus revenir par la suite. Je ne sais pas vous, mais moi ça me rappelle toujours autant la méthode Waterfall.

5 ) Le sprint zéro permet de livrer plus vite

Scrum est exigeant sur ce point : l'équipe doit être en capacité dès le jour 1 de créer de la valeur. A la fin du premier sprint, elle doit proposer un incrément fonctionnel et utilisable par les parties prenantes.

Imaginons que la durée des sprints classiques soit de 2 semaines. SI je n'utilise pas de sprint zéro, au bout de 15 jours je suis en mesure, à la fin du premier sprint, de présenter un incrément aux parties prenantes et d'apporter de la valeur business.

Si j'utilise un sprint zéro, je livrerais forcément la même chose, mais au bout de plus de temps, vu qu'il faudra rajouter au délai de livraison la durée du sprint 0.

Donc non, le sprint zéro ne permet pas de livrer plus vite.

En plus de ça, le risque de trop définir le socle technique à l'avance est de faire des choses pour rien, ou de devoir les refaire ou les réadapter par la suite.

6 ) Le sprint zéro crée de la cohésion d'équipe

Le sprint zéro servirait également à faire du teambuilding, à former l'équipe voire encore à souder l'équipe ensemble.

Le problème, c'est que ça marche en théorie, pas en pratique.

Il n'y a qu'à voir les séminaires de teambuilding organisés par les entreprises pour renforcer les liens et souder les équipes entre elles. Le lendemain, tout le monde se tire dans les pattes à nouveau.

ça ne marche tout simplement pas.

La cohésion de l'équipe ne se décrète pas, c'est quelque chose qui se crée et s'entretient au continu. C'est en faisant, en réalisant quelque chose et en se confrontant à des difficultés que l'on devient une équipe solide et soudée.

Un produit émerge au fil des itérations

C'est l'un des principes fondamental de Scrum. Le produit émerge au fur et à mesure des itérations grâce à l'empirisme.

L'équipe apprend tout au long du cycle de vie du projet, elle recueille du feedback, découvre les éléments à prioriser pour maximiser la valeur business apportée.

Le planning, la vision produit, l'architecture, le design, la sécurité, le CI/CD, l'installation de serveurs... Tout ça devrait émerger en fonction des besoins. Ces discussions ne sont pas limitées au sprint zéro, bien au contraire ! Elles doivent avoir lieu à tous les sprints.

D'ailleurs, je reviens sur cette notion de pipeline CI/CD, soit Continuous Integration / Continuous Delivery. C'est marrant, il y a le mot "continu" dedans. Alors pourquoi vouloir monter tout cela d'un seul coup lors du sprint zéro ?

Faire sans sprint 0, c'est possible ?

Gérer un projet agile sans sprint zéro, c'est tout à fait possible. 

Vous devriez d'ailleurs oublier cette notion, qui inculque de mauvaises valeurs à l'équipe, à savoir qu'il existe des sprints spéciaux (c'est faux) et que c'est ok de ne pas livrer quelque chose aux parties prenantes de temps en temps (faux également).

Mais alors comment faire dans ce cas si on ne cadre pas en amont le projet agile ?

• Construction du backlog.
  L'objectif de produit est défini en amont, sinon il n'y aurait pas d'équipe. Le product owner peut travailler sur une première version brute, mais il s'agit avant tout d'un travail d'équipe. Utilisez le premier sprint planning du sprint 1 pour faire émerger les éléments prioritaires du backlog.
  
• Définition des user stories.
  Elles n'ont pas à être parfaite de suite, il ne s'agit pas de spécifications détaillées. Elles doivent rester le plus simple possible. Considérez ces premières user stories comme des invitations à la discussion.
  
  En 1h de story mapping, un début de backlog peut se créer pour les 3-4 premières itérations.
  
• Installation des serveurs et bases de données.
  Installez le socle technique lorsque vous en avez réellement besoin, pas avant. Ces éléments doivent être pris en compte dans l'estimation des points d'efforts des user stories.
  
• Construction du pipeline CI/CD.
  Bâtissez quelque chose de minimaliste, un MVP. Vous le ferez ensuite évoluer au fur et à mesure des besoins.
  
• Architecture et design.
  Faites des hypothèses, et livrez le résultat aux parties prenantes lors de la sprint review. Le feedback que vous aurez vous permettra de valider ou non votre hypothèse et de prendre la bonne direction sur le produit.
  
• Definition of done.
  Encore une fois, elle doit être minimaliste. La définition de fini doit évoluer à chaque fin de sprint via la rétrospective.
  
• Organisation de l'équipe.
  Tout comme le reste, l'organisation de l'équipe doit émerger naturellement et de manière itérative, en fonction des besoins. Rien ne vous empêche lors du sprint 1 d'aller plus loin que la DoD que vous avez décidé.
  

Le sprint 1 doit-il être orienté 100% produit ?

Tout comme les autres sprints, le sprint 1 est orienté produit. L'équipe devra fournir au minimum un incrément de qualité en fin de sprint. Mais ça ne veut pas dire que le sprint 1 est orienté à 100% produit.

Une partie de ce qui est d'habitude réalisé sur le sprint zéro peut-être fait sur le sprint 1, tout en laissant suffisamment de place pour développer un premier incrément, aussi modeste soit-il.

Ayez bien conscience que le sprint 1 a toujours un objectif de sprint moins ambitieux que les sprints suivants.

Voici l'organisation que propose Constantin Guay, de la chaîne Youtube Scrum Life, pour découper votre premier sprint.

L'initialisation d'un certain nombre de points, comme on le ferait en sprint 0, demande trois jours de travail. Même si votre sprint dure 1 semaine, c'est suffisant pour livrer un incrément fonctionnel et utilisable aux parties prenantes du projet.

Faut-il oublier le sprint zéro ?

Alors au final, faut-il vraiment oublier le sprint zéro ? Oui, clairement, sans hésitation. Le sprint zéro n'est selon moi pas agile. Ce n'est pas non plus du Scrum. C'est du Waterfall déguisé. Et ça n'a pas sa place dans le monde de l'agilité.

Je comprends, c'est rassurant, on reste dans une zone de confort, c'est tentant. Mais en agissant ainsi, on n'aide pas l'entreprise à passer en mode agile, et on enseigne de mauvaises pratiques à l'équipe Scrum.

Mais on l'a vu, il y a d'autres manières de faire, il existe des alternatives, bien plus agiles et bien plus adaptées au développement d'un produit.

D'ailleurs, je ne suis pas le seul à penser ça.

• Alistair Cockburn, auteur du livre Agile Software Development, dit : "J'ai la vague impression que quelqu'un était pressé d'utiliser Scrum et qu'il a fait quelque chose qui n'avait pas de valeur métier manifeste au démarrage, et il a ensuite déclaré "Oh, c'était le Sprint Zéro !" pour éloigner les médisants."
  
• Ken Schawber, co-créateur de Scrum est d'accord avec lui : "Le Sprint 0 est devenu une expression utilisée à tort pour décrire la planification qui a lieu avant le premier sprint".
  
• Constantin Guay et Jean-Pierre Lambert, de la chaîne Youtube Scrum Life, vont également dans ce sens sur leurs blogs respectifs. (source1) (source2)
  

Je conclus cet article avec une citation que j'apprécie beaucoup et qui résume très bien la situation du sprint zéro.