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 de sprint 0 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 ; cela dans le but 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 au sprint 0 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 ; par exemple, l’installation du socle technique :
Le spike architectural est d’ailleurs utilisé en Extreme Programming pour faire cette phase d’initialisation technique si besoin.
Workshop lors d’un framing agile
Lorsque vous effectuez un framing agile 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 agile ne finisse pas sur un go / no go.
C’est la méthode d’initialisation que je préfère au niveau des projets car elle apporte un cadre sécurisé que les autres méthodes n’apportent pas.
Autres phase d’initialisation comme le DAD que le sprint 0
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 ; une alternative intéressante au sprint 0. 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 « sprint 0 » 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 au sprint 0 ?
Moi j’aime bien l’idée de ce « 0 » qui indique qu’on a pas commencé ; cependant mon avis importe peu. 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 agile (bien que cela est peut-être lié à un framework complet)
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 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 sprint 0
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 que ce sprint 0, 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 ; même chose pour le wording à y mettre (sprint 0, inception…). 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.
Paquet Judicaël (expert en transformation et AI)
Mes activités en France et en Suisse :
- ingénieur prompt
- coach AI
- architecte de transformation agile
- formations agiles personnalisées
- sensibilisations et coaching de manager
- audits de maturité agile et de situations
- coaching agile (équipes, orga, product owner, scrum master, coach agile)
Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle.
[Me contacter]
Pas facile de garder un management visuel totalement à jour surtout dans les équipes où celui-ci prend plusieurs murs. Et si vous mettiez un Scrum Sherif pour combler les trous ? Comment cette pratique fonctionne […]
Le LeSS Huge est un framework d’agilité à l’échelle combinant plusieurs LeSS ensemble afin de répondre à des projets de plus grande envergure. Je n’ai pas eu la change de pouvoir le mettre en place […]
Le Chaos Kong est une des pratiques appliquée dans l’approche du Chaos engineering. Cette pratique extrême du devops permet de s’imposer d’avoir des offres de qualité. Le Chaos Kong Le chaos kong est très proche […]
2 Commentaires
Bonjour,
Je suis un prof au fac, j’enseigne et j’encadre des étudiants en master génie logiciel. intéressé par vos articles dans la thématique scrum (méthode agiles en g&néral) , j’ai un soucis au niveau de la structure des rapports des master que j’encadre: comment présenter une structure d’un rapport en respectant scrum. en fait dans tout rapport de pfe on a besoin d’un chapitre 1 dans lequel on spécifie le projet à réaliser en présentant ses objectifs , les spécifications fonctionnelles , non fonctionneles , le backlog du produit, le planning des sprints , le diagramme de cas d’utilisation global …,
ce chapitre 1 peut on l’appeler Initialisation , Sprint0 ?? les chapitres suivants sont généralement des releases 1 , 2 , ..
chaque release comportera un backlog des sprint, la conception et la réalisation
merci de m’accepter un memebre dans votre équipe pour échanger des idées
bien cordialement
chiheb Professeur univ à l’ISET de Sousse , Tunisie
Je ne suis pas sûr d’avoir 100% compris ta demande. Mais je vais tenter d’y répondre ; mais si ça répond pas vraiment, n’hésite pas à répondre à mon commentaire.
Pour lancer un projet de façon agile, je recommande de partir sur un framework de lancement agile : le framing agile (https://www.agile-framing.com/). Il permet de créer une vision du produit mais d’avancer de façon agile, lean et UX. Moi je le recommande plus qu’un sprint 0 qui est souvent mal compris et qui implique souvent d’avoir déjà des bases (sur les gros projets). Le framing agile étant souvent plus adapté.
Tu peux me donner ton whatzap si tu désires creuser le sujet.
Bonjour,
Je suis un prof au fac, j’enseigne et j’encadre des étudiants en master génie logiciel. intéressé par vos articles dans la thématique scrum (méthode agiles en g&néral) , j’ai un soucis au niveau de la structure des rapports des master que j’encadre: comment présenter une structure d’un rapport en respectant scrum. en fait dans tout rapport de pfe on a besoin d’un chapitre 1 dans lequel on spécifie le projet à réaliser en présentant ses objectifs , les spécifications fonctionnelles , non fonctionneles , le backlog du produit, le planning des sprints , le diagramme de cas d’utilisation global …,
ce chapitre 1 peut on l’appeler Initialisation , Sprint0 ?? les chapitres suivants sont généralement des releases 1 , 2 , ..
chaque release comportera un backlog des sprint, la conception et la réalisation
merci de m’accepter un memebre dans votre équipe pour échanger des idées
bien cordialement
chiheb Professeur univ à l’ISET de Sousse , Tunisie
Hello,
Je ne suis pas sûr d’avoir 100% compris ta demande. Mais je vais tenter d’y répondre ; mais si ça répond pas vraiment, n’hésite pas à répondre à mon commentaire.
Pour lancer un projet de façon agile, je recommande de partir sur un framework de lancement agile : le framing agile (https://www.agile-framing.com/). Il permet de créer une vision du produit mais d’avancer de façon agile, lean et UX. Moi je le recommande plus qu’un sprint 0 qui est souvent mal compris et qui implique souvent d’avoir déjà des bases (sur les gros projets). Le framing agile étant souvent plus adapté.
Tu peux me donner ton whatzap si tu désires creuser le sujet.