Comparaison de 5 frameworks de mise à l'échelle agiles : lequel devez-vous utiliser ?

Imaginez ceci : au début d'un projet, vous assemblez une équipe unique, efficace et interfonctionnelle d'individus déterminés à atteindre les objectifs du produit. Pour améliorer les performances, vous vous assurez que l'équipe maîtrise Agile. La demande pour le produit augmente, augmentant les exigences et élargissant le carnet de commandes. Vous et les autres parties prenantes réalisez que l'équipe doit être agrandie. Semble familier?

La mise à l'échelle permet à plusieurs équipes de travailler ensemble pour maintenir leur agilité. S'il y a plus de travail à faire que votre équipe ne peut en gérer dans un délai raisonnable, il est temps de passer à l'échelle. Pour ce faire, cependant, vous devez sélectionner le bon cadre, et il y en a plusieurs parmi lesquels choisir. Choisir mal et la mise en œuvre pourrait échouer, perturber la productivité et entraîner des répercussions financières importantes.

Le cadre le mieux adapté à votre équipe variera en fonction de facteurs tels que le financement disponible, l'approche organisationnelle et la complexité du produit.

Quand devez-vous évoluer ?

Il y a un certain nombre de critères clés à remplir avant d'envisager une mise à l'échelle :

Pouvez-vous gérer le développement avec une seule équipe ?

La mise en œuvre de cadres Agile à l'échelle peut être complexe et prendre du temps, alors n'évoluez pas si vous n'en avez pas besoin. Lorsque la charge de travail de votre équipe dépasse ses capacités, une mise à l'échelle est nécessaire.

Votre équipe est-elle Agile ?

Le critère le plus important est peut-être la maîtrise de votre équipe dans les approches Agiles. Si votre équipe n'a pas d'expérience en Agile, la mise à l'échelle créera plus de problèmes.

Les pratiques de développement de votre équipe doivent-elles être améliorées ?

Si les pratiques d'ingénierie de votre équipe ne sont pas efficaces, la mise à l'échelle peut ne pas produire les résultats souhaités. Des pratiques telles que la mise en œuvre correcte de DevOps et un pipeline CI/CD sont essentielles pour la cohérence entre les équipes. De plus, sans assurance qualité standardisée, il peut être difficile de tester de nouvelles fonctionnalités.

Votre équipe propose-t-elle des incréments intégrés ?

La mise à l'échelle implique l'intégration de plusieurs équipes collaborant sur le même produit, où chaque équipe produit des fonctionnalités qui fonctionnent ensemble. Le tableau suivant détaille les quatre configurations possibles d'équipes et de produits. Notez qu'un seul nécessite une mise à l'échelle.

Choisir un cadre de mise à l'échelle

Il existe de nombreux cadres de mise à l'échelle Agile parmi lesquels choisir, mais nous nous concentrerons sur cinq des solutions les plus largement utilisées : Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale et Disciplined Agile (DA) . J'ai trouvé que ce sont les cadres les plus efficaces, et ils peuvent être appliqués à une gamme de scénarios et d'organisations. Les sections suivantes vous fourniront les informations dont vous avez besoin pour faire le meilleur choix pour votre contexte de mise à l'échelle unique.

1. Cadre agile à l'échelle (SAFe)

SAFe est le framework le plus populaire pour la mise à l'échelle Agile. Une enquête de 2021 a révélé que 37% des praticiens Agile l'utilisent, en grande partie en raison de ses multiples configurations, qui se concentrent toutes sur les flux de valeur et ont des guides et des procédures bien définis.

Parce que SAFe est utilisé pour fournir des solutions complexes nécessitant plus de 50 personnes, il organise les équipes en trains de version agiles (ART). Pour synchroniser les équipes dans un ART, SAFe utilise des itérations d'incrémentation de programme, similaires aux sprints Scrum, et chaque itération dure généralement de huit à 12 semaines. Cette approche permet aux chefs de produit de rester concentrés sur les objectifs généraux et de superviser efficacement une feuille de route de produit complexe sans introduire de changements excessifs.

SAFe est basé sur le framework Scrum mais avec quelques différences clés : l'adoption de SAFe se fait au niveau de l'entreprise plutôt qu'au niveau de l'équipe ; et tandis que Scrum donne au propriétaire du produit l'autorité exclusive sur la priorisation, SAFe encourage une approche plus démocratique.

SAFe a quatre niveaux de mise en œuvre :

SÉCURITÉ essentielle

Essential SAFe est la base de SAFe et doit être maîtrisé avant de passer à l'une des configurations suivantes. Il utilise des rôles Scrum établis tels que Scrum Master, Product Manager et Product Owner, et introduit également un nouveau rôle : Release Train Engineer. Cette personne agit en tant que leader-serviteur et coach ART, guidant les équipes pour aligner leurs objectifs. Il peut y avoir entre cinq et 12 équipes dans un ART, chaque ART étant capable de fournir une solution complète.

Grande solution

Cette configuration repose sur Essential SAFe et introduit un concept appelé « train de solutions ». Il est utilisé lors de la création de solutions vastes et complexes qui nécessitent la coordination de plusieurs ART (potentiellement des centaines, voire des milliers de personnes) travaillant sur le même flux de valeur. Par exemple, si vous travaillez chez Microsoft et que vous avez trois équipes distinctes qui programment Excel, Word et PowerPoint, elles contribuent toutes au même flux de valeur : Microsoft Office.

Portefeuille

Le portefeuille se compose de plusieurs ART travaillant sur différents flux de valeur. Poursuivons avec l'exemple de Microsoft : des équipes distinctes travaillant sur les produits Office, Skype ou Xbox de l'entreprise.

Sûr complet

Cette configuration combine toutes les couches (Essential, Large Solution et Portfolio) pour coordonner la gestion des équipes à l'échelle de l'entreprise.

2. Lien

Le framework Nexus est également basé sur Scrum mais est plus léger que SAFe, ne nécessitant que de petits ajustements qui facilitent la collaboration entre trois à neuf équipes. La mise en œuvre de Nexus ne nécessite aucun rôle supplémentaire. Au lieu de cela, un représentant de chaque équipe rejoint une équipe d'intégration centrale qui aligne le travail vers un seul objectif. Semblable à Scrum, toutes les équipes se réunissent pour une session de planification de sprint, dont les résultats forment le backlog produit partagé. Pour vérifier les progrès, chaque équipe tient une réunion quotidienne semblable à un stand-up, et l'équipe d'intégration se réunit également pour rendre compte des progrès de son équipe.

Au cours d'un sprint, les équipes participent à une session de raffinement pour hiérarchiser et estimer le backlog. Parce que la complexité de la gestion du backlog augmente avec le nombre d'équipes, Nexus impose des sessions de raffinement. Les équipes se réunissent pour des revues et des rétrospectives après chaque sprint.

3. Scrum à grande échelle (LeSS)

LeSS est presque identique à Nexus, mais il présente des différences mineures, telles que des conventions de dénomination et des sessions de planification de sprint supplémentaires spécifiques à l'équipe. Il se différencie également par sa capacité à être étendu avec sa deuxième configuration, LeSS Huge, qui supporte la collaboration de plus de huit équipes.

LeSS Huge adopte une approche centrée sur le client pour organiser le développement. Pour gérer efficacement le travail, le propriétaire du produit doit diviser le backlog de produit de haut niveau en "backlogs de zone" plus petits d'éléments plus granulaires, puis les trier davantage, en zones d'exigences.

Ces domaines d'exigence sont gérés par des propriétaires de produits régionaux (APO). Les APO se spécialisent dans les domaines liés à chaque domaine et travaillent avec plusieurs équipes sur des solutions pour leur domaine. Chaque exigence stockée dans le backlog appartient à un seul domaine d'exigence, et chaque domaine est géré par un seul APO. Ensemble, le propriétaire du produit et les APO forment une équipe chargée de hiérarchiser avec une vue globale du produit.

4. Scrum@Scale

Scrum@Scale est une extension de Scrum et probablement le framework le plus facile à apprendre et à comprendre. Il évolue d'une équipe à une équipe d'équipes.

Un composant central du framework est le Scrum of Scrums (SoS). Chaque équipe choisit une personne pour la représenter lors des réunions SoS, qui ont généralement lieu quotidiennement après les stand-ups individuels de l'équipe. L'objectif de la réunion SoS de chaque jour est de faciliter la coordination et la communication entre les équipes, et de faciliter la gestion facile de toute dépendance ou chevauchement.

Les rôles uniques dans ce cadre incluent le maître SoS, essentiellement une version à l'échelle d'un maître Scrum, et le propriétaire en chef du produit, qui travaille avec les propriétaires de produit de l'équipe pour former un backlog commun pour le SoS.

Scrum@Scale est moins normatif que les autres frameworks, permettant aux organisations d'évoluer à leur propre rythme. Si le nombre d'équipes continue de croître et que les réunions SoS deviennent trop importantes, les organisations peuvent faire évoluer le cadre vers un Scrum de Scrum de Scrums (SoSoS).

5. Agile discipliné (DA)

DA diffère des autres frameworks en ce qu'il agit davantage comme une boîte à outils à partir de laquelle vous pouvez choisir les stratégies de mise à l'échelle les plus appropriées, plutôt qu'un cadre rigide avec des règles auxquelles vous devez obéir. Il s'agit d'un hybride contextuel de divers cadres, y compris Scrum et Kanban, qui peut être adapté aux besoins de chaque projet, centré sur le principe « Le choix est bon ». DA est construit sur l'idée que chaque équipe et organisation est unique dans sa taille, sa distribution et son domaine, et chaque membre de l'équipe est également unique, avec ses propres compétences et expériences.

Il peut être appliqué au niveau de l'équipe de développement logiciel ou à l'échelle de l'entreprise. Pour ce dernier, la boîte à outils DA identifie ce que diverses fonctions commerciales, telles que la finance, les opérations informatiques et la gestion des fournisseurs, doivent traiter, et présente une gamme d'options pour le faire.

DA distingue trois phases de projet (Inception, Construction et Transition) et chacune comprend des objectifs de processus axés sur la livraison. Étant donné que ce cadre se concentre sur le cycle de vie complet de la livraison, et non uniquement sur la construction, il introduit plus de rôles que les autres cadres. Les rôles principaux, que l'on retrouve dans chaque équipe DA, sont les parties prenantes, les membres de l'équipe, les chefs d'équipe, les propriétaires de produits et les propriétaires d'architecture. Il existe également cinq rôles de support, souvent utilisés de manière temporaire pour aider à la mise à l'échelle : spécialiste, expert du domaine, expert technique, testeur indépendant et intégrateur.

DA peut être utilisé en plus des autres frameworks pour évoluer davantage.

Choisissez avec soin et évoluez lentement

La mise à l'échelle des équipes Agile et l'intégration transparente de leur travail sont difficiles, mais peuvent être facilitées en sélectionnant le meilleur framework. Utilisez l'organigramme ci-dessous comme première étape pour guider votre processus de prise de décision.

Je suis convaincu que vous trouverez le cadre de mise à l'échelle qui convient à l'expérience, à l'approche, au budget et aux produits de votre organisation parmi ceux présentés ici. Quel que soit le framework que vous choisissez, il est essentiel de ne pas vous précipiter, d'évoluer progressivement pour minimiser les perturbations et de planifier les modifications bien à l'avance.

Avez-vous utilisé ces cadres dans l'une de vos activités de mise à l'échelle ? Parlez-nous de vos expériences dans la section des commentaires.