D’abord, on ajoute « juste » un développeur. Puis un Business Analyst. Puis un autre développeur. Puis encore un autre. Les rituels s’allongent, les décisions se complexifient, jusqu’au moment fatidique, où l’équipe agile bascule du mode ‘Startup Nation’ au ‘Corporate Survival’. Le sprint planning ressemble à une partie de monopoly sans fin, le daily stand-up est précédé d’un pré-daily technique et la sprint review se transforme en mini-conférence TED.
C’est exactement ce que Pauline, développeuse front-end, est en train de découvrir. Depuis qu’elle a rejoint sa nouvelle équipe, tout semble avancer au ralenti.
La réalité d’une équipe XXL
Ce matin-là, pendant le daily stand-up, le constat est frappant. Pauline remarque que les trois développeurs hors site n’ont pas pris la parole depuis plus d’une semaine. Sur Teams, 15 personnes sont connectées, mais seulement 7 caméras allumées. Entre les discussions qui se chevauchent, les phrases coupées par des “Tu es en mute !” et les silences gênants, Pauline ne peut s’empêcher de penser que, paradoxalement, plus on est nombreux, moins on arrive à se parler.
« On est combien dans l’équipe au juste ? » lance-t-elle à Jean-Luc, le Product Owner.
Ce dernier répond avec un sourire désinvolte : « On est une équipe XXL, Pauline. C’est comme un avion gros-porteur : plus on embarque de passagers, mieux ça marche. »
Pauline fronce les sourcils : « Mais on n’est pas un avion, Jean-Luc. Et là, ça ne marche pas du tout. »
John, le développeur back-end, tente un peu d’ironie : « Moi, ça me fait penser à une réécriture de Game of Thrones, avec des personnages qu’on ne voit jamais, mais qui, apparemment, ont un rôle crucial à jouer… jusqu’au moment où tout part en vrille. »
Pauline reste dubitative. Les problèmes dépassent la simple question de présence. Jean-Luc, surchargé, délègue de plus en plus de responsabilités à Marc, le responsable technique. Et Marc gère cela d’une main de fer, multipliant les rituels de microgestion sous couvert de “stratégie alignée”. Chaque réunion ressemble de plus en plus à une scène d’interrogatoire. Il ne manque plus que la lampe braquée sur le visage et la musique dramatique pour qu’on se croie dans un mauvaise série Netflix…
« Pauline, pourquoi l’API n’est pas encore prête ? »
« Parce que les données de John ne remontent pas. »
« John, c’est quoi le problème ? »
« Ce n’est pas un problème, Marc, c’est un travail en cours. »
Le ton pince-sans-rire de John ne suffit pas à apaiser les tensions. Résultat ? L’équipe ressemble plus à un groupe de sous-traitants qu’à une véritable équipe Agile. Les frustrations montent, et les résultats stagnent.
Scinder pour mieux régner ?
Lors d’une rétrospective tendue, Pauline ose poser une question que tout le monde évitait jusque-là : « Et si notre problème venait tout simplement de la taille de l’équipe ? »
Jean-Luc, fidèle à son style, réplique avec un soupçon d’exaspération : « Ah, facile de blâmer la taille. Une grande équipe, c’est une grande richesse aussi. Pourquoi tout casser pour quelques problèmes de coordination ? »
Thomas, le Scrum Master, intervient avec calme : « Jean-Luc, ce n’est pas une question de casser quoi que ce soit. On s’épuise à gérer des malentendus, et le produit en souffre. Les utilisateurs attendent des solutions concrètes, et là, on s’enlise. Il est temps d’essayer autre chose. »
Hugo, l’UX Designer, est invité à partager ses méthodes de facilitation et de Design Thinking. Après une analyse rapide de la situation, il propose un atelier de Card Sorting pour clarifier les responsabilités et impliquer tout le monde dans une réflexion structurée.
Pendant l’atelier, une réalité frappante émerge : « On a tellement de chevauchements dans les responsabilités qu’on ne sait même plus qui doit faire quoi », résume Pauline avec franchise.
À partir de ce constat, Thomas propose une solution audacieuse : « Divisons l’équipe en deux groupes pour un sprint. Chaque groupe aura des objectifs précis, des rôles bien définis, et des interactions limitées pour maximiser l’efficacité. À la fin des deux semaines, on analysera ensemble les résultats. »
Jean-Luc, sceptique, finit par céder sous l’insistance collective : « Très bien, mais je veux des retours précis et chiffrés. Essayons, mais ne traînons pas. »
Les premiers résultats
Dès la fin du sprint suivant, les bénéfices se font sentir :
- Les daily meetings sont enfin pertinents, avec des échanges ciblés sur les priorités.
- Les malentendus diminuent, grâce à des interactions plus ciblées.
- Les utilisateurs perçoivent une nette amélioration, les fonctionnalités livrées étant enfin alignées sur leurs besoins.
Et six mois plus tard ?
Devant ces premiers succès, l’équipe a décidé de pérenniser ce mode de fonctionnement en adoptant le framework Scrum of Scrums.
Reconnu pour son efficacité, sa fiabilité et ses coûts limités, ce framework offre une structure claire pour coordonner plusieurs équipes tout en préservant leur autonomie. Chaque équipe garde son rythme et ses priorités, mais un point de synchronisation hebdomadaire permet de gérer les interdépendances et de garantir une vision stratégique commune.
Jean-Luc, initialement sceptique, ne cache plus son enthousiasme : « C’est vraiment impressionnant. Non seulement on avance plus vite, mais surtout, on livre des solutions qui répondent enfin aux attentes des utilisateurs. Et tout ça sans multiplier les réunions interminables. »
Pauline, taquine, ajoute : « Tu vois, Jean-Luc, on avait raison de tenter l’expérience. Une belle victoire pour l’intelligence collective, non ? ». Jean-Luc sourit : « Bon, vous avez raison. Mais souvenez-vous : un peu de tension, ça garde l’équipe alerte. Et puis, avouez que vous adorez ça ! »
Les leçons à retenir
- Scinder pour mieux avancer. Une équipe trop grande complique les interactions. Scinder permet de restaurer la fluidité.
- Expérimenter pour progresser. Tester une nouvelle organisation sur un sprint grâce au principe Build/Mesure/Learn aide à valider ou ajuster rapidement les stratégies.
- Clarifier les responsabilités. Organiser un atelier de Card Sorting aide à visualiser les tâches, identifier les chevauchements et éliminer les zones floues.
- Adopter un framework structurant. Utiliser le Scrum of Scrums garantit une coordination efficace entre plusieurs équipes tout en respectant leur autonomie.
- Renforcer l’intelligence collective. Impliquer chaque membre dans les décisions renforce la collaboration, la créativité et l’engagement autour des objectifs communs.
Et vous, comment faites-vous ?
Cet article n’est qu’un aperçu des défis que peuvent poser les équipes trop nombreuses en Agile. Mais qu’en est-il de votre expérience ? Avez-vous déjà expérimenté des situations similaires ? Quels ajustements ou solutions avez-vous mis en place pour retrouver fluidité et efficacité ?
Je serais ravi de lire vos idées et retours dans les commentaires. Partageons nos bonnes pratiques pour enrichir nos approches collectives !
