Habitué comme beaucoup aux sprints de deux semaines, j’ai pu me rendre compte de l’impact qu’un sprint d’une semaine peut avoir sur le produit et sur l’équipe scrum. Pensez-vous que vous devriez y passer aussi ?
Définition du sprint
Voici la définition du Sprint, telle que présentée dans le Scrum Guide :
Le cœur de Scrum est le Sprint, qui a une boîte de temps (timebox), une durée, d’un mois ou moins au cours de laquelle un Incrément Produit « Fini » fonctionnel et potentiellement publiable est créé.
Comme je l’ai expliqué dans mon article Scrum : quel est le bon jour pour commencer un sprint ?, le guide nous laisse libre de faire des sprints d’une minute, à quatre semaines. Nous pouvons même faire des sprints de 3, 13 ou 20 jours –mais ce n’est vraiment pas pratique et je le déconseille (voir l’article).
On en est où ?
Vincent Barrier, CEO de Kagilum éditant le logiciel IceScrum (que je conseille d’essayer), m’a très aimablement fournit la répartition de la durée des sprints parmi les utilisateurs d’IceScrum (en mars 2018) :
15% -> 1 semaine
80% -> 2 semaines
4% -> 3 semaines
1% -> autres
On se rends bien compte de l’écrasante majorité du sprint de 2 semaines.
Les logiciels de gestion de projet (comme IceScrum ou Jira), proposent d’ailleurs la durée de deux semaines, par défaut. Est-ce que cela influence les équipes à ne pas y réfléchir et à choisir la valeur par défaut ? Possible.
A priori sur le sprint d’une semaine
Lorsque j’ai proposé à une nouvelle équipe de développer notre produit en sprints d’une semaine, il y a eu des inquiétudes.
- Nous n’aurons pas le temps d’avoir un produit fini à chaque itération
- Nous passerons trop de temps en événements et préparations
- Nous ne pourrons pas finir de grosses fonctionnalités
Ce à quoi j’ai répondu :
- Les fonctionnalités embarquées seront moins nombreuses et mieux découpées
- Les événements peuvent (et doivent) s’adapter. Il y en a autant, mais ils durent moins longtemps
- L’intérêt est justement de mieux découper les grosses fonctionnalités
Le résultat
Comme le dit Rob Galanakis, si mon équipe travaille en sprints d’une semaine, c’est pour avoir du feedback très rapidement. Si vous travaillez en sprints de trois semaines, alors que nous travaillons sur des sprints d’une semaine, nous avons l’occasion d’avoir trois fois plus de feedback et trois fois plus d’opportunités d’échouer, d’apprendre et de nous améliorer.
Au lieu de discuter si nous devrions essayer quelque chose, nous le testons immédiatement, empiriquement. Cela permet la culture de l’échec et d’en réduire considérablement les impacts. Nous éliminons l’effet tunnel car nous acceptons de considérer les éléments du backlog produit (avant leur arrivée dans un sprint donc), comme des options pouvant être remises en cause.
Les éléments du backlog ne sont que des options possibles, tant qu’ils ne sont pas embarqués dans un sprint
Pour le product owner, il est presque impossible de négocier l’entrée dans le sprint d’éléments “non-prêts”. Sur un sprint d’un mois, il est tentant d’ajouter une fonctionnalité dont les maquettes doivent arriver “dans quelques jours”. Sur une semaine, le risque est trop grand et il est facile de se dire qu’on peut attendre le prochain sprint.
Pour une équipe qui n’est pas encore à l’aise avec Scrum, c’est aussi un bien meilleur moyen d’apprendre. Plus l’itération est courte, plus vite l’équipe acquiert le processus.
Si l’agilité repose sur les feedback, alors réduire de moitié la durée de vos sprints vous donne le double de feedback et de chances de vous améliorer. Vous pouvez essayer quelque chose pendant une semaine, vous rendre compte que ça ne fonctionne pas et partir sur autre chose sans mettre une release en péril. Pour un sprint deux fois plus long, c’est deux fois plus risqué.
L’impact n’est pas le même pour tous
Pour le Scrum Master, le coût de la rétrospective par exemple est au moins le même. L’évènement en lui même dure forcément moins longtemps, mais la préparation nécessite d’être plus précise.
Le Product Owner se doit d’être particulièrement attentif aux besoins des développeurs. Ils n’ont pas le temps de se dire “on verra ça demain”. “Demain”, c’est 20% du sprint en moins.
Au final, c’est peut-être l’équipe de développement qui est la moins impactée négativement. Nous ne lui demandons pas de travailler plus vite; Au contraire, nous pouvons lui laisser plus de libertés.
Au final, cela demande surement plus de discipline qu’un sprint plus long.
Conclusion
La durée d’un sprint ne se choisit pas parce que c’est la mode, ou simplement parce qu’on est habitué comme ça.
À chaque nouveau projet, vous devriez vous poser la question sérieusement et la soumettre au reste de l’équipe.
- Pouvons-nous avoir des retours utilisateurs chaque semaine ?
- La définition du “fini” nous permet-elle de livrer chaque semaine ?
En effet, l’intérêt premier du cycle court est d’avoir des retours utilisateurs. Si ce n’est pas possible pour vous d’en avoir aussi régulièrement, il faut réfléchir à la pertinence d’aller vers un sprint court.
Certains le font déjà sans oser se l’avouer
Beaucoup d’équipes qui font des sprints de 2 semaines ou plus organisent “un point mi-sprint”, ou par semaine. Pourquoi ? Pour se coordonner et pour se remettre en question. C’est une bonne alternative au sprint plus court, mais il serait bon de se demander pourquoi ne pas le formaliser comme tel.
On peut faire plus court
Pourquoi ne pas descendre à des sprints d’une journée ? Une multitude de sprints, avec des points réguliers (toute les semaines par exemple), pour se remettre en question et s’améliorer comme on ferait une rétrospective “produit” tous les 6 sprints par exemple.
Et vous ?
Comme on vient de le voir, bien que ce soit plus intense pour le Scrum Master, le sprint d’une semaine a bien des vertus :
- Du feedback très rapidement
- Permet la culture de l’échec et d’en réduire les impacts
- Difficile de négocier l’entrée dans le sprint d’éléments “non-prêts”
- Plus l’itération est courte, plus vite l’équipe acquiert le processus
Avez-vous déjà essayé le sprint d’une semaine ? D’un jour ? L’utilisez-vous déjà ? Avec quels résultats ?