Sprint 0, doit-on le mettre en place ?

Le Sprint 0 est devenu l’une des pratiques des plus discutées dans le Scrum : doit-on ou non vraiment faire un Sprint 0 en début de projet ? Est-ce que cette méthode est acceptable ? Je vous propose ma vision des choses.

Qu’est-ce que le Sprint 0 ?

Pour ceux qui ne connaissent pas cette pratique, certaines équipes commencent la mise en place d’un produit en initialisant ce fameux Sprint 0.

Le but étant de mettre en place des fondations techniques en début de projet (sur les aspects théoriques et techniques) afin de réaliser les futures premières user-stories sur un socle technique à peu prêt en place.

Elle est souvent l’équivalent en temps d’un sprint classique.

Cette méthode va par défaut aider les développeurs à estimer plus facilement les user-stories ; les développeurs n’auront plus la difficulté pour savoir où répartir la charge de mise en place du socle technique.

On a tendance à l’oublier mais si on doit mettre en place un framework ainsi que des serveurs pour faire une user-story, le point d’effort ne sera pas le même.

Par exemple, si j’ai 3 user-stories, sur quelle user-story je vais mettre la charge de ces serveurs et du framework ? Aucune idée…. Ah moins de déterminer un sens pour faire les user-stories ce qui va plutôt à l’encontre d’un scrum classique.

Des alternatives au Sprint 0 ?

Il existe de nombreuses alternatives possibles dont certaines que je vais vous citer ci-dessous.

Le spike

L’utilisation du spike pour les briques techniques est une alternative intéressante. C’est un type demande qui va définir un temps précis pour travailler sur un point difficile à quantifier (recherche, réflexion sur certains sujets…).

Le spike sera suivi de tâches techniques quantifiables qui par exemple permettront d’installer le socle technique : “mise en place du framework”, “installation base de données”…

Article : Qu’est-ce qu’un Spike dans un projet Scrum ?

Le spike architectural est d’ailleurs utilisé en Extreme Programming pour faire cette phase d’initialisation technique si besoin.

Workshop lors d’un framing

Lorsque vous effectuez un framing pour lancer un nouveau produit en partant de la vision de celui-ci, il est tout a fait possible de demander à l’équipe technique potentiellement dédiée au projet de faire différents workshop pour préparer le socle technique. Cela implique en revanche que la fin du framing ne finisse pas sur un go / no go.
Article : Comment lancer un framing de projet ?

Autres phase d’initialisation comme le DAD

Il existe également des concepts qui émergent depuis des années comme le Disciplined Agile Delivery (DAD) qui font office également de mise en place des fondations techniques et fonctionnelles d’un produit. Un prochain article parlera également de cette méthode.

Alors, faut-il faire un Sprint 0 ?

Les gens se rendent compte que cette phase d’initialisation est essentielle au lancement d’un projet mais que le “nom” n’est pas forcément le meilleur. Mais selon les contextes la phase d’initialisation n’est pas forcément la même et c’est souvent là que les débats semblent oublier que le contexte joue un rôle essentiel sur les réponses possibles.

Dans certains cas : oui

Si je fais une phase d’initialisation de projet mais que celle-ci doit arriver à valider ou non le projet avec un go / no go final, la partie technique ne sera lancée concrètement qu’en début de de développement. Oui dans certains contextes, les budgets ont une telle importance que le projet ne sera pas forcément validé si la masse potentielle de travail est bien au delà du budget qui devait être alloué.
En général, on a juste un tech lead dans cette phase afin d’avoir des coûts d’initialisation raisonnables ce qui ne permet pas de mettre le socle technique en place. Dans ce type de situation, le Sprint 0 est intéressant.
Maintenant qu’on le nomme comme cela où avec un autre terme n’est qu’un simple soucis de wording. On saura juste que la fin de cette phase n’apportera pas de valeur aux utilisateurs clés directement.

Dans certains cas : non

Si votre phase d’initialisation contient déjà une équipe de développement, proposez leur de mettre en place un socle technique directement pendant cette phase pendant que les métiers et les fonctionnels maturent la vision du produit.
Dans le cas où l’initialisation n’est qu’une phase de démarrage et qu’elle ne peut pas emmener sur un “no go”, autant profiter de cette période pour amener à maturation le socle technique.

Il ne faut pas trop initialiser

Attention, le socle technique ne doit contenir que l’obligatoire pour démarrer : serveur, framework back et/ou front, base de données, montée en compétence technique sur ces sujets si besoin… Les concepts d’internationalisation, les outils de recherches sont des réponses à certaines fonctionnalités et ne font pas parti du socle technique.
Dans un univers agile, on fait en sorte de ne développer des fonctionnalités (et mettre en place certains outils pour celles-ci) uniquement quand la demande arrive dans le sprint bakclog afin de :
  • s’assurer qu’on ne fera pas du travail en trop en cas de changement de scope
  • de ne pas alourdir inutilement le code de fonctionnalités non utilisées (lisibilité affectée) si le scope décidait de ne plus inclure les fonctionnalités associées aux blocs techniques ajoutés en amont.

On privilégiera d’ailleurs de faire du refactoring de code (exemple pour l’internationalisation) quand on prendra en charge une fonctionnalité impliquant une nouvelle technologie même si cela paraît curieux pour un certain nombre de développeurs.

Quel nom alternatif ?

Moi j’aime bien l’idée de ce “0” qui indique qu’on a pas commencé. Cependant mon avis importe peu et si vous désirez utiliser un autre nom car celui-ci vous perturbe, voici ceux qui existent :
  • initialisation
  • phase de setup
  • phase d’inception
  • framing (bien que cela est peut-être lié à une méthode)

Maintenant je pense que le wording n’est pas si important mais vous avez des termes alternatifs si besoin.

Et si l’équipe choisissait ?

Je pense honnêtement que ce soucis de wording est un faux problème. Le coach agile ou le Scrum Master sénior proposeront différentes techniques adaptées au contexte pour réaliser cette fameuse mise en place du socle technique.
L’équipe choisira la formule avec laquelle elle se sentira le plus à l’aise. On pourrait presque citer : “Les individus et leurs interactions plus que les processus et les outils” pour dire qu’on va privilégier l’avis des membres de l’équipe.
Dans des produits créés par plusieurs équipes Scrum avec LeSS, Safe, Nexus ou autres agilités à l’échelle, il faudra que la phase d’initialisation soit choisit par l’ensemble des équipes afin de partir sur les mêmes bases.

Conclusion

Proposez un ensemble de méthodes aux équipes adaptées au contexte dans lequel elles sont et laissez les choisir. Si une équipe veut faire un sprint 0, laissez la faire, si elle veut faire autre chose, pas de soucis.
Le plus important, c’est que l’équipe se sente à l’aise avec la méthode qu’elle décide d’appliquer (voire le wording à y mettre). Et si tout n’est pas parfait, elle profitera de la rétrospective pour chercher des axes d’amélioration.
Il n’y a pas de règle parfaite ou de processus à respecter à 100% ; chaque contexte est différent, les équipes utiliseront la méthode avec laquelle elles seront le plus à l’aise et qui est adaptée au contexte.

Laissez une réponse