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. Pensez-vous que vous devriez y passer aussi ?
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).
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.
Lorsque j’ai proposé à une nouvelle équipe de développer notre produit en sprints d’une semaine, il y a eu des inquiétudes.
Ce à quoi j’ai répondu :
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 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é.
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, pour faire ressortir autant d’améliorations, en moins de temps.
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.
I’m a big fan of moving to one-week sprints It forces the team to size stories small, eliminate waste in their meetings, work collaboratively at the last responsible moment. There’s a heap of goodness. … 1/x
— Allen Holub (@allenholub) March 14, 2018
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.
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.
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.
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.
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 :
Avez-vous déjà essayé le sprint d’une semaine ? D’un jour ? L’utilisez-vous déjà ? Avec quels résultats ?
