Trop grand pour évoluer – Guide de la taille optimale de l'équipe Scrum

Écoutez la version audio de cet article

Que vous travailliez dans une petite startup ou sur un nouveau produit dans une grande entreprise, vous arriverez probablement à un point où vous aurez trop de personnes dans une même équipe. Identifier les signes dès le début vous évitera d'atteindre l'étape la plus inefficace de l'équipe.

Chaque produit est différent et les équipes qui y travaillent le sont aussi. Ainsi, diviser une équipe vous obligera également à prendre des décisions qui reflètent votre situation. Certaines choses à considérer sont :

• Comment maintenir l'intégrité du savoir-faire lorsque les coéquipiers ne travaillent plus ensemble
• Devriez-vous diviser les fonctions (par exemple, équipes front-end et back-end) ?
• Les nouvelles équipes devraient-elles avoir des backlogs séparés ?
• L'équipe de gestion des produits doit-elle s'agrandir en conséquence ?

Quand devriez-vous commencer à créer une deuxième équipe ?

L'indication la plus évidente pour commencer à penser à une scission d'équipe ou à l'ajout d'une nouvelle équipe est lorsque votre budget augmente. Cela peut se produire lors d'un nouveau cycle d'investissement dans une startup ou de nouveaux objectifs pour votre produit dans une entreprise. Si l'augmentation du budget est si importante que votre équipe grandit 3 fois ou plus, il est alors évident que vous devrez diviser votre équipe actuelle pour répartir le savoir-faire. Cependant, les décisions ne deviennent pas aussi claires lorsque l'augmentation du budget est progressive et que vous finissez par ajouter quelques nouvelles personnes à la liste. Si, par exemple, vous envisagez de faire passer votre équipe de 7 à 11 personnes, cela nécessite-t-il une séparation ? Agile favorise les petites équipes mais il favorise également les individus et les interactions sur les processus et les outils. Avoir deux équipes ou plus crée inévitablement plus de processus pour pouvoir travailler en synchronisation.

Que disent les experts ?

Jeff Bezos, le fondateur d'Amazon, utilise la règle des deux pizzas pour les réunions et les équipes. Cela signifie que chacun ne devrait avoir que le nombre de personnes que deux pizzas peuvent nourrir pendant le déjeuner.

Le Scrum Guide suggère d'avoir entre trois et neuf membres de l'équipe qui exécutent réellement le backlog de sprint. Cela signifie que vous n'incluriez pas le propriétaire du produit ou le scrum master dans le total à moins que l'un d'eux ne mette en œuvre les éléments du backlog de sprint.

Ces chiffres semblent avoir un sens intuitif, mais il y a aussi des calculs derrière cela. Si vous pensez à une équipe, chaque personne est comme un nœud et se connecte à d'autres nœuds. Ce sont les relations interpersonnelles entre coéquipiers. Ils peuvent être amicaux, compétitifs, méchants ou attentionnés. Quelle que soit la relation entre deux personnes, il s'agit toujours d'un lien qui nécessite une certaine capacité mentale de la part de chacun. Au fur et à mesure qu'une équipe grandit, le nombre de ces liens n'augmente pas de manière linéaire. La formule des liens entre nœuds est \(n(n-1)/2\). Voici le diagramme de croissance des liens :

Le graphique illustre clairement d'un point de vue mathématique pourquoi les équipes fonctionnent plus efficacement lorsqu'elles ne sont pas trop grandes. Si on prend les 3 à 9 membres de l'équipe suggérés par le Scrum Guide, on se retrouve avec entre 3 et 36 liens. Si nous devenions 15 personnes, nous aurions plus de 100 liens. Une telle équipe ne pouvait fonctionner efficacement que si ses tâches étaient très bien définies et se chevauchaient rarement ou s'il existait des sous-groupes non officiels. Ni l'un ni l'autre n'est le cas ou souhaité lorsque l'on travaille selon les principes Agiles.

Signes que l'équipe devient trop grande

Mêlée quotidienne

Parfois appelée stand-up quotidien, la mêlée quotidienne est une réunion de toute l'équipe pour discuter des progrès et des obstacles du sprint. Le Scrum Guide suggère de les chronométrer à 15 minutes et c'est un bon test décisif pour la taille de l'équipe. Si vous commencez à remarquer que votre équipe dépasse la barre des 15 minutes, cela peut indiquer l'une des deux choses suivantes :

• Les mêlées quotidiennes ne sont pas efficaces. Les gens entrent dans trop de détails. Ou il n'y a pas d'ordre de parole clair et il faut du temps aux coéquipiers pour s'exprimer. Peut-être que le propriétaire du produit ou le scrum master utilise la mêlée quotidienne comme une opportunité pour fournir diverses mises à jour non liées au sprint.
• L'équipe est trop grande. Si les mêlées quotidiennes sont efficaces, mais que vous dépassez toujours les 15 minutes, alors vous pourriez simplement avoir trop de personnes dans l'équipe. Vous devriez également commencer à remarquer que les gens se désintéressent parce qu'il y a une limite à la quantité d'informations qu'une personne peut accepter. Si trop de personnes fournissent des mises à jour, il devient difficile de suivre les progrès de chacun et de comprendre le statut de l'équipe. . Cela incite les gens à se replier sur eux-mêmes et à ne réfléchir qu'à leurs progrès plutôt que de chercher des occasions d'aider les autres.

Préparation et planification de sprint

Le toilettage et la planification de sprint sont des activités liées à la décomposition des user stories et à l'estimation de leur délai de livraison ou de leur taille. Bien qu'avoir plus de personnes puisse aider l'équipe à prendre de meilleures décisions, avoir trop de personnes peut conduire l'équipe à une impasse. Il y a toujours différentes façons d'accomplir la même tâche et le nombre d'arguments de chaque côté augmente avec le nombre de personnes dans l'équipe.

Comme pour la mêlée quotidienne, ne confondez pas une session de planification inefficace avec une équipe trop grande. En fin de compte, c'est le travail du Scrum Master de faire en sorte que les cérémonies Scrum soient efficientes et efficaces.

Rétrospective

Lors d'une rétrospective, les membres de l'équipe peuvent résoudre des arguments ou des conflits et trouver des moyens d'améliorer leur processus de travail. Les rétrospectives nous enseignent l'art du compromis car elles nous font rechercher un terrain d'entente entre différentes parties. Une équipe est aussi puissante que ses membres sont prêts à faire des compromis sur leurs différences.

Cependant, comme pour la planification de sprint, trop de membres d'équipe créent trop de liens, qui sont tous des points de conflit potentiels. Commencez à remarquer si vous trouvez de moins en moins de terrain d'entente lors des rétrospectives. Cela peut être un signe que l'équipe est trop grande et gagnerait à être divisée.

Comment diviser l'équipe

À première vue, diviser l'équipe est une tâche relativement facile. Divisez les membres de l'équipe en deux groupes, assurez-vous que chacun a des personnes ayant une expérience similaire et définissez les objectifs des nouvelles équipes. Cependant, il y a pas mal de choses à considérer qui pourraient avoir un impact important sur le succès futur des nouvelles équipes.

Moral de l'équipe

L'une des choses les plus importantes à garder à l'esprit est probablement le moral de l'équipe. En fin de compte, ce sont les gens de l'équipe qui devront travailler dans la nouvelle composition. Si l'équipe est mature en termes de principes Agiles, elle devrait être capable de faire la séparation elle-même. C'est le résultat le plus souhaitable parce que les membres de l'équipe connaissent le mieux leurs relations internes - qui travaille le mieux avec qui et qui pourrait bénéficier d'être dans des équipes distinctes.

Équipes inter-fonctionnelles

Scrum promeut des équipes interfonctionnelles "avec toutes les compétences en équipe nécessaires pour créer un incrément de produit". Cela est vrai lors de la mise à l'échelle de deux équipes ou plus. Pour de nombreux développeurs, surtout s'ils débutent avec Agile, la tendance naturelle est de penser parallèlement aux lignes techniques. Par exemple, les équipes souhaitent souvent se diviser en équipes back-end et front-end. Cela peut avoir du sens dans de rares occasions, mais en tant que chef de produit, vous devriez le déconseiller la plupart du temps. Une équipe pleine de front-enders n'est pas en mesure de livrer un incrément de produit par elle-même et va naturellement commencer à penser davantage à la capacité technique, qui est ce qui les unit. Au lieu de cela, ils devraient se concentrer sur le client et sur la manière de satisfaire ses besoins.

Une autre considération intéressante est les rôles non liés au développement dans l'équipe. Dans diverses situations, une équipe peut inclure un concepteur, un analyste commercial ou un spécialiste de l'assurance qualité. Une fois que vous avez divisé une équipe, surtout si vous n'embauchez pas trop de nouvelles personnes, un dilemme se pose concernant ce qu'il faut faire avec ces rôles. Doivent-ils partager leur temps entre les équipes ? Devriez-vous embaucher de nouvelles personnes, qui seraient dédiées à une seule équipe ? Doit-il travailler avec les équipes de développement ou faire partie de l'équipe produit ?

Il n'y a vraiment pas de bon conseil unique pour cela car chaque produit est si différent. Il est préférable de prendre ces décisions avec l'équipe, en gardant à l'esprit que vous devrez peut-être corriger le parcours en cours de route.

Les équipes devraient-elles avoir des backlogs séparés ?

Si une équipe est divisée, la question naturelle est de savoir si elle doit travailler sur le même backlog ou en avoir des séparés. Nous pouvons consulter le Scaled Agile Framework pour obtenir des conseils.

Scrum@Scale

Scrum@Scale est une méthodologie développée par le créateur du Scrum Guide. Scrum@Scale n'est pas très prescriptif et ne décrit pas spécifiquement comment gérer les backlogs de produit. Il note cependant deux points :

• Le processus au niveau de l'équipe est le même que celui décrit dans le Guide Scrum.
• Les Product Owners forment une équipe de Product Owners, où ils créent un seul backlog unifié. Ceci est fait pour éviter la duplication du travail et pour créer de la visibilité au sein de l'entreprise. Dans le même temps, les équipes ont leurs backlogs séparés qui alimentent les éléments du backlog unifié.

Donc, en substance, Scrum@Scale représente les nouvelles équipes avec leurs propres PO et backlogs respectifs. Il ajoute juste quelques structures supplémentaires pour coordonner le travail entre les équipes. Scrum@Scale fonctionne mieux avec plusieurs, dizaines ou centaines d'équipes, mais il peut fournir des informations précieuses même si vous travaillez avec deux équipes.

Scrum à grande échelle (LeSS)

LeSS promeut une approche intéressante du backlog produit. Dans LeSS, un Product Owner travaille avec deux à huit équipes. Il peut sembler impossible qu'un PO travaille avec autant d'équipes. La philosophie de LeSS est que le PO travaille à un niveau abstrait et délègue les responsabilités de raffinement des éléments du backlog produit aux équipes. Dans ce cas, les équipes de développement interfonctionnelles doivent également inclure une connaissance du domaine métier afin de pouvoir fournir un incrément de produit. Dans LeSS, il n'y a qu'un seul backlog.

Comment se tenir au courant

Pour un chef de produit, plusieurs équipes signifient plus de travail pour suivre la progression et répondre aux requêtes.

Prioriser les réunions

Si vous assistiez aux mêlées quotidiennes d'une seule équipe, continuer cette habitude sera très probablement improductif. Considérez les mêlées quotidiennes comme une chance de prendre le pouls des équipes et de leur rappeler que vous êtes disponible pour des discussions.

Votre participation aux sessions de planification de sprint dépendra de la maturité des équipes. Si les équipes comprennent de nombreux nouveaux visages ou si elles n'ont pas travaillé avec Agile depuis longtemps, des conseils de votre part seront nécessaires. Même si vous vous sentez confiant de laisser l'équipe planifier sans votre présence, assurez-vous d'être disponible pour passer ou discuter avec l'équipe pendant leurs planifications si des questions se posent.

Les revues de sprint devront rester votre priorité absolue et toutes doivent être suivies. Les revues de sprint sont une chance d'obtenir des commentaires de première main de toutes les parties prenantes présentes et de l'équipe elle-même. C'est un moment où les hypothèses sont validées et il ne faut pas le manquer.

Engagez-vous davantage avec les Scrum Masters

Bien que vous réduisiez peut-être votre engagement avec certaines des cérémonies Scrum, vous devriez doubler votre partenariat avec le scrum master. Il pourrait y en avoir plus d'un maintenant après la scission de l'équipe, auquel cas vous devrez travailler en étroite collaboration avec chacun d'eux.

Assurez-vous que vous pouvez leur faire confiance pour donner une vision honnête des progrès de l'équipe et des problèmes qui surviennent pendant les sprints. Ces relations vous permettront de rester à jour sans avoir à vous engager dans toutes les cérémonies Scrum.

Présentation de Scrum de Scrums

Parfois appelée méta-mêlée, une mêlée de mêlées est une nouvelle cérémonie qui est généralement introduite à l'échelle des processus de mêlée. C'est une réplique de la mêlée quotidienne à un niveau supérieur. Chaque équipe désigne un ambassadeur, qui se réunit tous les jours à la mêlée des mêlées pour discuter des progrès et des obstacles. Cette cérémonie est également utilisée pour mettre en évidence les problèmes techniques inter-équipes qui pourraient devoir être résolus.

Envisagez d'élargir l'équipe produit

Si votre configuration Scrum nécessite que le chef de produit s'engage activement avec l'équipe, envisagez d'ajouter plus de personnes du côté produit. Il y a plusieurs façons d'aborder cela.

Chefs de produits juniors. Une voie consiste à assumer un rôle plus stratégique pour vous-même tout en ajoutant des chefs de produit juniors pour gérer certaines des tâches quotidiennes. Ils pourraient assumer certaines tâches telles que l'assurance qualité (QA), rédiger des spécifications pour les user stories ou créer des maquettes de haut niveau pour de nouvelles fonctionnalités.

Analystes d'affaires. Un autre moyen consiste à faire travailler un ou plusieurs analystes métier dans ou à côté des équipes. Le chef de produit peut travailler avec des analystes commerciaux pour identifier les hypothèses du produit, puis laisser les analystes commerciaux trouver des moyens de les valider par le biais de recherches ou de nouvelles fonctionnalités.

Conclusion

Au fur et à mesure que votre équipe grandit, vous commencerez probablement à remarquer certains signes indiquant qu'elle devient trop grande, en particulier dans :

• Mêlée quotidienne. Si vous dépassez le délai de 15 minutes pendant les mêlées quotidiennes et que vous voyez que les gens commencent à se désintéresser.
• Planification des sprints. Si vous vous retrouvez de plus en plus souvent dans des impasses lors de la planification de sprint.
• Rétrospective. Si vous commencez à remarquer qu'il est de plus en plus difficile de trouver des compromis lors des rétrospectives.

Tout cela indique que vous devrez peut-être diviser l'équipe. Séparer une équipe est apparemment une tâche facile, mais cela a aussi des conséquences durables et chaque chef de produit doit prendre en compte quelques éléments pour le faire :

• Moral de l'équipe. Idéalement, vous devriez laisser l'équipe décider comment elle souhaite se séparer afin de minimiser le nombre de bonnes relations de travail abandonnées.
• Équipes inter-fonctionnelles. Les équipes doivent avoir toutes les compétences nécessaires pour créer un incrément de produit.
• Carnet de produit. Décidez si vos équipes auront un backlog séparé ou un seul backlog unifié.

Le suivi de deux équipes ou plus vous obligera à établir des priorités. Un chef de produit efficace doit planifier comment il se tiendra au courant des nouvelles équipes :

• Privilégier les rencontres. Réfléchissez à quelles cérémonies Agiles valent votre temps et lesquelles peuvent être ignorées.
• S'engager avec les maîtres de mêlée. Utilisez des scrum masters comme mandataires de votre équipe et collectez des informations auprès d'eux.
• Développez l'équipe produit. Ajoutez des personnes pour travailler avec vous et vous aider dans les tâches répétitives quotidiennes ou effectuer des recherches sur les utilisateurs et des analyses de marché.

En utilisant ces suggestions, vous devriez être en mesure d'avoir une équipe propre. Si vos équipes continuent de croître et que vous en ajouterez encore plus à l'avenir, vous devriez en savoir plus sur Scaled Agile Framework, qui fournit des suggestions de structure et de processus pour Agile à grande échelle.