Que dois-je faire si un membre Scrum part à mi-chemin?

12

En raison de l'état de santé de l'un des membres de la mêlée, il doit quitter l'équipe.

Ma question est, dois-je recommencer une session de planification de sprint? ou changer le tableau de gravure? ou demander à tous les membres de l'équipe de mordre la balle et de faire un travail supplémentaire pour atteindre l'objectif?

Merci

scrum scrum-master

— janetsmith
source

7

Ironiquement, c'est là qu'un respect aussi strict de l'agilité entraîne trop de rigidité. Reculez une seconde du fait que vous essayez d'ajuster une approche agile. Quelqu'un a quitté votre équipe, redistribue la charge de travail et priorise. Vous n'avez pas besoin d'une réponse spécifique à Agile ici. Les gens prennent ces méthodologies trop à la lettre. Sans paraître condescendant, ce n'est que du bon sens ce que vous devez faire ici.

— JᴀʏMᴇᴇ

En tant qu'entraîneur, je dis toujours à mon équipe: FAITES CE QUI REND SENS! Qu'est-ce que l'OP et les parties prenantes doivent entendre? Quelles décisions doivent-ils prendre? Quels impacts ce départ a-t-il sur l'équipe à court, moyen et long terme? Que faut-il faire pour y remédier? Heureusement, Scrum et Agile sont basés sur des valeurs et des principes et NON sur un livre dense de règles.

— Curtis Reed

20

Vous devez supprimer la portée des histoires les moins importantes et les déplacer vers le prochain sprint. Votre capacité a changé et le sprint devrait refléter cela.

Si le client ajoute une nouvelle grande histoire de haute priorité, que faites-vous? L'accepter et l'ajouter au sprint? Re-planifier? Changer le tableau de gravure? Mordre la balle? Non. Vous supprimez d'autres histoires car vous n'en avez pas la capacité.

Ce n'est pas différent - les circonstances ont changé et votre équipe ne peut plus s'engager sur la portée initiale.

— Oded
source

Nous avons déjà fait la réunion du plan de sprint. J'ai pensé qu'une fois la réunion du plan terminée, tout est gravé dans le marbre. Oui Non?

— janetsmith

@janetsmith - Rien n'est "gravé dans le marbre". Que se passerait-il s'il y avait une épidémie de grippe et que vous perdiez tous les développeurs?

— Odé

Est-ce à dire que je dois recommencer une session de planification de sprint? La session de planification de sprint semble assez impliquante.

— janetsmith

@janetsmith - Non, vous continuez simplement à supprimer les éléments qui ont la priorité la plus basse dans le sprint, jusqu'à ce que vous puissiez réaliser les histoires restantes avec la capacité que vous avez maintenant.

— Oded

2

Non. Vous ne demandez pas aux gens de travailler des heures supplémentaires. Voulez-vous plus de partir?
Qu'est-ce qu'un tableau de burn-down? C'est le graphique des points terminés par rapport au graphique des points que vous devez terminer avant la date limite. Alors pourquoi le changer? Continuez à représenter graphiquement et vous verrez l'effet que la perte d'un développeur a et peut tenir le client informé.
Le client peut utiliser ces informations pour réduire ou prolonger le délai. Ce qu'ils ne peuvent pas faire, c'est dire qu'ils veulent plus de ressources. Les ressources viennent quand vous les trouvez et disparaissent quand elles en ont envie et forcer rapidement la mauvaise personne ne résoudra pas votre problème. Cela est particulièrement vrai à l'approche de l'échéance.
Si vous allez embaucher quelqu'un, attendez-vous à ce que cela prenne aussi du temps, donc le coût sera supérieur à une heure de développeur et le gain ne sera pas immédiat.
Faites remarquer à l'entreprise que s'ils ne veulent pas que cela se produise à l'avenir, ils doivent embaucher trop de ressources au début du projet et rester en avance sur l'exigence attendue jusqu'à la fin de la date limite (quand, parce qu'ils sont à l'avance, ils peuvent perdre la moitié de l'équipe et ne pas remplacer à un moment où les développeurs restants n'ont pas besoin de passer du temps à s'entraîner).

Avertissement: Tout cela s'accompagne d'une mise en garde, "dans un monde parfait." Maintenant, approchez-vous le plus possible et tout ira bien.

— pdr
source

2

Si une échéance importante approche, il est normal à mon humble avis de demander aux membres de l'équipe s'ils sont prêts à consacrer quelques heures supplémentaires. C'est généralement bien tant qu'il s'agit d'un événement inhabituel, d'un incident exceptionnel, et que vous DEMANDEZ à l'équipe de le faire, et non de le DIRE. La plupart du temps, vous serez surpris de voir comment l'équipe va fièrement intervenir et livrer. La mise en garde est qu'ils doivent vous respecter et sentir que vous les respectez à leur tour.

— maple_shaft

2

Si vous avez besoin de consacrer des heures supplémentaires, vous vous êtes trop engagé ou quelque chose entre les deux l'a empêché de terminer le travail que l'équipe a également engagé. Dans les deux cas, vous devez informer le propriétaire du produit à temps afin qu'il puisse prendre les mesures appropriées (par exemple, supprimer certaines histoires). Scrum dit que l'équipe devrait travailler à un rythme soutenable de 7 à 8 heures par jour, vous ne devriez pas travailler des heures supplémentaires.

— Bart

4

@maple_shaft: Vous me demandez de faire des heures supplémentaires parce que j'ai foiré, ou même un de mes coéquipiers a foiré (et je ne peux pas tout faire lui-même cette fois), ou parce que j'ai trop promis, je le ferai dans un battement de coeur. Demandez-moi de le faire parce que la direction n'a pas tenu compte de la possibilité que quelqu'un parte, je ne le prendrai pas si bien.

— pdr

0

En tant que membre de l'équipe ou maître de mêlée, ne faites rien que d'informer le propriétaire du produit de la situation. Votre équipe s'est déjà engagée à utiliser un certain nombre d'histoires d'utilisateurs en fonction de la capacité attendue. Quelque chose de grave s'est produit et l'un des membres de votre équipe ne peut pas continuer au sprint en raison de son état de santé. Cela peut arriver et personne ne peut lui en vouloir ni à vous.

C'est au propriétaire du produit de décider quoi faire ensuite. Il est évident que vous ne réaliserez probablement pas ce que vous avez commis. Le propriétaire du produit peut laisser le sprint continuer tel quel afin que vous terminiez autant de user stories que vous le pouvez sans manquer de membre de l'équipe et des heures supplémentaires déraisonnables ou elle peut décider d'arrêter le sprint et d'en commencer un nouveau - mais ce serait assez drastique.

Le détartrage est dangereux. Le sprint devrait être une zone de sécurité pour l'équipe. Cela fait partie des principes agiles d'autonomiser les gens. L'équipe est habilitée à prendre un engagement. Une fois que vous autorisez le changement d'engagement pendant le sprint, cela peut bientôt devenir une pratique courante et tout le point d'engagement et la zone de sécurité disparaîtront. Vous obtiendrez le chaos avec une cible de sprint en constante évolution.

— Ladislav Mrnka
source

-1

Réalisez que la mêlée a de la vitesse pour aider à gérer cela.

Je crois comprendre que votre vitesse s'adaptera à la nouvelle équipe au fil du temps. Certains endroits permettent même d'estimer une diminution de la vélocité, pour aider à mieux gérer le départ ou même les vacances des membres de l'équipe.

— tylermac
source

1

Comme ci comme ça. Certains endroits permettent même une diminution de la vitesse. Comme ils sont généreux. Saviez-vous que c'est moi qui permet au ciel d'être bleu?

— ThomasX

-2

Analysez l'impact sur le sprint global. Identifier une solution alternative / contourner. Discutez avec le propriétaire du produit pour déplacer les histoires d'utilisateurs moins prioritaires / importantes au prochain sprint. Apportez des ressources supplémentaires pour ce sprint ou le futur sprint.

— Pani
source