---

Comment faire passer Scrum à l’échelle pour les grands projets et les équipes distribuées ? La réponse pourrait vous surprendre !

Le framework décrit jusqu’ici fonctionne au mieux avec une seule Scrum Team réunie au même endroit. En pratique, une équipe ne peut cependant pas toujours réaliser tout le projet, ou ses membres doivent être répartis sur plusieurs sites.

Quand elle ne suffit pas aux besoins du produit, l’organisation peut envisager d’autres équipes. La répartition géographique seule ne l’impose pas, et ajouter des personnes peut accroître les coûts de coordination. Nous constatons aussi souvent une répartition sur des sites éloignés ou sur plusieurs continents.

Plusieurs raisons peuvent conduire une organisation à répartir ses équipes :

• Raisons techniques : Le savoir-faire nécessaire à certains composants n’est pas disponible au siège,
• Raisons d’expertise : Certaines compétences ne sont pas disponibles localement : automatisation des tests, conception d’interfaces ou intégration des logiciels internes avec ceux d’autres éditeurs peuvent nécessiter des experts externes,
• Raisons de taille : Le projet nécessite davantage de personnes pour livrer dans le délai prévu que ne peut raisonnablement contenir une seule Scrum Team. Plusieurs équipes cohérentes peuvent alors être préférables à l’agrandissement indéfini d’une équipe,
• Raisons économiques : Des ressources dans des régions moins coûteuses ou la continuité du travail grâce aux fuseaux horaires peuvent constituer un argument économique solide.

La communication étant essentielle à Scrum, tous les membres doivent chercher à surmonter les difficultés d’un environnement distribué. Chacun doit avoir accès aux conférences audio et vidéo et au partage d’écran.

Les outils courants de gestion de projet soutiennent une communication saine et continue : Product Backlogs, Sprint Backlogs, listes d’incidents, partage de connaissances et d’actualités, etc.

Organisation du projet : plusieurs équipes

La manière la plus simple d’élargir Scrum pour un grand projet est d’augmenter le nombre d’équipes sur le même site.

Lorsque plusieurs équipes doivent collaborer, mieux vaut en augmenter progressivement le nombre.

Qu’est-ce que cela signifie pour vous ?

Plusieurs équipes sur un seul site

La croissance progressive est généralement plus facile à gérer que le lancement simultané de dix équipes. Commencez par une Scrum Team, puis ajoutez une ou deux équipes après plusieurs Sprints réussis. Lorsque vous vérifiez que ces équipes (en savoir plus sur Plusieurs Scrum Teams) travaillent bien ensemble, vous pouvez en ajouter d’autres à l’organisation distribuée.

Augmenter le nombre d’équipes

Deux méthodes sont courantes pour créer des Scrum Teams :

• Diviser une équipe existante et ajouter des membres là où c’est nécessaire,
• Constituer une nouvelle équipe avec des ingénieurs qui ne participaient pas encore au projet.

Diviser une équipe permet de s’appuyer sur des membres qui connaissent déjà le projet et ont de l’expérience.

Les nouvelles équipes sont donc généralement productives au moins en partie dès leur formation. Mais l’équipe pleinement opérationnelle a été scindée, ce qui peut affecter la motivation. C’est particulièrement vrai sans annonce et justification préalables de la direction, lorsque les membres ne sont préparés ni mentalement ni techniquement.

Ajouter des équipes entièrement nouvelles permet aux équipes existantes de conserver leur structure et leurs Sprints. La coordination, l’intégration des personnes et du travail restent nécessaires. Les nouvelles équipes mettront toutefois plus longtemps à acquérir le savoir-faire et l’élan requis.

Quelle que soit la méthode retenue, gardez ces principes :

• Commencez avec peu de Scrum Teams,
• Augmentez leur nombre progressivement,
• Assurez la continuité du travail et la livraison fluide de logiciels et de valeur pendant les changements,
• Si des problèmes importants freinent la productivité ou la continuité, résolvez-les avant de poursuivre l’expansion.

Organisation du projet : équipes distribuées

La complexité devient particulièrement visible lorsque les équipes sont réparties entre plusieurs sites : barrières de communication, difficultés de coordination et interprétations différentes des règles communes n’en sont que quelques exemples.

Plusieurs équipes sur plusieurs sites

Ne pas relever ces défis a de graves conséquences.

Les entreprises gaspillent des milliards de dollars de budget informatique faute de compétences en Leadership organisationnel et Expertise Scrum à l’échelle.

Voici quatre recommandations essentielles :

• Veillez à former les nouveaux membres au framework Scrum en tant que Scaled Scrum Expert,
• Présentez-leur correctement le projet pour qu’ils comprennent sa finalité technique et sa valeur métier. Ils pourront ainsi décider de manière à accroître leur contribution,
• Établissez les règles du projet. Comme une équipe définit comment communiquer, planifier et travailler, une organisation multiéquipes a besoin de règles communes pour agir, résoudre les problèmes et livrer de la valeur ensemble.
• Faites travailler temporairement les nouveaux membres avec les plus expérimentés. Des visites sur site et une formation en situation peuvent être nécessaires et sont souhaitables : elles transmettent le savoir et créent un dialogue personnel dans les deux sens entre sites et équipes.

Équipes virtuelles

On peut aussi répartir les membres d’une même Scrum Team entre plusieurs sites : c’est une « équipe virtuelle ».

Le défi principal est une communication sans faille. Tous les événements prescrits doivent toujours avoir lieu, même sans présence dans une même salle.

Équipes virtuelles

Les membres d’un même site peuvent se réunir lorsque c’est utile, en assurant la pleine participation des personnes à distance. Ils s’appuient davantage sur les outils collaboratifs et peuvent se connecter ensemble en visioconférence au reste de l’équipe.

Équipe de Scrum Product Owner

Nous l’avons souvent souligné : les échanges réguliers entre Product Owner et Scrum Team sont essentiels à une livraison réussie.

Les équipes réparties doivent accéder efficacement aux décisions produit. Pour un même produit, elles partagent un Product Owner, un Objectif de Produit et un Product Backlog. Le Product Owner peut déléguer le soutien sans déléguer sa responsabilité ; un Product Owner responsable distinct pour chaque équipe n’est pas exigé.

Cette édition décrit une « Scrum Product Owner Team » et un « Chief Scrum Product Owner » comme une organisation possible de la collaboration. Le Product Owner peut travailler avec des délégués ou des spécialistes, mais ces titres ne créent pas de responsabilités Scrum supplémentaires et ne remplacent pas son unique responsabilité sur le produit.

Avec ce soutien, le Product Owner responsable veille à ce que :

• Le bon produit soit réalisé pour satisfaire le client,
• Le Product Owner et ses délégués collaborent efficacement pour aider les équipes à créer une valeur métier et technique.

Le Product Owner reste responsable de la gestion efficace du backlog. D’autres compétences et parties prenantes peuvent soutenir le travail sur les exigences. Cela peut inclure des représentants du dossier économique, des parties prenantes, des architectes d’entreprise et des architectes techniques.

Pour un même produit, tous travaillent depuis un Product Backlog ordonné vers un Objectif de Produit commun. Chaque équipe livre certaines stories, mais certaines nécessiteront toujours les contributions et les résultats de plusieurs équipes.

Équipes de composants et équipes de fonctionnalités

Le travail peut être réparti en confiant aux équipes des composants logiciels ou des fonctionnalités. D’où les noms « équipe de composants » et « équipe de fonctionnalités ».

Équipes de composants

Chaque équipe réalise uniquement certains composants du système global. Il faut alors généralement découper une story pour en réaliser des parties dans chaque composant. Les dépendances rendent l’intégration continue indispensable aux livraisons réussies.

Équipe de Scrum Product Owner

Elles peuvent compliquer la livraison d’une fonctionnalité complète pendant le Sprint. Collaboration et intégration sont indispensables : les équipes d’un même produit doivent livrer un Incrément intégré et utilisable, conforme à leur Definition of Done commune.

Cela augmente la taille des lots et les délais du travail en cours non encore intégré. C’est peu souhaitable : Scrum vise des Incréments livrables en petits lots et avec des délais courts.

En revanche, ces équipes facilitent la spécialisation dans l’architecture et la conception de composants particuliers. C’est très utile pour ceux qui exigent découverte et innovation.

Leurs membres ne se spécialisent cependant que dans certaines parties du système. Ils peuvent perdre la vision d’ensemble et la finalité métier des fonctionnalités.

Rappelez-vous que nos clients nous rémunèrent pour des fonctionnalités utiles à leur activité, pas pour des composants. Sans cette attention constante aux fonctionnalités, l’optimisation globale et l’intégration prennent plus de temps. Les décisions qui optimisent un composant isolé peuvent créer des goulets d’étranglement invisibles pour la solution complète.

Équipes de composants

Équipes de fonctionnalités

Elles sont entièrement responsables des user stories définies dans le Product Backlog. Elles ne se répartissent plus par composant : chacune livre une fonctionnalité pleinement opérationnelle et sa valeur métier.

Équipes de fonctionnalités

Leurs membres ont des compétences pluridisciplinaires et agissent avec le plus d’autonomie possible pour livrer vite. L’équipe conserve la connaissance du système, ce qui facilite l’intégration de ses fonctionnalités.

Il peut toutefois être plus difficile d’approfondir chaque composant. Construire une équipe autonome et rapide demande du temps : la pluridisciplinarité ne se crée pas facilement. Ce sont néanmoins ces équipes performantes qui font avancer la plupart des organisations, probablement la vôtre aussi.

Comment choisir entre équipes de composants et de fonctionnalités ?

En pratique, la plupart des grandes organisations utilisent à la fois des équipes de composants et de fonctionnalités.

Équipes de composants et de fonctionnalités

Sur le graphique, C est une équipe de composants. Elle fournit des services d’infrastructure planifiés et à la demande aux équipes de fonctionnalités. Elle ne réalise pas directement des stories de bout en bout, mais répond aux besoins des stories retenues par les équipes de fonctionnalités.

Cela limite le nombre de spécialistes de ces composants nécessaires dans les équipes de fonctionnalités.

Le Scrum Master dans les projets distribués

Son rôle est encore plus important dans cet environnement :

• Il faut davantage d’efforts pour aligner les équipes sur les valeurs Scrum,
• Établir les règles des équipes et du projet prendra plus longtemps, car elles concernent plusieurs équipes,
• Enfin, l’augmentation des dépendances entre équipes et livrables crée davantage d’obstacles.

Le Scrum Master doit être accessible et efficace. La proximité physique peut aider, mais n’est pas une exigence ; l’accompagnement à distance est possible. L’organisation distribuée doit lui permettre :

• D’aider à faire lever les obstacles à la progression,
• D’aider l’équipe à établir des accords de travail efficaces et
• D’améliorer son utilisation du framework Scrum.

Certaines organisations utilisent un Lead ou Primary Scrum Master pour le coaching et la coordination entre équipes. C’est une organisation facultative, pas une hiérarchie obligatoire ni un remplacement des responsabilités de chaque équipe.

Chaque Scrum Team conserve la responsabilité de Scrum Master et a besoin d’un soutien efficace pour ses événements, son autogestion et ses améliorations.