Équipe Scrum pendant les vacances : on change la durée de Sprint ?

[@ScrumLife]

Ca va se passer comment les vacances dans ton équipe ? 👇👇👇

[@dimitripanoryia8732]

Quid des escouades en SAFe, avec des sprints cadencés ? Pour ma part, la solution reside dans le calcul de la capacité, qui est propre à chaque sprint, en entrant les congés dans le calcul.

[@TomArchb]

Je savais que j'aurai dû faire un tour sur Scrum Life AVANT les vacances ! On est finalement passé en Kanban pendant la période des fêtes.. En vrai on avait hésité à allonger la durée de l'itération

[@Reconversion-pro-et-coaching]

Merci pour ces astuces qui tombent à pic pour les fêtes de fin d'année. Il n'est jamais inutile de rappeler que des périodes de congés doivent être anticipées dans les plannings. Nous avons tous tendance à rester la tête dans le guidon et à se faire surprendre alors que nous connaissons parfaitement les périodes de congés. Je conseille toujours de commencer à préparer des "listes de choses à anticiper" au moins un mois avant les congés. L'anticipation me semble être primordial : c'est le seul moyen de préserver la soutenabilité des objectifs et le bien-être des acteurs.

[@ScrumLife]

Je pense que ce qui est important ce n'est pas tant d'anticiper les vacances, mais plutôt d'en profiter pour s'assurer qu'on est toujours résiliant aux imprévus. Vois-tu la différence ? -- Constantin

[@Reconversion-pro-et-coaching]

Salut @const, Oui je vois bien la différence et je te remercie d'insister sur ce point ! L'un n'empèche pas l'autre (anticipation + profiter des congès pour s'assurer de notre résiliance) ? On imagine bien également qu'il faudra prendre le temps de trouver des solutions pour tirer les leçons de nos enseignements lorsque l'on constate des carences sur notre résilience... Jeremy 😉

[@PatrickBrouchet]

pour une fois que je suis gêné par une de vos vidéos : si des ressources manquent (et il n'y a pas que les vacances, épidémies, turnover non anticipés, etc..) on devrait en premier lieu adapter l'objectif de sprint. Et comme vous le dites à la fin de la vidéo (et c'est pour moi le plus important car des vacances il y en a régulièrement et ce n'est pas exceptionnel) cela peut être le moment de l'Inspection (lors de retro on se pose la question dans un mois, au prochain sprint la moitié de l'équipe est en congé comment voyez-vous les choses, et ce qui n'a pas pu être anticipé, on en parle aussi en retro, pour ce rendre compte que peut-être l'équipe n'est aussi pluridisciplinaire qu'elle le pense, l'occasion de montée en compétence, de demander des formation. Mais franchement présenter comme solution première de changer la durée de sprint me semble non seulement la solution de facilité mais également un biais qui pourrait nous amener à un dévoiement de cette consistency (adapter la durée aux objectifs au lieu des objectifs à la durée sur laquelle nous pensons que c'est le bon rythme pour nous. Bien sur on peut faire des essais lorsqu'une équipe se constitue pour trouver la bonne durée, mais cela reste finalement ponctuel, pas comme les vacances (plusieurs fois par an).

[@ScrumLife]

Merci pour ce feedback. En fait je pense que ça dépend beaucoup de comment tu utilises tes sprints. Le sprints n'est utile que s'il te permet d'apprendre si tu vas dans le bon sens de ton Product Goal. Donc, si tu n'as pas l'occasion d'avoir cette information en 1 semaine pendant les vacances car les gens pouvant te donner l'info ne sont pas, ou bien personne n'utilise ton produit pendant les vacances par exemple, alors quel est l'intérêt de faire un sprint ? Comment tu t'assures que tu vas dans le bon sens du Product Goal ? On ne dit pas qu'adapter la durée de sprint est LA seule solution bien sûr, mais ça ne doit pas être un tabou. Tu l'as bien écris : "le bon rythme pour nous". Et ce n'est pas forcément tout le temps le même tout au long de l'année. Ça me fait me poser une question, c'est quoi pour toi, dans ton contexte, les critères d'un "sprint réussi" ? -- Constantin

Les vacances est un cas "extrême" mais toute l'année, on a des variances sur la capacité. On fait des sprints d'un jour pour "apprendre" parce que c'est extrême. On utilise des vacances pour avoir des cas extrêmes de baisse de capacité, pour apprendre comment réagir. ==> apprendre : l'équipe va choisir sa réaction. Il n'y a pas de réponse universelle

[@OlivierFarlotti]

Je suis étonné. J'ai l'impression que vous ouvrez une boîte de Pandore 😅 Quid de la notion de triangle de fer agile ? En quoi les vacances empêche d'articuler la création de valeur adaptée aux moyens de l'équipe ?

[@ScrumLife]

Si tes utilisateurs sont en vacances, tes parties prenantes aussi, comment t'assures-tu avoir créé de la valeur ? Le but du sprint est d'avoir des feedback. Si tu ne peux pas en avoir, à quoi ça sert de faire un sprint ? Produire pour le principe de produire ? -- Constantin

[@OlivierFarlotti]

@@ScrumLife si vraiment pas de client en face, en effet 🙂 En même temps, pas de client à Noël ?! C'est les lutins qui vont être au chômage technique 😅

[@garancera]

Le rythme doit être constant... Ca dépend ce qu'on entend dans la constance... D'un point de vue agile, la soutenabilité prime, de plus, la constance n'a de sens que dans une approche hypothético-déductive : à quelle hypothèse va-t-on pouvoir répondre ? Souvent le problème survient face à un défaut de planification, de prise en charge du facteur humain, de la soutenabilité... Une chose qui vaut le coup, face à une équipe qui ne pense pas cela possible : elephant carpaccio... Cette question devrait souvent être posée à l'équipe par un Scrum Master en rétro en option : bon dans 2 sprint, c'est les vacances, on fait comment ? Souvent, avec un Elephant Carpacccio, + une question puissante, on arrive avec un peu de facilitation à un truc : l'autogestion... Prochaine étape : faire que l'équipe arrive elle-même à voir cette histoire arriver, s'adresse cette problématique, trouve un voie de résolution (si en plus ça passe par un dev ce serait magique)

[@yorg722]

La version officielle (non traduite) : "They are fixed length events of one month or less to create consistency" (cf Scrum Guide) D'un point de vue théorique, il y a une erreur répétée dans la vidéo : je cite "Un Sprint est une période définie qui peut durer d'une semaine à un mois". Comme on le sait, il n'y a pas de minimum pour un Sprint et on sait juste que le max fait 1 mois, cette histoire de "semaine" a tendance à créer de l'ambiguïté et à pousser à se caler sur des semaines calendaires alors que rien n'empêche de faire des sprints de 1 jour ou de démarrer un Sprint un jeudi, il me semble que vous en parlez dans une précédente vidéo d'ailleurs. Dommage. Toujours côté théorique, l'autre élément qui me gêne est l'interprétation faite à partir de la traduction française qui rappelons le, n'est pas le support officiel. Ici le traducteur français a choisi le terme "cohérence" pour traduire "consistency", mais ce mot peut également se traduire par "constance" ou "régularité". Ce qui renforce le fait que la durée du Sprint peut changer, mais que ça ne se fait pas à la légère, et généralement plutôt dans le but de raccourcir le cycle d'apprentissage ce qui est rappelé un peu plus loin dans le Scrum Guide "Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame". Côté pratique, ça me pose également un soucis : si on suit la logique de la vidéo, pourquoi ne changer la durée du Sprint QUE pour les vacances ? et pas pour les formations, les arrivés/départs dans l'équipe, les arrêts maladies prévisibles, la veille, etc.. Dit autrement, si on pousse la logique à l'extrême, pourquoi ne pas sortir concrètement de Scrum et créer son propre framework où il est nécessaire d'adapter systématiquement la durée de l'itération pour rendre constante la capacité de l'équipe, ce qui semble être le but de l'adaptation proposée ? Pour moi, le fait de changer la durée du Sprint de cette façon risque de poser un problème de transparence : - On cache le problème de "rush" après vacance, sans pour autant réellement le résoudre de façon pérenne - la vélocité risque fortement de ne plus refléter les événements de vie de l'équipe (vacance, formation, veille, etc..), bien qu'en soit si la capacité devient constante, la mesure des performances passées devient quasi inutile finalement ^^ - les vacances/absences deviennent un événement "gênant", un obstacle auquel il faut faire face, au lieu de rester un non événement, c'est à dire un élément normal de la vie de l'équipe qu'on accueille positivement - l'utilisation des ressources (on s'attends à ce que x personnes travaillent y jours) est mise en avant par rapport à la gestion du flux de valeur (fail fast, empirisme, etc.) et la prise en compte des contraintes dans l'accomplissement de l'objectif (l'objectif du Sprint est-il menacé par ce délai perçu comme plus court ? Si oui, est-ce que ça ne pose pas un soucis plus profond de définition d'objectif ? Si non, pourquoi s'adapter s'il n'y a pas de soucis ?) On perd donc au moins en partie la transparence et le lean thinking de Scrum. Pour moi, il ne s'agit plus de Scrum mais bel et bien d'un framework custom à part entière. D'ailleurs je me demande même si on est encore en agilité, puisqu'ici, il s'agit ici d'adapter le délai au lieu d'adapter le périmètre. En tout cas, la question est intéressante et mérite d'être discutée, je trouve juste dommage que le sujet ne soit pas traité avec un peu plus de recul.

[@ScrumLife]

Merci pour ta réponse ! Je vais essayer d'y répondre : "il n'y a pas de minimum pour un Sprint et on sait juste que le max fait 1 mois, cette histoire de "semaine" a tendance à créer de l'ambiguïté" - En effet, c'est un raccourcis qu'on fait. Dans les faits, on a déjà parlé du sprint d'1 jour, ce n'est pas un "vrai sprint" au final. Bien que rien n'empêche de faire 3, 6 ou 12 jours pour un sprint, néanmoins je ne le conseille pas, ça créé de la complexité, c'est quand même plus simple de savoir que nos sprint planning sont "le mardi à 10h", plutôt qu'une fois le mardi à 10h et ensuite le jeudi de dans 2 semaines et après le lundi de 2 semaines plus tard. "démarrer un Sprint un jeudi" - Je comprends l'ambuiguité que ça peut apporter, effectivement dans notre tête "1 semaine" n'implique pas du lundi au vendredi. Genre là on est mercredi, "dans une semaine" pourrait marcher. Mais je retiens la remarque, nous essayerons de faire plus attention :) "l'interprétation faite à partir de la traduction française [...] ci le traducteur français a choisi le terme "cohérence" pour traduire "consistency", mais ce mot peut également se traduire par "constance" ou "régularité"." - Nous en avions parlé dans quelques lives, il se trouve que j'ai eu la même interrogation que toi, et j'ai donc discuté avec le responsable de la traduction officielle de cette nuance, et il m'a confirmé avoir justement pour ce terme vérifié le choix de la traduction avec Scrum.org. De mémoire c'était un live très proche de la sortie du Scrum Guide 2020. "si on suit la logique de la vidéo, pourquoi ne changer la durée du Sprint QUE pour les vacances ?" - on le mentionne quand même qu'on ne le conseille pas. Ca ajoute de la complexité. Par contre je ne suis pas d'accord sur la vélocité. Je conseille généralement de ne pas calculer la vélocité sur un sprint, mais sur 1 semaine. Qu'on fasse un sprint de 1, 2 ou 3 semaines ne change rien, on calcule le nombre d'item fait par semaine. Oui je suis d'accord que c'est un gros sujet. Nos vidéos essayent de rester courtes, mais ça ne veut pas dire qu'on va s'arrêter là sur ce sujet :) -- Constantin

[@DavidCASBONNE]

Oula.... Je ne suis tellement pas d'accord avec ça... Alors oui on peut adapter la durée des sprints en fonction de la phase de développement, on commence long, on raccourci, on rallonge. Sans aucun problème et en fonction aussi de l'équipe. Mais de là à changer pour 1 sprint pour les vacances... Et vous faites ça 4 fois par année j'imagine ? Les vacances de ski, de l'été, les ponts de mai et Noël ? Pour moi ce qui fonctionne c'est simplement d'ajuster la capacité et donc l'objectif. Non mr le PO on ne fera pas autant de dév. Oui la vélocité va être impactée mais au final ce qui nous intéresse c'est que l'équipe livre de la valeur non ? Et qu'elle le fasse dans un rythme soutenu et soutenable. Allonger les sprints de vacances je trouve que ça va totalement contre la régularité et le rythme amené par scrum.

[@loicdubart6362]

Totalement en phase, on doit plutot s'adapter en fonction de ce que l'équipe sera capable de faire pendant la période des vacances et définir son objectif en conséquence. Et aussi profiter des difficultés rencontrés (dépendances humaines) pour les travailler et "mieux vivre" la prochaine période d'absence de ces membres de l'équipe

[@lazyac_]

On itere aussi vite qu'on peut faire de demo ou refiner, moi mes sprints ils bougent si les stakeholders sont absents ou si le business n'a pas bougé le sprint goal est difficile à définir je laisse l'equipe faire un sujet 100% tech sans business value ou si il reste qu'un dev pour refiner ... et plus mon équipe est petite plus j'allonge sinon le temps passé en planing/retro/demo est trop important par rapport au temps de dev ( ou je fais la retro un sprint sur deux). On bricole pour pas frustrer l'équipe et faire du scrum en appliquant sans réfléchir ( si y a un incident de prod le matin je laisse l'equipe skip le daily elle est au front, y a pas besoin de faire un dessin pour comprendre que le sprint goal est pas le sujet du jour).

[@benoitdelemarle398]

Bonjour, super la vidéo 👍👍 Ou peut on trouver le pdf de checklist des vacances svp?

[@corentinguillaume2738]

Un oscar pour Constantin ! :D

[@veroniquelancelot9819]

Il faut aussi gérer les capacités durant le sprint. Si moins de personnes présentes ben moins de capacités et donc moins de chargement du sprint 😅

[@ScrumLife]

En effet, on en parle d'ailleurs vers la fin de la vidéo. on adapte le sprint en fonction de qui est là ou pas là. De ton côté, vous faites comment pour ces vacances ? -- Constantin

[@veroniquelancelot9819]

Nous on va agir sur un allongement de sprint et on enlève des jours de capacités en fonction des congés pour ces vacances. En gros notre sprint de 3 semaines passent à 4 semaines, on a calculé notre capacité jour-homme de l'équipe en retranchant les jours en fonction des congés posés et en retranchant les temps prévu pour nos cérémonies agile. Une fois nos vrais capacités calculées, on alimente notre board et définit nos objectifs en fonction de nos capacités. Cela se passe très bien et ce n'est pas le chaos au retour de vacances.

[@amirablaiech3538]

J'ai une question. J'ai pas compris ce qu'il faut faire dans le cas où une personne indispensable prend vacance et que ses compétences et que personnes dans l'équipe ne sais faire alors comment faire ?

[@ScrumLife]

Salut ! Ce qu'il faut faire c'est de préparer les vacances en faisant monter en compétences, dès que possible, le reste de l'équipe pour qu'elle soit capable de se débrouiller sans cette personne. J'imagine que cela semble difficile à faire dans ton contexte ! Avez-vous déjà essayé ? -- JP

[@ScrumLife]

Salut @amirablaiech3538, C'est une excellente question et une situation que beaucoup d'équipes rencontrent. Dans l'approche agile et plus spécifiquement dans Scrum, l'objectif est d'éviter que les connaissances soient concentrées entre les mains de quelques individus. Cela signifie que dès le départ, il est crucial de favoriser le partage de compétences au sein de l'équipe. On peut utiliser des techniques comme la revue de code en binôme (pair programming) ou des sessions de partage de connaissances pour démocratiser les savoirs critiques. Maintenant, si tu te retrouves déjà dans cette situation où quelqu'un d'indispensable part en vacances, il y a quelques étapes à suivre : 1. **Identifier les tâches critiques** : Avant que la personne ne parte, assure-toi de bien identifier lesquelles de ses tâches sont critiques. 2. **Documentation** : Demande à la personne de documenter ses procédures de travail de manière exhaustive. Une bonne documentation peut sauver la mise quand il y a une absence imprévue. 3. **Formation croisée** : Si possible, organise des sessions de formation rapide pour que plusieurs membres de l'équipe acquièrent ces compétences de base avant le départ de la personne. 4. **Communication** : Il est vital de communiquer de manière transparente avec toutes les parties prenantes pour mettre en place un plan de contingence. Et toi, as-tu déjà essayé certaines de ces approches dans ton équipe ? Comment cela s'est passé ? À bientôt, Robin

[@nicolasponcet8626]

Bonjour, Je suis d accord avec le point sur la durée des Sprints qui peut être adaptée. Principalement, les équipes conservent une durée constante dans le temps pour améliorer la prédictabilité du delivery, pour améliorer leur niveau de confiance sur ce qui est acté en Sprint Planning... mais ça s entend bien "à équipe constante". Donc si l'équipe varie on peut effectivement envisager de modifier cette durée. Ceci étant dit, pourquoi ne pas aussi proposer d'ajuster l' engagement de l équipe, ou le Goal, voire de profiter des vacances pour faire de l exploratoire, de la réduction de dette technique, etc. Le Sprint n est pas juste une urne que l on bourre avec les n US voulues par le PO 😅