Et non! Augmenter la taille des équipes ne permet pas forcément de délivrer plus.
John : « Pour finir à temps, il faudrait que les 2 développeurs travaillent à 150% pendant un mois »
Marc : « Il y a plus simple, prends un développeur en plus ! »
Une idée régulièrement soutenue pour réduire les délais de livraison est d’augmenter la taille de l’équipe de développement. En réalité, ça n'est pas forcément aussi simple !
Nous avons observé que l'arrivée d'un nouveau développeur dans une équipe de 2 personnes n'a, contre toute attente, aucun impact sur la vélocité du premier sprint. A terme, la vélocité de l’équipe n'augmente que d'environ 35%. On se trouve bien loin des 50% que les mathématiques nous présentaient !
Ce phénomène est d'autant plus marqué que la taille de l'équipe augmente. Cette dégradation de la productivité lorsque l'on est en groupe n'est pas propre au développement. Elle a été théorisée en 1882 par Maximilien Ringelamnn sous la nom de "paresse sociale". Selon cette théorie, toute personne a tendance à fournir moins d'efforts lorsqu'elle est en groupe, se reposant en quelque sorte sur ses pairs. A partir de 8 personnes, chaque individu fournirait un effort 2 fois inférieur à celui qu'il fournirait s'il était seul !
Revenons au développement.
La paresse sociale n'explique pas à elle seule la baisse de productivité consécutive à l'agrandissement de l'équipe. Au début du moins, dans la mesure où la productivité des développeurs passant du temps à faire monter en connaissances les nouveaux se trouve automatiquement dégradée.
Afin de minimiser au mieux l’impact que peut avoir l’arrivée d’un développeur sur la productivité d’une équipe, plusieurs actions peuvent être entreprises en amont. Le product owner doit planifier une présentation du produit dans son ensemble, ses enjeux et son fonctionnel, ainsi que les tâches de mise en place d’un environnement local de développement. Le PO doit aussi prioriser des correctifs ou stories permettant d’appréhender plus facilement le fonctionnel de l’application. Il faut, par ailleurs, favoriser les tâches propices au pair programming afin que le nouveau développeur puisse bénéficier au mieux de l’expérience de l‘équipe. Pour toutes ces tâches, il est nécessaire qu’un développeur de l’équipe soit présent pour aider à la montée en compétence.
En conclusion, gardez en tête que l'arrivée d'un nouveau développeur se prépare et que si la méthode Scrum recommande que la taille de l’équipe ne dépasse pas 7 développeurs ce n'est pas par hasard !
(crédit photo)
Copier le lien
