10 prérequis à connaître avant de passer à l’échelle
Préparez-vous, car je vais vous dire la dure vérité sur la scalabilité.
Commençons par aller droit au but à propos de la montée en échelle en entreprise :
La plupart des tentatives de passage à l'échelle échouent.
Alors, quel est le secret ? Comment réussir à faire grandir une équipe, et pourquoi est-ce si difficile ?
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Si vous travaillez dans le développement logiciel depuis un certain temps, vous avez très probablement déjà vécu ce cauchemar :
- Le client se voit promettre un grand nombre de fonctionnalités dans un délai irréaliste (et personne n'a le courage de remettre ça en question).
- Plus tard, alors que l’échéance devient critique, quelqu’un en position de pouvoir décide d’ajouter plus d’équipes au problème pour réussir à tenir le délai.
- Les choses commencent alors à se dégrader.
Ça vous semble familier ?
Dans cet article, je vais vous expliquer comment éviter de revivre cette situation cauchemardesque (ou, si vous avez eu la chance de ne jamais y être confronté, comment l’éviter tout simplement).
Mon analyse ici provient de l’expérience de la croissance d’équipes de développement logiciel, mais vous pouvez appliquer ces fondamentaux à la croissance d’une entreprise ou d’une équipe dans n’importe quel secteur. Vous trouverez ces conseils utiles, même si vous adoptez un des modèles de passage à l’échelle existants : Large Scale Scrum (LeSS), Scrum@Scale, SAFe.
Cela s’explique par le fait que je m’attarde sur plusieurs aspects importants de la scalabilité rarement évoqués dans ces méthodologies — la vérité fondamentale sur la nature de la montée en échelle, trop souvent oubliée ou ignorée.
La loi fondamentale du passage à l'échelle
La Loi Fondamentale du Passage à l'Échelle est une observation empirique de ce qui se passe dans les projets lorsqu’on les fait grandir :
Le passage à l’échelle amplifie les défauts et rend les atouts plus difficiles à exploiter.
J’ai formulé cette expression, mais je ne suis ni le seul, ni le premier à avoir eu cette intuition.
Voyons concrètement ce que cette Loi implique à travers quelques exemples liés à la scalabilité.
1. Exemple : Communication et passage à l’échelle
Le premier et le plus évident concerne la communication. Il est bien connu que plus le nombre de personnes impliquées dans un projet augmente, plus le nombre de canaux de communication croît. Si ces canaux de communication ne sont déjà pas assez efficaces au départ, la montée en échelle aggrave encore la situation.
À l’inverse, si les canaux de communication sont déjà efficaces au départ, la montée en échelle apporte tout de même de nouveaux défis, non seulement dus au nombre croissant de personnes, mais aussi à leur dispersion géographique. Bien souvent, de nouvelles équipes apparaissent dans différents endroits, imposant des changements dans la communication — par exemple, passer de réunions en face à face à la visioconférence, ou remplacer un tableau blanc par un outil électronique.
2. Exemple : Intégration Continue/Livraison Continue et passage à l’échelle
On retrouve aussi la Loi Fondamentale du Passage à l’Échelle dans les pipelines d’Intégration Continue (CI) et de livraison continue (CD). Lorsqu’il n’y a qu’une seule équipe, la situation est simple à gérer.
Mais en passant d’une à deux équipes, les systèmes CI et CD deviennent plus complexes : en général, pour n équipes, il y aura tendance à avoir n+1 pipelines (un pipeline par équipe, plus un pipeline d’intégration). Cela a évidemment des répercussions sur la gestion des environnements et sur la coordination entre équipes.
3. Exemple : Boucles de rétroaction et passage à l’échelle
Un dernier exemple : les boucles de rétroaction. Plus les projets grandissent, plus leurs cycles de retour d’information s’allongent. Résultat : il est bien plus difficile d’affiner le système progressivement, ce qui augmente le risque de concevoir un produit inadapté.
Ce ne sont là que trois exemples des nombreux défis induits par la montée en échelle. Je suis sûr que vous pourrez en trouver beaucoup d’autres.
Supposons que vous acceptez les compromis inévitables. La prochaine étape est de vérifier que votre projet satisfait à certains prérequis essentiels pour valider votre capacité à évoluer.
10 prérequis pour passer à l’échelle
Que vous ayez ou non une entreprise, un projet ou une équipe pouvant évoluer, cela dépend de plusieurs prérequis listés ci-dessous. Si vous remplissez ces conditions, vous êtes en bonne voie pour une montée en échelle réussie. Sinon, le risque d’échec augmente fortement.
1. La présence d’objectifs clairs et partagés
Cela devrait aller de soi, mais selon mon expérience, l’absence d’objectifs clairs et partagés est extrêmement courante. Sans ces objectifs, les équipes partent dans différentes directions et il devient plus difficile de livrer un résultat pertinent.
2. L’utilisation d’indicateurs appropriés
Plus le projet est important, plus il est essentiel de pouvoir mesurer l'impact des décisions prises. Par exemple, l'ajout d'une nouvelle équipe a-t-elle amélioré la capacité du projet à livrer ? Forçons-nous tellement les équipes que la qualité en pâtit ? Les équipes travaillent-elles bien ensemble, ou interfèrent-elles les unes avec les autres ?
3. Une architecture adaptée
Si la « forme » du système ne correspond pas à la structure des équipes, ajouter davantage d'équipes ne fera qu'empirer les choses. Il s'agit là d'un effet direct de la loi de Conway, une observation empirique bien connue et confirmée dans la pratique.
4. Disponibilité des compétences managériales et techniques
Les problèmes dus au manque de compétences auront un effet négatif amplifié à mesure que le projet prendra de l’ampleur.
5. De bons canaux de communication
Plus il y a de personnes impliquées, plus la communication est importante. La réussite du passage à l’échelle exige une communication fluide et efficace.
6. Bonne priorisation et planification
L'absence d'une priorisation et d'une planification adéquate est, de mon expérience, un facteur très courant d’échec de projets. En particulier, lorsqu’il y a plus d’une équipe impliquée, les activités de priorisation et planification doivent prévoir des mesures pour atténuer les effets des retards et du manque de synchronisation.
7. Bonne expression et gestion des besoins
Cela va de pair avec la priorisation et la planification. En outre, l’impact des besoins erronés, mal compris ou inutiles s’aggravera au fur et à mesure que le nombre d’équipes augmente.
8. Travail de haute qualité
Plus le projet est grand, plus l’impact négatif d'une mauvaise qualité est important. Dans des scénarios pathologiques (et fréquents), certains bugs peuvent devenir des fonctionnalités, car les boucles de rétroaction pour les corriger sont si longues que d'autres équipes ont eu le temps de concevoir leurs propres palliatifs pour les contourner.
9. Disponibilité des ressources
Davantage d’équipes nécessite plus de bureaux, d’ordinateurs, d’outils et d’environnements.
10. Automatisation sans concession
Toute activité manuelle constitue un goulet d’étranglement dont les effets s’aggravent avec le nombre de personnes et d’équipes. Un exemple courant : les activités de tests manuels pour garantir qu’aucune régression n’a été introduite avant une mise en production. D’après mon expérience, c’est l’un des plus gros freins dans tout projet, mais surtout dans ceux impliquant plus d’une équipe.
Attention à la mise à l’échelle prématurée
La scalabilité est une priorité pour les start-ups et les entrepreneurs en série — et ils ont quelques leçons à nous donner sur les dangers de vouloir grandir trop tôt.
Si vous engagez un effort de montée en charge avant d’avoir réellement réuni les prérequis pour faire évoluer correctement une entreprise, une équipe ou une organisation, vous obtenez ce que la communauté des start-ups appelle une « mise à l’échelle prématurée ».
Une définition simple de la mise à l’échelle prématurée par l’entrepreneur en série Jim Pitkow :
Mise à l’échelle prématurée : croître en prévision de la demande, au lieu de poursuivre une croissance tirée par la demande.
En effet, bien monter en échelle prend du temps — et la vraie scalabilité répond à un besoin réel lié à la demande, et non pas à une idée artificielle de grossir et d’en faire toujours plus, plus vite.
La communauté des start-ups nous offre plusieurs enseignements à appliquer à nos équipes et projets lorsqu’on se demande s’il est temps ou non de passer à l’échelle. Voici quelques statistiques issues du Startup Genome Report Extra sur la mise à l’échelle prématurée :
- Les startups qui grandissent prudemment mettent 76 % de temps en plus à parvenir à leur taille d’équipe que celles qui s’agrandissent trop tôt.
- 74 % des startups Internet à forte croissance échouent à cause d’une mise à l’échelle prématurée.
- Les startups qui évoluent de façon adéquate se développent environ 20 fois plus vite que celles qui s’agrandissent trop tôt.
Si vous souhaitez plus de statistiques sur l’entrepreneuriat, consultez notre étude sur les États américains les plus entrepreneuriaux.
Êtes-vous vraiment prêt à passer à l’échelle ?
Si votre projet est bien mené et satisfait aux prérequis énumérés ci-dessus, la question suivante à se poser devrait être :
« Combien d’équipes peuvent-elles contribuer de manière productive ? »
Nous répondrons à cette question dans la prochaine section.
Quelle est la limite de l'évolutivité ? Lois de Brooks et d'Amdahl
Il est bien connu que l'ajout de personnes supplémentaires à un projet logiciel n'augmente pas nécessairement la productivité.
En fait, dans la plupart des cas, ajouter plus de personnes provoquera une chute sévère de la productivité.
Fred Brooks a fait cette observation dans son livre The Mythical Man Month, observation qui est devenue connue sous le nom de loi de Brooks :
« Ajouter de la main-d'œuvre à un projet logiciel en retard le rendra encore plus en retard […] Le nombre de mois d'un projet dépend de ses contraintes séquentielles. Le nombre maximum de personnes dépend du nombre de sous-tâches indépendantes. À partir de ces deux quantités, on peut établir des plannings avec moins de personnes mais sur une plus longue période […]. On ne peut cependant pas obtenir de plannings viables avec plus de personnes en moins de temps. »
La seconde partie de la citation ci-dessus est, à mon avis, la plus intéressante. En fait, il s'agit tout simplement de la traduction en langage courant de la loi d'Amdahl—une formule qui donne l'accélération maximale théorique d'un système concurrent :
Loi d'Amdahl
Accélération = 1 / (s + p / n )
Où :
s = pourcentage de tâches sérielles
p = pourcentage de tâches parallèles
s + p = 1
n = nombre de processeurs (équipes, dans notre cas)
En fait, un projet avec plusieurs équipes est une sorte de système concurrent où chaque équipe constitue une unité de traitement. En pratique, la loi d'Amdahl stipule que la quantité maximale de travail effectué simultanément est limitée par la quantité de travail qui doit être effectuée de manière séquentielle.
En termes simples, cela signifie que les tâches qui doivent être réalisées dans un ordre précis imposeront des restrictions sur la quantité de travail que les équipes peuvent accomplir en même temps.
Qu'est-ce qu'un travail séquentiel dans un contexte de développement logiciel ?
Vous vous demandez peut-être quel type de travail séquentiel impacte les équipes logicielles.
Voici quelques exemples (je suis certain que vous en trouverez beaucoup d'autres) :
- Tous travaux sur les pipelines d'intégration et de déploiement
- Fusion de modifications logicielles dans du code partagé entre différentes équipes
- Toute forme de synchronisation—par exemple, une équipe dépendant des livrables d'une autre avant de pouvoir poursuivre son travail
- Attente du provisionnement des ressources
Application de la loi d'Amdahl à l'échelle des équipes
Le graphique ci-dessous illustre les implications de la loi d'Amdahl lorsqu'on augmente le nombre d'équipes sur la productivité.
Nous pouvons voir que la productivité augmente de façon sous-linéaire avec l'accroissement du nombre d'équipes—jusqu'à un pic, après quoi elle recommencera à diminuer.
Une illustration de la loi d'Amdahl : le débit des livrables augmente avec le nombre d'équipes, mais seulement jusqu'à un certain point—et ce n'est généralement pas ce que les managers espèrent.
Si vous ne deviez retenir qu'une seule chose de cet article, ce serait celle-ci :
Augmenter le nombre d'équipes peut accroître le débit—mais seulement jusqu'à un certain point.
Alors, quel est le nombre idéal d'équipes pour un projet donné ?
Malheureusement, il n'existe pas d'équations pour calculer à l'avance le nombre idéal d'équipes pour un projet donné. La seule manière consiste à utiliser un ensemble de métriques projet pour mesurer la productivité, la qualité, etc., et pour observer ce qu'il se passe lorsque l'on ajoute ou retire des équipes. Ma recommandation est de commencer petit, avec une équipe de 3 à 6 personnes, et de n'augmenter l'effectif que lorsque cela s'avère nécessaire.
À un moment donné, vous pouvez constater que vous avez déjà atteint le nombre maximum d'équipes, mais que votre projet n'est toujours pas en mesure de remplir ses engagements. C'est là que vos compétences en hiérarchisation et en communication prennent toute leur importance, car vous pourriez avoir à avoir des conversations difficiles avec vos clients.
Considérations sur la structure des équipes : Équipes fonctionnelles ou par composant ?
Lorsque vous ajoutez une nouvelle équipe au projet, comment doit-elle fonctionner ? Pour commencer, posez-vous ces deux questions :
- Seront-ils chargés de développer des fonctionnalités visibles par le client de bout en bout ou de modifier quelque chose dans le système pour atteindre leur objectif ?
- Seront-ils chargés de travailler sur un composant spécifique fournissant une partie d'une fonctionnalité visible pour l'utilisateur ?
Si vous avez répondu oui à la question n°1, l’équipe sera une équipe de fonctionnalités.
Si vous avez répondu oui à la question n°2, il s’agira d’une équipe de composants.
Conseils pour choisir la bonne structure d’équipe
Choisir la bonne structure et organisation d’équipe est très important, mais ce n’est pas facile. Actuellement, les équipes de fonctionnalités semblent être l’option privilégiée dans la plupart des situations. Cependant, ce choix est souvent fondé sur l’habitude ou la routine plutôt que sur des données concrètes.
La réalité, c’est que « ça dépend ». Plus précisément, cela dépend de l’architecture du système. Les projets logiciels ont tendance à suivre ce que l’on appelle la loi de Conway — une observation empirique de Mel Conway :
« Les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations »
En d’autres termes, la « forme » de la structure de l’équipe doit correspondre à la « forme » du système, sinon le projet rencontrera de sérieux problèmes.
C’est la raison pour laquelle je recommande toujours aux responsables d’impliquer des architectes seniors et des responsables techniques dans les décisions relatives à la structure des équipes — sinon, les managers font en réalité de la conception de système sans s’en rendre compte (et sans en avoir les compétences nécessaires). Cela peut grandement accroître le risque d’échec du projet.
Deux paradoxes de la mise à l’échelle
D’après mon expérience de consultant auprès de nombreux projets à grande échelle, j’en suis arrivé à la conclusion que, dans la plupart des cas, les projets passent à l’échelle pour de mauvaises raisons.
J’ai inventé deux paradoxes qui résument ce que j’ai observé dans la pratique :
Premier paradoxe de la montée en charge
La plupart des projets passent à l’échelle parce qu’ils ne remplissent pas les prérequis pour la montée en charge
Second paradoxe de la montée en charge
Les projets qui remplissent les prérequis pour la montée en charge ont moins besoin de passer à l’échelle
Le premier paradoxe énonce que, dans la majorité des situations, les projets avancent lentement tout simplement parce qu’ils ne sont pas bien gérés.
Le second indique que les projets bien gérés auront moins besoin de monter en charge justement parce qu’ils sont bien gérés.
En fait, les projets les plus productifs que j’ai vus ne comportaient qu’une ou deux petites équipes et satisfaisaient à tous les prérequis pour la mise à l’échelle. Parmi les projets de grande envergure auxquels j’ai participé, je n’en ai pas vu un seul où tous les prérequis étaient remplis. En réalité, ils avaient tous beaucoup de difficultés à remplir l’un ou l’autre des prérequis.
Si vous participez à un projet qui rencontre des problèmes et des retards, la meilleure recommandation que je puisse faire est de réduire le désordre avant d’envisager de faire monter le projet en charge.
Leçons à retenir pour faire évoluer vos équipes de la bonne façon
Faire évoluer des équipes logicielles n’est pas simple, et doit être fait avec une extrême précaution. Avant de vous laisser, voici quelques réflexions pour trouver la manière la plus efficace de faire évoluer une équipe de développement logiciel :
- Si vous travaillez à satisfaire les prérequis pour la montée en charge, vous constaterez peut-être que vous pouvez garder une petite taille et éviter tous les problèmes liés à un effectif trop important.
- En revanche, si votre projet est déjà de grande taille et en difficulté, concentrez-vous d’abord sur la réduction du désordre.
Voici les premières étapes que je vous suggère de suivre après avoir lu cet article :
- Découvrez ce qui se passe réellement sur le terrain
- Mettez en place quelques indicateurs pour pouvoir évaluer la situation actuelle, ainsi que la qualité des décisions prises.
