Scrum Forum

L’empirisme affirme que la connaissance provient de l’expérience et de la prise de décisions basées sur ce qui est connu.

Avoir plus de neuf membres nécessite trop de coordination. Les grandes équipes de développement génèrent trop de complexité pour qu’un processus empirique puisse la gérer

Le guide Scrum cite ces problèmes de présence dans les équipes de plus de 9 membres. Ce sont des préoccupations, pas des points d’échec, et une équipe Scrum de plus de 15 membres peut fonctionner. Cependant, elle ne sera pas aussi efficace qu’une équipe de taille appropriée. L’idéal serait de les séparer en deux équipes, et de suivre le Guide Nexus pour étendre Scrum à plusieurs équipes. Il s’agit de la méthode Scrum.org de mise à l’échelle de Scrum. Vous pourriez également examiner SAFe, comme une deuxième méthode de mise à l’échelle agile.

Le plus gros problème que vous trouverez n’est probablement pas la main-d’œuvre, mais les événements. Garder un temps de Scrum quotidien boxé à 15 minutes peut être un défi avec 7 personnes, et doubler cette taille d’équipe rend les choses beaucoup plus difficiles. L’expansion de la boîte de temps est un non-go (après 15 minutes, vous commencez à perdre les avantages d’une réunion « stand up »), et vous allez devoir mieux préparer les autres événements en clarifiant les choses à l’avance.

Comme je le comprends, votre travail en tant que Scrum Master dans ce scénario devient plus difficile, mais pas impossible. Vous pouvez avoir une équipe Scrum de 15 personnes, mais comme les événements sont basés sur la durée du sprint et non sur la taille de l’équipe, vous vous retrouverez moins dans le rôle de serviteur et plus dans celui de leader. Vous devez vous concentrer davantage pour vous assurer que les choses sont faites efficacement, car vous avez moins de place (et moins de temps) dans votre emploi du temps comme marge d’erreur. Quelqu’un qui prend la tangente aura un impact plus profond sur une grande équipe que sur une petite.