Comment choisir la bonne durée de Sprint
Avez-vous déjà entendu - ou vécu - ces scénarios ?
"On ne livre pas à temps ? C’est parce que le sprint est trop court, pas le temps de travailler !"
"On ne prend pas action après nos rétrospectives ? C’est parce que le sprint est trop long, trop de temps entre deux rétros !"
"On passe notre temps en meeting ! C’est parce que le sprint est trop court, on enchaîne et on répète les mêmes rencontres !"
Au cours de mes années en tant que Coach Agile, j’ai remarqué que la durée de sprint revenait régulièrement comme la cible facile d’une équipe qui cherche à se déresponsabiliser des problèmes qu’elle rencontre.
Tant de fois, des équipes m’ont remonté des doutes ou de la frustration concernant la durée de leurs sprints. Pourtant, ces équipes avaient des itérations de différentes durées. Parfois très courtes, parfois plus longues. Et pourtant, la durée de leur sprint semblait cristalliser une gêne récurrente.
Bien souvent, la cadence de leur sprint leur fut imposée par le management qui cherchait à harmoniser la cadence de livraison entre les différentes équipes. C’est d’autant plus vrai dans un contexte SAFe, mais nous reviendrons sur ce point plus tard. Le problème, c’est que cette décision ‘’top-down’’ peut provoquer une véritable levée de boucliers, puis une réelle barrière à l’adoption des bonnes pratiques agiles.
Quand on y pense, chaque équipe vit une réalité qui lui est propre. Avec son rythme, ses objectifs et ses contraintes qui lui sont propres. Non ?
Alors, venons-en aux faits. Comment déterminer la bonne durée de votre sprint ? Je glisserai dans cet article quelques conseils de coach que j’ai pu expérimenter et mettre en place avec mes équipes. Voyons cela ensemble dès maintenant afin de vous équiper pour pouvoir gérer ce type de situation.
Au programme de cet article:
Qu’est-ce qu’un Sprint ? Quelle est sa durée idéale ?
Pour bien démarrer, revenons sur ce qu’est un sprint et son utilité dans le quotidien des équipes.
Le guide Scrum introduit la notion de Sprint comme ceci :
“[Les Sprints] sont des événements d'une durée fixe, d'un mois ou moins, pour créer une cohérence. Un nouveau Sprint commence immédiatement après la fin du précédent.
- Ken Schwaber & Jeff Sutherland, Guide Scrum
Le guide Scrum poursuit avec ces indications :
“Les Sprints permettent la prédictibilité en assurant l'inspection et l'adaptation de la progression vers l'Objectif de Produit, une fois par mois calendaire au moins. Lorsque l’horizon d’un Sprint est trop lointain, l’Objectif de Sprint risque de ne plus être le bon, la complexité augmente et, avec elle, le risque. Les Sprints plus courts raccourcissent le cycle d’apprentissage, limitant ainsi les risques liés aux coûts et à l’effort. Chaque Sprint peut être considéré comme un projet court.”
Côté SAFe, la définition est sensiblement la même. À la différence près qu’un Sprint y est appelé Itération :
"Les Itérations sont les constituants de base du développement Agile. Chaque itération a une durée fixe standard au cours de laquelle les équipes Agile livrent une valeur incrémentale sous la forme de logiciels et de systèmes fonctionnels et testés."
Et qu’en est-il de la durée idéale d’une itération ?
Voici ce que nous livre Scaled Agile :
“La durée recommandée de l’itération est de deux semaines. Toutefois, une durée d’une à quatre semaines est acceptable, selon le contexte d'affaires.”
Les cadres Scrum comme SAFe se rejoignent en préconisant des périodes de développement courtes, d’un mois ou moins. Dans les deux cas, une ouverture à adapter la durée au contexte de l’équipe y est évoquée.
À noter que par ‘’cycle d’apprentissage’’, le guide Scrum souligne l’importance de la boucle de feedback (ou rétroaction) inhérente à chaque sprint. En rencontrant votre utilisateur final à chaque fin de sprint, ce dernier vous permet de récolter les commentaires nécessaires à l’amélioration continue de votre produit. Il en ira de même avec vos rétrospectives, conçues pour échanger en équipe pour tirer l’équipe vers le haut.
Après cette révision du volet théorique, plongeons dans la pratique et observons les problématiques que les équipes rencontrent fréquemment autour de la gestion des sprints.
Les principales objections autour de la gestion des sprints
Voici les 3 objections que j’ai le plus souvent entendues au cours de mes années de Coach Agile. Nul doute que vous vous reconnaîtrez dans au moins l’une d’entre elles ;)
Friction #1 : On passe notre temps en meeting !
Qui ne l’a pas déjà entendu ou pensé ? Ici, il faut commencer par identifier si le problème est (1) la fréquence des rencontres, (2) leur durée ou (3) leur pertinence aux yeux des membres.
La durée et la fréquence sont intimement liées. Plus le sprint est long, plus les rencontres qui viennent le ponctuer le seront également.
D’une manière générale, j’ai remarqué que la plupart des équipes suivent une règle de pouce d’une heure par rencontre par semaine de sprint (1h pour un sprint d’une semaine, 2h pour une durée de 2 semaines, etc.). Cette règle s'applique donc à vos planifications, revues, affinages et rétrospectives.
Pour illustrer concrètement cette règle, prenons l’exemple du Sprint planning en nous appuyant sur ce que suggère le guide Scrum
"Le Sprint Planning est limité dans le temps à un maximum de huit heures pour un Sprint d'un mois. Pour les Sprints plus courts, l'événement est généralement plus court.’’
- Ken Schwaber & Jeff Sutherland, Guide Scrum
On comprend donc qu’allonger le sprint ne règle pas vraiment le problème du temps passé en rencontre. Plutôt que 2h chaque 2 semaines, un planning durera par exemple 3h chaque 3 semaines.
💡 Conseil de coach : en équipe, questionnez-vous sur la pertinence de vos rencontres en vous demandant si le temps de chacun y est bien investi. Au-delà de vos rétrospectives, vous pouvez étendre ce réflexe aux rencontres ad-hoc organisées par des membres externes de l’équipe, communément appelées ‘’Sync; 1-1; debrief; Update; etc…’’.
Bien souvent, ces dernières ne sont pas suffisamment préparées, manquent de pertinence et les membres d’équipe se sentent obligés d’y participer. Elles peuvent même être récurrentes et donc fatales dans un agenda !
Par exemple en fin de rétrospective, le ROTI est particulièrement efficace pour prendre le pouls de votre équipe concernant la rencontre que vous venez de passer.
Friction #2 : On court après le temps et on ne termine jamais nos livrables !
Avant de rentrer dans les solutions, il faut d’abord identifier pourquoi l’équipe ne livre pas le niveau de valeur attendu à la fin de son sprint. Bien souvent, le découpage des récits est superficiel et fait tant bien que mal durant la rencontre de planification - soit par manque de temps, soit par manque d’expertise. On se retrouve donc avec des morceaux trop gros, truffés de variables inconnues qui viendront inéluctablement retarder la livraison.
💡 Conseil de coach : Si votre équipe fait régulièrement face à un engagement trop important pour sa capacité d’exécution réelle, réduire ou augmenter votre durée de sprint ne fera que nourrir cette pression. Dans ce cas de figure, je vous suggère plutôt de revenir aux bases et de revoir vos DoR (Definition of Ready - Définition de Prêt) et DoD (Definition of Done - Définition de Terminé). Pour vous faciliter la vie, vous pouvez proposer à l’équipe d’avoir une rencontre d’affinage qui vous permettra de retravailler les récits du prochain sprint avant la planification.
Vous pourriez même établir votre Vélocité, du moment qu'elle est utilisée pour vous aider et ne devient pas une vanity metric (une statistique de performance qui semble impressionnante à première vue, mais qui ne traduit pas de résultat concret dans la poursuite des objectifs).
Friction #3 : À peine le sprint terminé, on doit déjà recommencer !
Je comprends cette frustration. L’agilité est un marathon. Il faut donc trouver le bon tempo, tel qu’évoqué dans le point précédent. Une nouvelle fois, la durée du sprint n'apporte que peu de réponses à cette problématique.
💡 Conseil de coach : Avec l’accord de votre Product Owner, suggérez aux membres de l’équipe de travailler sur leurs tâches de manière alternative. Par exemple, organiser un hackathon permet aux membres de briser la monotonie des sprints. À noter que SAFe suggère une itération d’innovation par Planning Interval (2 semaines par trimestre par exemple).
Comment décider de la bonne durée de sprint
L’équipe connaît mieux son propre contexte. Plutôt qu’une approche ‘’top-down’’ où la direction décide de la durée de sprint, on aimerait lorsque possible que l’équipe se responsabilise et opte pour une approche ‘’bottom-up’’ ou elle décide elle-même de comment fonctionner. Elle expérimente, elle prend action et elle s’adapte aux résultats. En d’autres termes, elle est auto-organisée.
Ce processus d’essais-erreurs, soutenu par une culture de confiance et de transparence, permet de trouver un rythme soutenable et durable, au lieu d’appliquer une règle universelle qui ne tiendrait pas compte du contexte de votre équipe. Le résultat aura donc davantage de chances d’être un succès !
Si, après diagnostic avec votre équipe, vous jugez que la durée de votre sprint est le problème profond à régler, gardez en tête que ce changement n’est pas anodin. Avant de prendre une décision, il faut se rappeler que des effets secondaires pourraient se présenter.
Si vous allongez vos sprints, vous allongez vos cycles d’apprentissage.
La boucle de feedback avec votre client sera plus longue. En effet, si vous attendez vos revues de sprint avant de présenter votre progrès à vos parties prenantes, alors vous repoussez la prise de feedback. Par extension, vous vous exposez donc à plus de risques… et donc plus d’imprévus.
Vous réduirez les occasions de vous rassembler en rétrospective et donc de célébrer les succès ou de prendre action sur les éléments à améliorer.
Sprints de 2 semaines = 26 rétros par an
Sprints de 3 semaines = 17 rétros par an
Sprints de 4 semaines = 13 rétros par an
💡 Conseil de coach : peu importe votre cadence de sprint ou même votre cadre (Scrum, SAFe, Kanban, etc.), n’hésitez pas à présenter vos progrès et incréments de valeur le plus tôt possible à vos clients. Vous réduirez ainsi la durée de votre boucle de feedback. Il en va de même pour la résolution de problèmes dans l’équipe, où il ne faut pas attendre la rétrospective pour communiquer.
Si vous raccourcissez vos sprints, vous vous exposez à du feedback superficiel.
Le feedback reçu trop fréquemment peut devenir superficiel. Pas assez de temps s’écoule pour que les apprentissages soient suffisants. Cela peut donner l’illusion d’une amélioration continue rapide, mais sans réelle profondeur ni consolidation des apprentissages.
L’alignement entre les équipes peut devenir un vrai challenge sur des sprints courts. C’est particulièrement vrai dans un contexte SAFe ou les synchros des POs et Team Coachs s’ajoutent aux autres rencontres.
💡 Conseil de coach : assurez-vous d’avoir des récits prêts, suffisamment petits avec une bonne gestion des risques. Plus votre sprint est court, moins vous aurez de marge de manœuvre.
Et si le problème venait du concept même de sprint ?
Certaines équipes se prêtent mieux à l’approche Kanban qui fonctionne sur un flux continu plutôt que des cycles fixes.
Source : Unichrone
On pourrait citer à titre d’exemple les équipes Support, qui gèrent quotidiennement les demandes de leurs clients. Ces dernières ne peuvent être anticipées et donc ne peuvent être planifiées dans un futur sprint. Une approche en flux continu semble donc plus appropriée. La priorisation et la livraison sont continues, le rythme s’ajuste naturellement à la capacité de l’équipe - plutôt qu’en anticipation.
Cette approche favorise la visualisation du travail en cours, limite le multitâche (WIP limit - Limite de travail en cours) et met en évidence les goulots d’étranglement. Elle permet également une amélioration continue plus fluide, car l’équipe inspecte et adapte son flux en permanence, plutôt qu’à la fin d’un sprint.
Pour certaines équipes, passer à un flux continu peut représenter une véritable libération : moins de pression temporelle, plus de flexibilité, et un focus constant sur la valeur livrée plutôt que sur la complétion d’un sprint. À méditer…
Bien s’outiller pour tirer le maximum de votre boucle de feedback
Un peu plus tôt dans cet article, je vous parlais de l’importance d’effectuer votre diagnostic d’équipe initial avant de prendre toute décision sur un changement de durée de sprint.
Facile à dire mais… aussi facile à faire grâce à Neatro.
En effet, je vous recommande de lancer un Radar d’équipe de Neatro. Cette fonctionnalité vous permettra de dresser un portrait global de votre équipe grâce à la récolte asynchrone (et potentiellement anonyme) de leur feedback sur des aspects clés tels que vos Processus d’équipe, votre Collaboration ou encore votre Vélocité. L’équipe sera ainsi libre de prendre le temps de s’exprimer sur les aspects du quotidien, positifs comme négatifs.
Une fois ce feedback récolté, vous serez en mesure d’identifier les thèmes forts de l’équipe, puis les thèmes qui fonctionnent moins bien actuellement.
Il sera alors temps pour vous de passer à l’étape suivante en dédiant une rétrospective complète sur le ou les thème(s) à renforcer en utilisant une activité qui vous permettra de sortir des sentiers battus.
Les Briques de Valeurs, Espoirs et Inquiétudes, les Pour et les Contre ou encore la Futurespective Star Wars me semblent particulièrement adaptés à la situation. Les résultats du Radar d’équipe viendront naturellement nourrir vos conversations afin de vous amener sur un plan d’actions adapté à vos enjeux.
Vous pouvez aussi vous laisser inspirer par les autres modèles disponibles dans Neatro.
Un dernier conseil, pour la route...
Il n’existe pas de durée de sprint universelle, seulement celle qui correspond le mieux à votre propre contexte d’équipe. Favorisez donc l’expérimentation et surtout la livraison de valeur, l’apprentissage continu et la cohésion d’équipe. Soyez curieux, et n’hésitez pas à sortir des sentiers battus de votre entreprise en explorant une approche Kanban par exemple.
En parlant d’apprentissage continu, cela fait désormais plusieurs années que Neatro me facilite la vie pour accompagner mes équipes et générer des discussions qui ont du sens. Qu’il s’agisse de nos sprints, de leur durée, ou tout autre sujet, j’ai toujours une activité adaptée à la conversation que je souhaite avoir avec les membres d’équipe.
Si vous voulez en apprendre davantage, n’hésitez pas à jeter un œil à l’expérience de rétrospective Neatro. Lancez une démo de présentation Neatro ici.
Et si vous préférez passer immédiatement à l'action, commencez à utiliser Neatro gratuitement ici.