Agrandir une équipe de développement devrait permettre d’accélérer le travail, n’est-ce pas ? Plus de personnes, plus de mains, plus de vélocité — du moins, c’est ce qu’on pensait. Mais au lieu d’accélérer, on s’est heurté à un mur. Les demandes de fusion se sont accumulées, l’intégration des collègues s’est transformée en goulot d’étranglement et, soudainement, personne ne savait qui était responsable de quoi. Qu’est-ce qui a mal tourné ?
On pensait avoir la réponse : les topologies d’équipe. En structurant notre équipe avec des rôles clairement définis — guide, éclaireur et artisan — on s’attendait à un flux de travail fluide et efficace. Mais on s’est vite rendu compte qu’on avait mal compris le cadre de travail. Les topologies d’équipe n’ont rien à voir avec des rôles rigides, mais plutôt avec la structuration des équipes en vue d’un flux rapide, de l’adaptabilité et de la responsabilité partagée. Et on était sur le point de l’apprendre à nos dépens.
La topologie d’équipe est un cadre conçu pour optimiser la structure des équipes pour la livraison logicielle en privilégiant le flux rapide et en minimisant la charge cognitive. Elle introduit quatre types d’équipes clés : les équipes alignées sur le flux, les équipes facilitatrices, les équipes de sous-systèmes complexes et les équipes de plateformes. Les équipes alignées sur le flux se concentrent sur la valeur ajoutée pour le client, tandis que les équipes facilitatrices se consacrent à l’assistance en aidant à combler les lacunes dans les connaissances. Les équipes chargées des sous-systèmes complexes s’occupent des composants hautement spécialisés qui nécessitent une expertise approfondie, et les équipes chargées des plateformes créent des services partagés pour améliorer la productivité des développeurs et développeuses. Les organisations peuvent créer un environnement propice à l’efficacité et à la collaboration en alignant la structure des équipes sur ces principes.
Newforma est un chef de file des solutions technologiques de gestion de l’information de projet (PIM) pour l’industrie de l’architecture, de la construction, de l’ingénierie et des opérations (ACEO). Nexapp a collaboré avec l’une des équipes de Newforma dans le cadre d’un projet de codéveloppement visant à livrer rapidement des fonctionnalités critiques. Camil, le gestionnaire de produit, et le reste de l’équipe ont joué un rôle essentiel dans la mise en place de cette stratégie de collaboration et dans les ajustements ultérieurs, conduisant à un succès significatif.
Notre équipe a presque doublé de taille, passant d’un groupe soudé de cinq personnes à une équipe diversifiée de onze personnes, comprenant des spécialistes, des seniors, des juniors et des personnes animées par des ambitions de leadership, de produit et de coaching, ce qui a considérablement complexifié la coordination. Les principes de la topologie d’équipe ont permis d’améliorer l’efficacité de manière structurée tout en maintenant la charge cognitive à un niveau raisonnable.
On a structuré notre équipe autour de trois rôles — guide, éclaireur et artisan — en pensant que ça correspondait aux topologies d’équipe. Malheureusement, on avait mal compris le principe de base : les topologies d’équipe se concentrent sur la structure des équipes, et non sur des rôles individuels prédéfinis. Cette erreur est devenue évidente seulement lorsqu’on est passé à une plus grande équipe.
« Pour être honnête, c’était un ajustement, et ça ne marche pas pour tout le monde. Si vous êtes un gestionnaire qui fait de la microgestion, laissez tomber ! Si vous avez peu ou pas confiance dans les membres de l’équipe, n’essayez même pas ! »
— Camil Lafrenière, gestionnaire de produit chez Newforma
Au début, nos rôles semblaient correspondre aux quatre types d’équipes fondamentales :
👨🏫 Les guides ont pris en charge le mentorat et le partage des connaissances, comme les équipes facilitatrices, mais ils ont également pris en charge le développement des fonctionnalités, créant ainsi une division entre le coaching et l’exécution.
🔍 Les éclaireurs ont travaillé en amont pour affiner les fonctionnalités, un peu comme les équipes alignées sur le flux, mais leur rôle n’était pas tout à fait adapté puisqu’ils ne livraient pas directement.
🛠️ Les artisans se sont concentrés sur une implémentation de haute qualité, ce qui les rend similaires aux équipes alignées sur le flux ou aux équipes de sous-systèmes complexes, mais l’attribution rigide de ce rôle a conduit à des silos plutôt qu’à une capacité d’adaptation.
Alors qu’on pensait que cette approche structurée augmenterait la responsabilisation et l’efficacité, elle a en fait eu l’effet inverse. Au lieu de permettre aux gens d’assumer des responsabilités en fonction des besoins, elle les a contraints à rester dans des limites prédéfinies.
Cette prise de conscience a ouvert la voie à notre plus grand défi : augmenter la capacité tout en maintenant l’efficacité.
Avec une équipe presque deux fois plus grande et un ensemble de compétences de plus en plus diversifié, nos anciennes méthodes de travail n’étaient plus adaptées. Mais cette évolution semblait une opportunité excitante. Avec plus de membres dans l’équipe, on s’attendait à construire, tester et livrer des fonctionnalités plus rapidement. On a abordé la question avec confiance, persuadés qu’une stratégie bien définie maintiendrait l’efficacité. En définissant les rôles, les responsabilités et les flux de travail, on n’a pas anticipé le véritable défi. La croissance ne consistait pas seulement à ajouter des mains au projet, elle introduisait aussi de nouvelles couches de complexité. Au lieu d’avancer plus vite, on s’est heurté à des goulots d’étranglement inattendus, ce qui nous a fait repenser tout ce qu’on croyait savoir sur la livraison efficace d’un logiciel.
Au fil de notre expansion, on s’est rendu compte que la structuration du travail à travers des rôles rigides n’avait pas permis d’améliorer l’efficacité. Au contraire, elle créait des frictions. On avait mis l’accent sur l’optimisation du flux, la réduction de la charge cognitive et la structuration des interactions au sein de l’équipe, mais on avait plutôt imposé, à tort, des responsabilités rigides aux individus. Au lieu de renforcer l’équipe, la rigidité des rôles a limité la capacité d’adaptation. Les gens hésitaient à sortir des catégories qu’on leur avait attribuées, même lorsque c’était logique. Il a fallu du temps pour reconnaître que les responsabilités devaient émerger en fonction des besoins, plutôt que d’être dictées par des catégories prédéfinies. Une fois qu’on s’est éloigné des définitions statiques des rôles et qu’on a adopté l’appropriation adaptative, on a constaté une amélioration significative de la façon dont nos équipes collaboraient et produisaient des résultats.
L’expansion rapide de notre équipe nous confrontait à la réalité. L’intégration des collègues est devenue un processus chaotique qui interrompait le travail de plusieurs membres de l’équipe. Au lieu d’accélérer notre vélocité, on s’est retrouvé face à :
Des goulots d’étranglement au niveau de l’intégration — L’intégration de nouvelles personnes dans le développement ralentissait l’activité des membres de l’équipe en place.
Des demandes de fusion qui s’accumulent — Tout le monde supposait que « quelqu’un d’autre » les passerait en revue.
Les demandes de fusion ont commencé à s’accumuler et personne ne ressentait l’urgence de les réviser. Plus l’équipe grandissait, plus on pouvait facilement supposer que quelqu’un d’autre s’en chargerait. C’était un cas classique de l’effet « témoin », un phénomène psychologique selon lequel les gens sont moins enclins à agir lorsque la responsabilité est répartie au sein d’un groupe. Comme personne ne se sentait directement responsable, les revues de code étaient bloquées, ce qui entraînait des retards importants et ralentissait la mise en production des fonctionnalités.
Une confusion dans le partage des responsabilités — L’information n’était pas distribuée de manière efficace, provoquant un déséquilibre. En l’absence d’une appropriation claire des fonctionnalités, la duplication des efforts et la mauvaise communication affectaient l’équipe. On s’est vite rendu compte que l’augmentation du nombre de personnes au sein de l’équipe n’était pas synonyme d’une livraison logicielle plus rapide.
Il est devenu évident que le simple fait d’ajouter des personnes n’était pas la solution. L’équipe avait du mal à s’approprier le projet, à en assumer la responsabilité et à s’aligner, ce qui créait des goulots d’étranglement au lieu d’accélérer le processus. À ce stade, on a dû repenser notre approche. On s’est rendu compte que la restructuration en sous-équipes plus petites et plus ciblées apporterait la clarté et l’efficacité qui nous manquaient. On a amélioré la collaboration, la communication et les performances globales en permettant à tout le monde de contribuer aux tâches qui lui tiennent le plus à cœur. Pour s’assurer que chaque personne travaille sur ce qui la passionne le plus, on a organisé un atelier d’auto-sélection d’équipe, comme décrit dans l’article de blogue de mon collègue Maxime. Ce changement de paradigme a permis aux équipes de s’approprier pleinement des points spécifiques, ce qui a amélioré la communication, la responsabilisation et la livraison.
« Assurez-vous de ne pas considérer l’échec comme un problème, car vous et votre équipe allez échouer fréquemment. Il doit y avoir un environnement ouvert pour essayer, ce qui ne signifie pas sauter d’une falaise, mais la capacité de travailler avec l’équipe pour limiter les risques. »
— Camil Lafrenière, gestionnaire de produit chez Newforma
Même après la restructuration, il restait des défis à relever. On a constaté que les rôles devaient être fluides plutôt que fixes. Mais le rôle d’artisan avait ses inconvénients. Le terme donnait l’impression que les membres étaient des exécutants, qu’ils ne pouvaient pas prendre de responsabilités parce que ce n’était pas le rôle qui leur était attribué. On a aussi remarqué des problèmes similaires avec les autres rôles prédéfinis. Les guides, par exemple, avaient souvent du mal à trouver un équilibre entre le travail de mentorat et le travail de développement, ce qui les empêchait de s’engager pleinement dans l’un ou l’autre de ces rôles. Les éclaireurs, dont le rôle était d’affiner les fonctionnalités à venir, se sont retrouvés déconnectés de l’exécution, ce qui a limité leur impact. Ces divisions rigides ont involontairement découragé la flexibilité, rendant plus difficile pour les membres de l’équipe de sortir de leur rôle désigné en cas de besoin. Cette structure a eu pour effet négatif de freiner les membres de l’équipe dans l’accomplissement de tâches urgentes ou dans la résolution de problèmes inattendus qui ne correspondaient pas clairement à la catégorie qu’on leur avait attribuée.
La restructuration en équipes plus petites et autosélectionnées a permis d’améliorer l’alignement et la responsabilisation des équipes, de clarifier l’appropriation et de réduire les goulots d’étranglement. Toutefois, la communication et l’engagement plus larges entre les équipes sont restés un défi. Les initiatives interéquipes manquaient souvent d’élan et les rôles prédéfinis décourageaient encore les gens de sortir de leur domaine de compétence. Au fil du temps, on s’est aperçu que les moments les plus efficaces se produisaient lorsque les gens prenaient naturellement des responsabilités au-delà des rôles qu’on leur avait attribués. Cette évolution nous a fait repenser notre approche. Les rôles émergents, où les responsabilités évoluent en fonction des besoins, se sont avérés beaucoup plus efficaces pour favoriser la collaboration et l’adaptabilité. Cette approche a permis aux gens de choisir où contribuer, d’explorer de nouvelles initiatives et de développer des compétences en leadership sans que des rôles prédéfinis les contraignent. Elle a encouragé la résolution proactive des problèmes et a permis à l’équipe d’être plus flexible et résiliente.
Même avec nos équipes réduites, des problèmes inattendus venaient toujours interrompre les progrès. On s’est rendu compte de la nécessité de gérer efficacement les tâches non planifiées, d’améliorer la collaboration avec d’autres équipes et d’assurer la responsabilité des problèmes de production critiques. C’est ainsi qu’est née l’initiative du jongleur. Inspiré de l’expression « échapper la balle », nous avons conçu le rôle du jongleur pour assurer qu’aucune tâche critique n’était négligée, et donc qu’aucune balle n’était échappée.
Chaque semaine, une sous-équipe était désignée comme « l’équipe de jongleurs de la semaine ». La principale responsabilité du jongleur était de faciliter la gestion des tâches, en veillant à ce que les tâches non planifiées et les problèmes de production soient rapidement résolus grâce à la délégation et à la collaboration. Plutôt que d’accomplir eux-mêmes les tâches, les jongleurs veillent à ce qu’elles soient correctement attribuées et suivies, ce qui permet d’éviter les goulots d’étranglement et de maintenir l’efficacité de l’équipe.
Cette initiative a encouragé la collaboration transversale et favorisé une culture de la responsabilité partagée. Les membres de l’équipe ont davantage pris part au processus de développement en intervenant dans différents points en fonction de leurs intérêts et de l’évolution des besoins de l’équipe. La rotation du rôle de jongleur a permis à tout le monde d’être exposé à divers aspects du projet, ce qui a favorisé une meilleure compréhension et un plus grand engagement dans la réussite du produit.
L’initiative du jongleur a permis d’améliorer considérablement les temps de réponse, de réduire les goulots d’étranglement et de renforcer notre capacité à livrer des logiciels de qualité plus rapidement. Elle a permis aux gens de s’approprier des défis inattendus et a contribué à un environnement de travail plus flexible et plus réactif.
Au début, on s’est concentré sur la structure. Plus tard, on a appris que la capacité d’adaptation était plus importante. Au lieu de nous adapter aux nouveaux défis, on s’en tenait à nos rôles et processus prédéfinis, parfois à notre détriment. On a cessé de définir les rôles à l’avance et on a laissé les responsabilités émerger en fonction des besoins.
Grâce à des ateliers et à des activités de cohésion d’équipe, on a créé une culture dans laquelle tout le monde se sentait impliqué dans la mission du produit. On s’appropriait à la fois les succès et les échecs des fonctionnalités développées. Ce changement a aidé l’équipe à surmonter le premier dysfonctionnement d’une équipe : le manque de confiance. En favorisant la confiance et le partage de la responsabilité, notre équipe a pu livrer des logiciels plus rapidement sans compromettre la qualité. On a laissé les membres de l’équipe s’orienter vers des tâches qui les passionnaient, créant ainsi un sentiment d’appartenance commune. On a découvert que jouer un rôle était moins intéressant que d’assumer une responsabilité. Cette approche a permis de renforcer l’engagement personnel et le sens des responsabilités. L’hésitation à agir et la dépendance passive aux autres ont disparu.
« Un certain niveau de confiance est nécessaire. Ça ne veut pas dire qu’on a carte blanche. Il faut inspecter ses attentes. Dès le départ et au fil du temps, nous avons construit nos relations, ce qui s’est révélé très utile. La confiance est très importante dans ce domaine. »
— Camil Lafrenière, gestionnaire de produit chez Newforma
Augmenter la capacité, ce n’est pas seulement augmenter le nombre de personnes, c’est aussi travailler plus intelligemment. On a appris à nos dépens que les structures rigides tuent l’agilité. Une fois qu’on s’est débarrassé des rôles prédéfinis et qu’on a adopté l’appropriation flexible, on a enfin pu débloquer à la fois la vitesse et la qualité.
Plus de personnes n’éliminent pas les goulots d’étranglement, et plus de structure ne garantit pas la rapidité. La véritable clé consiste à donner aux équipes l’autonomie nécessaire pour façonner leur propre flux de travail.
Les topologies d’équipe nous ont permis de repenser notre approche. Cependant, ce ne sont pas les diagrammes ou les cadres de travail qui nous ont permis de progresser. On a fait confiance à notre équipe pour qu’elle s’adapte.
« Je n’ai jamais douté de nos capacités ni de celles de l’équipe. Quand ça a marché… c’est comme si les vannes s’étaient ouvertes ! En fin de compte, les résultats ont dépassé mes attentes, et celles de l’équipe et de la direction. C’était difficile à suivre, un problème très rare, mais agréable à résoudre. »
— Camil Lafrenière, gestionnaire de produit chez Newforma