Petit cadre de travail ^^
Je suis Scrum master depuis 1 an dans un gros groupe
J’encadre actuellement 2 équipes ( 5 dev et 1 testeur par equipe ) qui travaillent tout les 2 sur le meme produit
Les équipes fonctionnent sur des sprints de 3 semaine en décaler , ce qui donne
Semaine 1 fin/debut de sprint team A
Semaine 2 fin/debut de sprint team B
Semaine 3 relache pour les equipes , et planification des prochaines sprints pour les leads
En plus de mes 2 equipes , le produit est dépendant
D’une autre equipe de on va dire plutot des devOps
Un responsable métrologie
Ce qui fait que l’on est meme pas totalement autonome sur nos sorties de versions, et sur nos tests de version
A coté de cela, nos chefs de au dessus nous poussent a faire + de recherche et developpement en 2025 et freiner sur la maintenance
C’est un peu tout ca qui m’a amener a la reflexion de « Et si on passais a des sprints de 4 semaines? » . Une partie de moi hurlais « nonnnnn » , mais meme si il est plutot mieux vu de raccourcir les durées de sprints, j’ai quand meme trouver un interet a passer a des sprints de 4 semaines, voici ce que j’ai principalement pensé
Deja, vu que mes 2 equipes sont sur le meme produit, au niveau de la cadence de livraison de mon produit je vais rester sur 2 semaines , alors que aujourdhui , le Po ne sachant jamais quelle semaines sont des fin de sprints , il me place un peu des deadlines nimporte comment
Passer a 4 semaines me permettra de d’avoir une meilleure égalité entre mes equipes , en ce moment quand il y a des trucs un peu urgent a faire, ca tombe sur la prochaine equipe a commencer son sprint, donc 2 fois sur 3 ma team A
J’aurai pour chaque equipe une vrai semaine de rafinement des items et du backlog dédié que a elle, et de ce fait, je vais pouvoir incité les leads a reflechir/rafiner/definir leurs besoins une fois toutes les 2 semaines, au lieu de 1 fois sur 3, ce qui nous offrira une meilleure visibilité
Les sprints de 4 semaines permettrons plus facilement d’intégrer des items de recherche dans le sprint, car a l’heure actuelle , dès qu’on parle de recherche, soi ca déborde sur plusieur sprints , soi un de mes dev sort de l’equipe pendant 3-4 sprints pour pouvoir avancer seul de son coté
Certains partis externe serons legerement moins occupé par nos réunions , et moins de réunions c’est toujours un petit plus
Mes équipes étaient partagé entre le OUI , et le « Essayons pour voir » , j’ai donc lancer ce changement pour 2025
Mais je ne peux m’empecher de me demander si je fait pas une erreur ^^, mais apres tout, quelque chose ne va pas, j’essaie donc de provoquer un changement qui j’espere permettera a mes equipes de mieux fonctionner, quitte a me planter et qu’on revienne en arriere
Qu’en pensez vous ? Certains ont-ils deja été dans un genre de cas similaire ?
Selon la métrique DORA du Change Lead Time, augmenter la durée des sprints, et donc le délai entre les commit et les mises en production, c’est une régression, et donc pas une très bonne idée.
A court terme, ce passage de 2 à 4 semaines pour tes sprints sera indolore, et tu pourras même y voir des avantages car tu continueras à bénéficier par inertie de la performance acquise grâce à tes sprints de 2 semaines.
Mais progressivement, tu constateras que les mises en production qui étaient jusqu’à présent des non-événements, vont devenir des sources de préoccupation, avec davantage de bugs à corriger après coup, et des tensions croissantes avec les Ops et tes utilisateurs.
My 50 cents.
Je pase de 3 a 4 semaines
Et avec 3 semaines, mes mises en production défini par le produit était un peu random et pas lié a la fin d’un sprint
En passant a 4 semaines avec 2 equipes sur le meme produit , je retrouve justetement une mise en prodution toutes les 2 semaines, car les équipes vont avoir leurs sprints en quinconce
Tu as ta réponse dans ce cas. Mais excuse moi de ne pas avoir compris au premier abord les subtilités de fonctionnement de tes deux équipes. Avec ce complément, c’est bien plus clair.
« quelle drôle d’idée » la somme de ces 2 équipes donnent un groupe de taille raisonnable pour une équipe scrum (il y a juste à transformer le groupe en équipe) (team canvas), et les garder en 2 équipes doit générer un gaspillage en synchronisation.
// Fin de réaction à chaud sans avoir lu la suite ni pris connaissance du contexte complet
Il faut faire la différence entre livraison et déploiement.
L’équipe est seule responsable de ce qu’elle dé(livre)
La gestion du produit est responsable du déploiement des livrables (gestion du changement, gestion des risques, gestion de l’information…
Je dis ça parce que je lis qu’on est dans un cadre où la gestion du produit n’est pas attribuée à l’équipe qui le fait évoluer.
le responsable (d’exploitation) du produit ? ← à priori c’est son boulot de décider le ratio maintenance/évolution et ce en fonction des SLA (si on baisse les exigences dans les SLA alors il y a moins de maintenance)
le product owner ? ← à priori c’eut été son boulot si c’était une équipe scrum unique et responsable.
Une deadline (ou date d’échéance ou de perempition de la demande), c’est la date après laquelle ce qui est attendu pour cette date, et qui n’est pas fini, valse à la poubelle.
Il peut fixer des deadlines où il veut quand il veut tant que ce sont réellement des deadlines.
Si tu entends, bah c’est pas fini on va le terminer pour la semaine/sprint/Incrément/… suivant , c’est que c’est du bullshit deadline.
Et l’équipe va tenter de délivrer des livrables (finis) de qualité pour cette date.
S’il n’y arrive pas, on jette le tout (et on apprend). C’est d’ailleurs pour cela qu’il faut le « arrêtez de commencer, commencez par finir » . Pour qu’il y ai le moins de rebut à la deadline.
Attention, ce n’est pas la même chose qu’un milestone qui n’est plus une « date »
Une Deadline c’est le debut des JO, le salon XXXX où les commerciaux vont présenter le produit, la présentation annuelle des produits en interne, la date de mise en application d’une nouvelle réglementation…
Un milestone c’est une étape (et là il va fixer un lot de fonctionnalités finie et désirée mais pas imposer la date)
Si on veut un milestone pour une certaine deadline, alors on joue sur le périmètre
baisser la qualité, la quantité, … du moment que c’est « clair », « affiché », « acté »
Bonjour ce sujet cadrage équipes m’intéresse car le rappelle une mission en tant que analyste dev au sein d’équipes multiple sur un même produit. Tes 2 teams ne seraient elles pas front et back ? Ou plus précisément front / intégration métier ?
Concernant les déploiements je suppose qu’ils peuvent être fait par lot?
Une Deadline c’est le debut des JO, le salon XXXX où les commerciaux vont présenter le produit, la présentation annuelle des produits en interne, la date de mise en application d’une nouvelle réglementation…
C’est en effet ce que j’ai appris en banque : « changements réglementation ».
D’ailleurs quand pas fini c’est complexe et suis curieux de connaître vos façon de faire.
Même si anticipé les changements imprévus par d’autres projets ou corrections livrés deviennent balle dans le pied.
Passer de 3 semaines à 4 peut être une bonne idée ou une mauvaise…
Mauvaise si tu corrèle MEP et Sprint, tu vas exploser ton lead time…
Mais si livres plusieurs fois par sprint, voir avec une CI/CD top, plusieurs fois par jour au besoin : c’est propre…
Mais, il va falloir que tu considères deux choses : tu vas espacer tes feedbacks… Tu pars vers de la R&D, mais tu veux les espacer ??? Tu opposes la complexité manifeste de ton contexte à une probl’ématique de gestion… Sers-tu ton équipe ou d’autres intérêts ???
Après, une seule chose permettra de savoir si c’est une bonne idée, le retour d’expérience, nous sommes sur une pratique empirique, combien même tout ce que tu ferais serait contre intuitif, dans ton contexte, peut-être que cela fait sens et fournira de bien meilleur résultats que toute théorie ne saurait expliquer ou mal…
Le principe, n’est pas d’avoir raison, de gagner ou de perdre, mais d’apprendre…
