L’une des questions les plus brûlantes de nos jours, que ce soit en ligne ou en salle de conférence, est la suivante : Comment une organisation devient-elle plus « agile » ? Au fur et à mesure que la discussion évolue, elle débouche sur d’autres questions, parmi lesquelles : Comment faire passer l’agilité au sein d’une équipe à plusieurs équipes ? Devrions-nous vraiment évoluer vers plusieurs équipes ? Pouvons-nous appliquer le Framework Scrum à grande échelle en même temps ? Serons-nous efficaces si nous travaillons à plusieurs équipes sur le même produit ? Des questions auxquelles nous allons tenter de répondre dans cet article à travers la technique de scaling Scrum.
Certains produits sont trop complexes pour être livrés par une seule équipe Scrum. C’est le cas, par exemple, des logiciels pour des banques, des automobiles ou d’autres produits physiques qui nécessitent les efforts coordonnés de plusieurs équipes Scrum pour pouvoir être livrés. D’autres produits sont quant à eux soumis à des contraintes de « Time-To-Market » très strictes qui exigent de mobiliser davantage de compétences dans un court laps de temps. Capacités qu’une seule équipe ne peut fournir à elle seule.
Face à ces défis, les organisations ont besoin de plus qu’une simple équipe Scrum pour travailler sur un seul produit. Les équipes Scrum multiples qui travaillent ensemble pour construire un seul produit ont souvent du mal à créer un travail intégré « Done » à chaque sprint en raison de la complexité supplémentaire des dépendances à l’échelle.
Pourquoi la mise à échelle Scrum ?
Scrum étant le mode de travail le plus courant parmi les équipes, la question se pose de savoir comment faire évoluer la méthodologie au-delà d’une seule équipe. Toutefois, la question devrait plutôt porter sur le(s) produit(s) livré(s) et sur la manière la plus efficace de le faire.
Scrum est conçu pour et fonctionne bien pour les organisations qui opèrent principalement dans le domaine complexe (voir chaotique) du Framework Cynefin de Dave Snowden.
Les complexités de la technologie, du marché et de l’environnement et leurs interactions ayant rapidement augmenté, l’utilité de Scrum pour faire face à la complexité est prouvée quotidiennement [le guide de Scrum].
Quelles sont les principales raisons de la mise à l’échelle de Scrum ?
- La nécessité de compléter rapidement la fonctionnalité en mettant en place des équipes Scrum supplémentaires pour travailler sur le Backlog produit.
- La mise à l’échelle est nécessaire lorsqu’il est nécessaire d’aligner plus d’une équipe Scrum dans un programme.
- La nécessité de rassembler les équipes sous une mission commune, de synchroniser leurs événements, de normaliser leur estimation, afin que le suivi et la mesure deviennent faciles.
Des équipes Scrum interdépendantes
Une fois qu’un certain nombre d’équipes Scrum commencent à travailler ensemble sur le Backlog Produit, on constate une augmentation du nombre de complications, d’événements non linéaires et d’interactions. Il existe une corrélation linéaire entre la créativité et la productivité, et les Scrum Teams. Les Product Owner doivent analyser et évaluer soigneusement les coûts et les avantages.
La [source] ci-après montre le nombre d’interactions possibles entre différents membres d’une seule équipe. Ceci prouve que le fait de rajouter de nouveaux membres à une équipe Scrum (3-9 personnes) rajoute de la complexité et introduit forcément des problèmes de communication.
Comment mettre Scrum à l’échelle ?
Une seule instance de Scrum dispose d’une équipe Scrum qui travaille à partir d’un seul arriéré de produits. L’équipe sprinte contre les éléments sélectionnés du Backlog produit et crée un incrément de fonctionnalités potentiellement livrables ou utilisables à la fin du sprint.
Cependant, pour un ou plusieurs sprints, le Product Owner a choisi d’employer plus d’une équipe Scrum. Le nombre de Scrum Teams peut être constant et leur composition peut rester la même… ou non.
Il est impératif que l’organisation s’entende sur la définition des produits et sur les limites d’un seul produit. Un ensemble de capacités est-il constitué d’un produit, ou des parties d’un produit plus important ? Sans cette compréhension, impossible alors de maintenir l’attention en tant qu’équipe – ou ensemble d’équipes –, et d’assurer l’appropriation du produit. C’est pourquoi il est essentiel de vérifier comment vous définissez le produit, combien de produits vous avez et ce qui peut les relier ou les séparer les uns des autres.
Ne laissez toutefois pas la vision figée et le retard de livraison diminuer la qualité des produits. Trop souvent, la est gravée dans le marbre et n’évolue pas sprint par sprint. Résultat : cela conduit à une approche en mini-cascade, et risque d’aboutir à une mauvaise livraison ou à moins de valeur avec le temps. Si vous réexaminez régulièrement le « Backlog Produit », vous avez beaucoup plus de chances de continuer à l’affiner pour chaque sprint et de livrer des produits de plus grande valeur finalement.
Avant d’envisager de la mise à échelle Scrum (Scaling of Scrum), demandez-vous si cela résoudra vraiment vos problèmes. Ça ne sert à rien d’étendre Scrum tant que vous n’avez pas réglé vos problèmes avec l’adoption de Scrum. Dans certains cas, vous n’aurez pas à étendre Scrum si vous l’appliquez déjà correctement.
Il existe une multitude de différence entre les différents Frameworks de mise à l’échelle Scrum. Nous reviendrons ultérieurement plus en détails sur chaque Framework séparément.
Les Frameworks de la mise à échelle Scrum
Il existe plusieurs Frameworks de mise à l’échelle Scrum :
- LeSS (Large Scale Scrum Framework) reste le plus proche de l’objectif et du cadre de Scrum car il n’y a que peu de complexité ajoutée (certains événements ont une partie avec l’équipe et une partie avec les représentants des équipes). Par conséquent, LeSS est la meilleure option pour les solutions de mise à l’échelle des équipes de petites tailles.
- Nexus est également fidèle à Scrum, bien que les rôles, événements et artefacts supplémentaires ajoutent de la complexité. En conséquence, Nexus obtient un score inférieur à celui de LeSS en tant qu’option de petite ou moyenne équipe.
- Scrum@Scale est un concept très intéressant. Toute l’organisation (delivery, produit, etc) travaille en équipes Scrum. En théorie, cela fonctionnerait très bien et vraiment dans l’esprit du guide Scrum. Scrum@Scale remporte le prix de la meilleure option à grande échelle.
- SAFe met l’objectif de la Scrum Team sous forte pression en raison de son approche descendante, des couches supplémentaires et, par conséquent, des rôles, des événements et des artefacts supplémentaires. SAFe obtient, selon notre humble avis, le plus faible score de tous les Framework de mise à l’échelle Scrum.
- Spotify permet une grande autonomie aux équipes pour travailler selon Scrum. L’accent mis sur les petits systèmes découplés est toutefois une perspective différente de celle de Scrum, qui consiste à optimiser la valeur d’un produit. Spotify peut être votre approche de choix en matière de dimensionnement si vous n’avez pas les préoccupations des systèmes par rapport au produit.
- Scrum of Scrums est la solution la plus simple pour mettre à l’échelle Scrum. On y ajoute encore un ou plusieurs événements qui permettent aux entreprises d’ignorer les éventuels problèmes de transversalité et de transparence. Scrum of Scrums obtient également un score inférieur à Less sur les équipes de petite et moyenne taille.
Les défis de la mise à échelle de Scrum
Il n’y a pas de solution miracle ! Trop souvent, j’entends les gens parler, lors de conférences ou de réunions, de la façon dont ils veulent « acheter agile » ou « devenir agile » sans comprendre réellement leur besoin ni la philosophie agile. Lorsque l’on creuse la conversation, on a tendance à penser qu’il suffit d’acheter des outils et d’appliquer certains processus pour devenir agile comme par magie… mais ce n’est pas le cas. Il n’y a pas de « solution miracle » !
Même si vous avez une équipe de deux personnes qui travaillent ensemble, vous commencez à rencontrer des dépendances les unes par rapport aux autres. À mesure que vous passez à plusieurs personnes, les dépendances augmentent également. Imaginez maintenant que vous passez à l’échelle de plusieurs équipes Scrum travaillant ensemble pour livrer un produit : les dépendances ne vont pas seulement se croiser entre les individus, mais également entre les équipes Scrum.
Les catégories de dépendances peuvent comprendre des éléments tels que :
- Séquence de construction : Un élément ne peut être complété tant que son parent n’est pas terminé (peut inclure la technologie, le domaine, le logiciel…)
- Personnes / Compétences : Seules certaines personnes/équipes peuvent compléter un élément
- Externe : L’article principal est livré par des équipes extérieures à l’équipe Scrum
Une fois que les dépendances ont été visualisées et séquencées, les conversations doivent se concentrer sur les possibilités de les minimiser et de les supprimer.
Voici quelques solutions possibles expérimentés au sein du Crédit agricole:
- Déplacer le travail entre les équipes afin qu’il y ait moins de dépendances entre les équipes.
- Déplacer les personnes entre les équipes afin de réduire les dépendances entre les équipes. Vous pouvez réduire considérablement les risques de livraison si certaines compétences sont rééquilibrées entre les équipes pour un sprint ou deux afin de minimiser les dépendances.
- Remodeler le travail. En divisant les éléments de différentes manières, il peut être possible d’éliminer les dépendances.
- Utiliser différentes stratégies basées sur les risques. Certains groupes peuvent essayer de supprimer complètement une dépendance entre équipes “in-Sprint”. D’autres groupes peuvent choisir d’affronter le risque le plus tôt possible et de dédier plusieurs Cross-Team dans les premiers sprints afin d’apprendre et de réagir plus tôt.
Conclusion
En fin de compte – et on ne le répétera jamais assez –, . La mise à l’échelle de Scrum, ou simplement le passage à des équipes plus importantes, ajoute de la complexité à la manière dont les personnes et les équipes travaillent. En tant que cadre, Scrum est un excellent moyen d’aider les équipes à évoluer sans avoir à changer leur univers. La mise à l’échelle de Scrum n’est qu’un Scrum. Vous ne changez pas la façon dont vous travaillez en tant qu’équipe Scrum, ni le travail fourni. Étendre Scrum permet aux équipes de développement de gérer les dépendances entre elles.
Lire aussi
Lire la suite
Pour aller plus loin
Lire la suite
Pas encore de commentaires