18/03/2024
Dans un contexte Agile ou classique, on retrouve souvent des équipes qui dépassent la dizaine de membres. Fréquemment, ces équipes rencontrent des difficultés à produire une quantité optimale de valeur, et ce de manière efficace.
Dans la majorité des cas, peut-être le vôtre, cette équipe souffre d'obésité.
Je veux dire par là qu'elle est composée de trop de membres, ce qui en limite ses performances.
Je vous propose de voir ensemble comment diagnostiquer le problème et guérir votre obésité pour retrouver une taille saine et une dynamique performante !
Dans les projets où l’on retrouve le problème d’équipe trop grande, on peut constater, entre autres, les éléments suivants :
• Une trop grosse capacité à traiter les besoins d’évolution sur le produit, dépassant la limite gérable
• Le périmètre fonctionnel à couvrir est extrêmement large et devient difficilement appréhendable
• Le Product Backlog contient plusieurs produits, réduisant le focus
• Des difficultés de communication peuvent amener du travail fait en doublon ou inutile
Dans ces cas, l'un des premiers réflexes est d'ajouter des membres à l'équipe en pensant qu'ajouter une personne permettra d'augmenter la performance proportionnellement. Ce réflexe est hérité d’anciennes méthodes et n’est plus valable dans la plupart des environnements actuels. Le temps suivant son cours, la taille de l’équipe est rarement revue à la baisse, pérennisant les symptômes néfastes.
Pour vous aider à diagnostiquer ce problème dans votre équipe, ce serait trop facile de vous dire :
« Votre équipe a plus de 10 membres, elle est donc trop grande »
Le problème est plus complexe que cela. Une équipe de 20 membres peut produire de la valeur avec un minimum de déperdition alors qu'une équipe de 4 membres peut perdre énormément de productivité inutilement.
« La Scrum Team doit être suffisamment petite pour rester réactive et assez grande pour accomplir un travail significatif durant le Sprint, habituellement dix personnes au plus »
On retrouve dans cette citation du Scrum Guide 2020 la consigne donnant les critères de décision pour une taille d’équipe Scrum optimale – valable aussi dans un contexte non Agile. Concentrons-nous sur la taille maximale habituelle. C’est dans ce dernier mot qu’est toute la nuance.
Aucun contexte n’étant généralisable, on doit donc se pencher sur la question plus en profondeur pour déterminer si votre équipe dépasse la taille maximale que votre contexte permette.
Il est difficile, voire impossible, d’appliquer le cadre Scrum qualitativement dans un contexte d’équipe volumineuse, car cela réduit la transparence, rend difficile l’inspection et rend laborieuse l’adaptation.
Dans cette infographie, on illustre les différents canaux de communication entre les membres d’une équipe. Vous remarquerez que plus il y a de membres dans l’équipe, plus il y a de canaux de communication à entretenir. Pour une équipe de 3 personnes, nous n’avons que 3 canaux de communication et pour une équipe de 7, 21 canaux. On peut aussi considérer qu’une équipe de 20 personnes atteigne 190 canaux de communication.
Avec autant de canaux à entretenir, les bénéfices de l’intelligence collective sont donc réduits voire totalement perdus. Pour des équipes dont le nombre de membres dépasse la limite qu’elle peut supporter, le nombre de canaux de communication empêche cette dernière d’être de qualité.
Les réunions doivent être des moments utiles où l'équipe partage des informations et collabore. Mais elles peuvent facilement basculer dans l'inefficacité et donc la perte de valeur. C'est pour cela que nous allons naturellement chercher à optimiser ce temps.
Il existe plusieurs types de réunions à citer pour illustrer mon propos :
• Les réunions de présentation : un briefing ou une présentation
• Les réunions de partage : le Daily Scrum, où les participants partagent rapidement des informations
• Les réunions de collaboration : le Sprint Planning, l’Affinage ou la Sprint Retrospective.
Ce sont des sessions où les participants doivent collaborer pour produire un ou plusieurs éléments.
Pour le cas des réunions de présentation, elles sont plutôt adaptées au contexte d’une équipe trop grande. En effet, peu importe le nombre de participants, son efficacité et sa durée ne sont pas impactées. On peut aussi retrouver ce type de réunion sous la forme d’un briefing où un référent a une communication descendante. Dans des domaines complexes et chaotiques (comme le développement informatique), la collaboration est étroitement liée à la performance. Si cette forme de réunion est en trop grande proportion, l’équipe résoudra plus difficilement les problématiques, réagira moins rapidement aux changements et arrivera difficilement à obtenir une implication de tous les membres.
De ce qui est des réunions de partage, on peut remarquer qu’elles laissent peu de place aux participants pour réellement échanger. Dans une équipe problématique, le Daily Scrum se transforme en un rapport où les participants listent machinalement les éléments à partager et sont bridés dans leurs échanges pour que cela ne dure pas trop longtemps. Mais aussi, l’attention des participants se relâche vite et l’intérêt de ces réunions est donc perdu. Si on compte 2 minutes par prise de parole, on remarquera que le temps passé dans ce type de réunions est rapidement élevé.
Et pour finir, parlons du pire, les réunions de collaboration. Les Scrum Master ayant encadré une Sprint Retrospective à plus de 10 participants vous le diront : difficile d’être efficace et de tenir la timebox. Il en est de même pour des sessions de travail, d’Affinage ou des Sprint Planning. Dès qu’une collaboration est nécessaire, discuter et débattre à plus de 10 personnes est difficile et très chronophage.
On remarquera dans ces sessions que la parole est inégalement distribuée, où les plus extravertis vont beaucoup s’exprimer au détriment des introvertis. Le temps étant court, l’animateur ne pourra pas se permettre de distribuer la parole équitablement.
Dans certaines grosses équipes, la majorité des réunions et événements Scrum prennent la forme de réunions de présentation pour limiter la perte de temps. Dans cette situation, toute forme d’intelligence collective ou de collaboration est difficile malgré leur nécessité lors de ces événements, réduisant les bénéfices du travail en équipe. La prise de décision est donc inefficace vu qu’elle n’est pas prise par l’équipe au total, ralentissant encore plus ses performances.
Un Sprint Backlog volumineux a un niveau d’incertitude plus élevé, réduisant la fiabilité de l’engagement de l’équipe. En effet, plus le périmètre est large, plus le cerveau humain aura du mal à appréhender les éléments qui le composent.
Cet élément est doublement frustrant :
• Pour l’équipe qui va donner le meilleur d’elle-même pour essayer d’atteindre un objectif inatteignable
• Pour les parties prenantes (client ou sponsor) qui vont s’attendre, en regardant le Sprint Backlog, à avoir des fonctionnalités qui ne seront pas présentes lors de la Sprint Review
La taille importante du Sprint Backlog entraîne une autre conséquence au-delà des Sprints : la planification devient très difficile. Dans un Sprint Backlog, il est courant que des éléments (tickets,User Story, etc) se trouvent être plus complexes que prévu. Ces éléments imprévisibles créent une dérive au cours du Sprint. Avec un Sprint Backlog problématique cette dérive est difficile à gérer pour une équipe peu efficace dans sa collaboration.
Du côté des membres de l’équipe, un Sprint Backlog de taille importante va encourager les personnes à se spécialiser dans une compétence et à rester dans leur zone de confort. C’est pour cette raison que dans une grande équipe, on voit apparaître des personnes ayant un profil de compétences en T (T-shape skills). Lorsqu’il y a une baisse de charge de travail dans leur domaine, ces personnes se trouveront peu adaptables au sein de leur équipe.
En-dehors des réunions où l’équipe ne produit pas de valeur, on peut remarquer que l’efficacité d’une équipe trop grande est limitée. L’équipe peut faire du travail inutile, car elle a du mal à collaborer et à avoir conscience de ce que les autres font.
Par travail inutile, j’entends par exemple :
• Du travail en doublon par plusieurs membres de l’équipe
• Des ralentissements évitables avec une simple discussion (qui peut avoir lieu en Daily Scrum ou dans l’open space)
• Des changements de besoin qui transitent mal entre le PO et les membres de l’équipe
Avec cette quantité de temps perdu, les rouages de l’équipe se grippent et plus les membres sont nombreux, plus la valeur produite baisse au regard de sa capacité, comme illustré ci-dessous.
Le graphique ci-dessus est tiré de l’article Developing a model for team learning and success.
On remarque qu’à partir de 10 personnes, l’équipe perd définitivement en efficacité.
Ce graphe permet d’illustrer mon propos, mais est assez biaisé, car il représente seulement les équipes colocalisées, format d’équipe moins représenté depuis l’ère du télétravail.
Les organisations ont de plus en plus recours au distanciel avec le télétravail.
Le distanciel impose des modes de communication peu riches – aussi appelés « froids » - qui ajoutent de la difficulté à collaborer aux éléments cités plus haut (cf. principe 6 du Manifeste Agile qui s’appuie sur l’efficacité de la communication par Allistair Cockburn). La colocalisation des membres de l’équipe, dans le même open space la majorité du temps, permet d’avoir des discussions informelles et une circulation de l’information optimale. Les échanges en face à face avec un tableau blanc sont la meilleure manière de communiquer au sein d’une équipe. Plus une équipe va avoir recours au distanciel, moins la communication va être de qualité. Mais aussi, les appels entre les membres d’équipe en distanciel sans les caméras retirent l’avantage de la communication non verbale. Donc, si une équipe est en majorité en distanciel, il est d’autant plus important de limiter sa taille.
Dans une équipe Scrum, les équipiers sont redevables de :
• Créer un Sprint Backlog
• Adhérer à la Definition of Done
• Adapter leur plan au jour le jour
• Se sentir mutuellement responsables en tant que professionnels
Dans des équipes hors contexte Agile, la responsabilisation des membres est aussi nécessaire et importante. On peut remarquer au sein des membres d’une équipe trop grande un sentiment de dévalorisation et d’ignorance de leur ressenti par l’organisation. En effet, plus il y a de membres dans une équipe, plus les responsabilités y sont diluées. Les personnes peuvent se diriger vers les tâches qu’elles auront envie de faire et non les plus prioritaires. Elles peuvent agir en pensant qu’un autre membre de l’équipe va prendre la responsabilité des tâches prioritaires. L’esprit d’équipe, l’engagement et la proactivité seront davantage présents dans une petite équipe, le nombre de personnes pouvant endosser une responsabilité étant réduit.
Réorganisez la grande équipe en plusieurs petites équipes cohérentes !
La solution peut paraître simple, mais vous devriez maintenant avoir plusieurs questions :
• Combien d’équipes créer ?
• Comment répartir les personnes ?
• Que faire du Product Backlog ?
Les conseils donnés ensuite sont valables dans des cas généraux. Dans la majorité des cas, l’accompagnement d’un coach Agile est nécessaire pour trouver la solution adaptée et pour conduire le changement. Klee Group peut vous accompagner dans cette démarche, n’hésitez pas à nous contacter.
Selon Scrum, il faut assez de personnes pour avoir les compétences nécessaires pour réaliser les items du Product Backlog et pas trop pour permettre une bonne collaboration et une communication ouverte. Mon conseil serait de prévoir le minimum de personnes par rapport au futur Product Backlog d’une équipe. Prenez aussi en compte vos contraintes comme le distanciel ou les personnalités des futurs équipiers. Ces contraintes pourraient limiter le nombre maximum optimal de personnes dans l’équipe. C’est donc pour cela qu’en prenant le minimum nécessaire pour constituer une équipe, la limite serait assez éloignée pour ne pas la franchir.
Il est très important d’impliquer les personnes pour constituer les équipes. Par cela, j’entends les aider à décider par eux-mêmes dans quelle équipe se répartir. Pour prendre leur décision, ils peuvent s’aider des personnes déjà présentes dans l’équipe, des compétences nécessaires à la réalisation complète d'un élément du backlog ou le contenu du Product Backlog. Cependant, la présence du Scrum Master et du Product Owner sont indispensables pour une équipe. Ils pourraient être assignés à plusieurs équipes en fonction du contexte.
Vous pourriez vous retrouver dans deux cas de figure : votre product backlog est constitué de plusieurs produits ou bien d’un seul. Dans le premier cas, le plus simple, vos produits sont assez indépendants pour être gérés par plusieurs équipes Scrum sans avoir besoin d’un cadre d’Agilité à l’échelle. La séparation de votre Product Backlog en plusieurs sera intuitive et la constitution des équipes en sera de même.
Dans le second cas qui est majoritaire, vous auriez besoin de mettre en place un cadre d’agilité à l’échelle pour pouvoir gérer plusieurs équipes travaillant sur un même produit. Pour définir quel cadre choisir, Il est fortement recommandé être accompagnés, car cela dépend fortement de votre contexte, de vos besoins et de votre budget. C’est une décision qui ne doit pas être prise à la légère et qui mérite un accompagnement par des experts en transformation agile afin de minimiser les risques d'échec.
N’oubliez pas que le problème de votre équipe peut être multifactoriel. En effet, réduire la taille de votre équipe pourrait résoudre certains problèmes, mais pas tous. C’est pour cela qu’il est nécessaire d’avoir une démarche d’introspection régulière pour continuer l’amélioration continue de votre projet.
