Comment choisir le bon framework d’agilité à l’échelle ?

Pour rester compétitive, une entreprise a besoin de délivrer toujours plus rapidement des solutions informatiques de plus en plus complexes.

Votre entreprise ne sait plus répondre à ce double enjeu de complexité et de rapidité ? Il est peut-être temps de passer à l’agilité à l’échelle ! 

Dans cet article, nous vous expliquerons à quoi sert l’agilité à l’échelle et quels sont ses prérequis.

Nous vous présenterons succinctement 3 frameworks du marché à travers leurs spécificités puis nous vous aiderons à faire le meilleur choix de framework en fonction de votre contexte.

Principes de l’agilité à l’échelle

Si vous avez déjà travaillé au sein d’une équipe agile, sans doute avez-vous remarqué que les petites équipes (moins de 8 personnes) communiquent mieux et sont plus productives.

À l’inverse, plus une équipe est grande et plus les canaux de communication entre ses membres sont nombreux.

Dans ces conditions, il est difficile pour l’équipe de devenir hautement performante.

Pour conjuguer complexité et rapidité, tout en gardant une taille d’équipe optimale (moins de 8 personnes), il est nécessaire de construire un dispositif constitué de plusieurs équipes agiles.

Aligner plusieurs équipes autour d’un objectif commun, optimiser la collaboration, enrichir fréquemment une solution complexe avec des nouvelles fonctionnalités, tels sont les enjeux de l’agilité à l’échelle.

Le cadencement, la synchronisation et l’alignement sont des principes structurants sur lesquels repose l’ensemble des frameworks d’agilité à l’échelle du marché.

1) Cadencement et synchronisation

Le cadencement et la synchronisation permettent à chaque fin d’itération :

• Une intégration au plus tôt du travail fourni par l’ensemble des équipes
• Une démonstration d’un produit unique et commun

D’un point de vue pratique, définissez un agenda commun dans lequel vos itérations démarrent et terminent toutes au même moment pour toutes vos équipes.

Nous vous conseillons de pratiquer des itérations de 2 semaines, le grand maximum étant 3 semaines.

2) Alignement

Le principe d’alignement mobilise toutes vos équipes agiles autour d’un objectif commun et évite que les équipes partent dans des directions différentes.

Je vous conseille d’aligner vos équipes sur 3 axes :

• Un axe business / fonctionnel pour partager vos enjeux métiers,
• Un axe méthodologique / organisationnel pour homogénéiser les manières de travailler,
• Un axe technologique pour partager des standards communs.

Prérequis à l’agilité à l’échelle

Une entreprise qui s’engage sur le chemin de l’agilité ne le fait jamais en mode « big bang ». 

L’agilité et encore plus l’agilité à l’échelle apporte des changements importants dans les modes de fonctionnement.

De manière générale, une entreprise suit une feuille de route ou roadmap de transformation agile, composée des grandes étapes suivantes :

Il est très important de ne pas griller les étapes.

Si vous expérimentez l’agilité à l’échelle avant même d’avoir résolu les freins à l’agilité d’équipe, vous allez simplement porter les problèmes à l’échelle et ils seront alors bien plus difficiles à résoudre.

Je vous conseille d’adopter une approche progressive qui permet à votre entreprise d’apprendre en marchant et d’adopter l’agilité à son rythme.

Pourquoi le choix du framework est stratégique 

Si vous choisissez le framework le plus adapté à votre contexte, vous pourrez en tirer tous les bénéfices.

À l’inverse, si votre contexte vous oblige à tordre les pratiques proposées par le framework au point de dénaturer les principes, alors votre choix n’est probablement pas le bon.

Dans ce cas, vous n’obtiendrez pas le niveau de performance attendu et vos équipes auront du mal à adopter le nouveau cadre. 

Vous allez embarquer un nombre très important de collaborateurs dans cette nouvelle aventure et modifier en profondeur les manières de travailler.

Pour que chacun comprenne son nouveau rôle, vous allez devoir former massivement et aussi accompagner tout le monde pendant plusieurs mois, jusqu’à autonomie.

Cela suppose aussi d’accompagner l’évolution des pratiques collaboratives et la structuration progressive des flux de travail au sein des équipes.

Tout cela représente un coût très important pour l’entreprise.

Mieux vaut donc réfléchir à deux fois avant de choisir votre framework d’agilité à l’échelle !

Quel que soit le framework utilisé, je vous conseille de privilégier une croissance organique, c’est-à-dire d’ajouter des nouvelles équipes au fur et à mesure.

Cela vous évitera de nuire à l’efficacité d’origine et à la dynamique globale qui peuvent être fragilisées par ces nouvelles manières de travailler.

Stratégies utilisées par les frameworks d’agilité à l’échelle

En partant du principe que votre entreprise a déjà entamé une transformation agile et que beaucoup d’équipes travaillent déjà en agile, le challenge qui vous est proposé est de réussir à délivrer rapidement une solution complexe qui nécessite la collaboration de plusieurs équipes agiles.

Voyons d’un point de vue méthodologique quelles stratégies peuvent être mises en œuvre pour réussir une telle collaboration.

1) Stratégies d’organisation des rôles pour l’agilité à l’échelle

Il existe 3 stratégies possibles autour des rôles pour garantir l’alignement de plusieurs équipes :

1.1) Stratégie 1 : Un Product Owner unique et un Scrum Master unique pour plusieurs équipes

Avantages : 

• Vision métier et priorisation portées par un acteur unique
• Réduction des coûts (moins de Product Owner et moins de Scrum Master)

Inconvénients :

• Surcharge potentielle du PO unique, car il doit alimenter plusieurs équipes
• Surcharge potentielle du SM unique si les équipes ne sont pas matures sur l’agilité

1.2) Stratégie 2 : Un des Product Owner et un des Scrum Master prennent le lead pour aligner les équipes

Avantages : 

• Équipes inchangées, pas de perturbations
• Pas de surcoût (effectif constant)

Inconvénients :

• Conflit potentiel de légitimité entre les PO pour prendre le lead
• Conflit potentiel de légitimité entre les SM pour prendre le lead

1.3) Stratégie 3 : Un rôle de « super Product Owner » incarné par une nouvelle personne et un rôle de « super Scrum Master » incarné par une nouvelle personne

Avantages : 

• Équipes inchangées, pas de perturbations
• Des personnes complètement dédiées à l’alignement fonctionnel et méthodologique

Inconvénients :

• Surcoût (2 personnes en plus)
• L’introduction de rôles supplémentaires ajoute une complexité dans la compréhension des rôles et responsabilités de chacun
• Le « super Product Owner » définit la vision, les PO se contentent d’y contribuer
• Le « super Scrum Master » peut se retrouver décorrélé du terrain

2) Stratégies de coordination via les évènements agiles à l’échelle

Les événements agiles à l’échelle participent aussi à l’alignement des équipes.

2 stratégies sont possibles concernant la manière d’organiser ces évènements :

2.1) Stratégie 1 : Événements à l’échelle avec l’ensemble des membres de toutes les équipes

Avantages : 

• Sentiment d’appartenance à un ensemble d’équipes
• Communication en face à face avec l’ensemble des acteurs
• Traitement des dépendances efficaces grâce à la présence de tous

Inconvénients :

• Coût élevé
• Difficulté à trouver des locaux adéquats pour réunir tout le monde

Pour bénéficier des avantages de cette stratégie tout en limitant les inconvénients, certains frameworks jouent sur la fréquence des évènements à l’échelle.

2.2) Stratégie 2 : Événements à l’échelle avec uniquement des représentants de chaque équipe

Avantages : 

• Coût faible

Inconvénients :

• Manque de sentiment d’appartenance à un ensemble d’équipes
• Perte d’informations puisque tout le monde n’est pas présent

Spécificités des frameworks d’agilité à l’échelle

Nous vous proposons d’étudier un ensemble volontairement limité de 3 frameworks plébiscités par les entreprises : LeSS, Scrum@Scale et SAFe.

Comme ils couvrent les différentes stratégies présentées au chapitre précédent, nous pensons qu’ils répondront à la diversité des contextes de vos périmètres :

(*) L’horizon de planification est l’intervalle de temps pour lequel les équipes s’engagent ensemble sur les travaux qu’elles vont réaliser.

Cet engagement est défini lors d’un événement à l’échelle de planification.

Nous vous proposons d’étudier maintenant plus en détails les spécificités de ces 3 frameworks pour vous aider à faire le meilleur choix possible en fonction de votre contexte.

1) Spécificités du framework LeSS (Large Scale Scrum)

La devise de LeSS est : « More with LeSS » (faire plus avec moins). LeSS est le framework le plus léger.

Rôles :

• Un unique Product Owner aligne l’ensemble des équipes avec un Product Backlog unique

Événements :

• Un Scrum Master est en charge de 3 équipes maximum
• Un Sprint Planning en 2 parties : 
  • une partie commune avec tout le monde
  • un Sprint Planning par équipe
• Une Sprint Review commune pour montrer un produit unique
• Une Sprint Retrospective en 2 parties : 
  • une par équipe
  • une partie commune avec tout le monde pour traiter les difficultés communes

2) Spécificités du framework Scrum@Scale

Scrum@Scale est un cadre de travail léger dans lequel un réseau d’équipes Scrum opèrent ensemble pour adresser des problèmes complexes. Scrum@Scale décrit le minimum requis pour mettre Scrum à l’échelle.

Rôles :

• Une équipe d’équipes (appelée Scrum of Scrums) optimale est composée de 4 à 5 équipes. Chaque équipe est composée de 4 à 6 personnes.
• Un « Scrum of Scrums Master » joué par un Scrum Master d’une équipe ou par une personne spécifique aligne l’ensemble des équipes et facilite les évènements à l’échelle
• Un « Chief Product Owner » joué par un Product Owner d’une équipe ou par une personne spécifique, propriétaire d’un Product Backlog unique, s’assure avec les PO que les priorités des équipes sont alignées sur les besoins des clients

Événements :

• Un « Scaled Sprint Planning » avec l’ensemble des PO et des SM
• Un « Scaled Daily Scrum » avec un représentant au moins de chaque équipe
• Une « Scaled Sprint Review » avec le « Chief Product Owner » et ses PO
• Une « Scaled rétrospective » avec le « Scrum of Scrums Master » et ses SM

3) Spécificités du framework SAFe (Scaled Agile Framework)

Le framework SAFe est un cadre très détaillé. Il porte l’ensemble des concepts de Scrum (rôles, évènements, artefacts) à l’échelle :

Dans SAFe, une équipe d’équipes est appelée un train.

Par analogie avec un train de voyageurs, vous pouvez considérer que chaque wagon du train représente une équipe.

Rôles :

• Un PM (Product Management) garant de l’alignement métier / fonctionnel des équipes
• Un RTE (Release Train Engineer) garant de l’alignement méthodologique des équipes
• Un SA (System Architect) garant de l’alignement technique des équipes

Pour reprendre l’analogie du train de voyageurs, ces 3 rôles conduisent le train. Ils donnent la direction fonctionnelle (PM), méthodologique(RTE) et technique (SA).

Evénements :

• Une planification tous ensemble pendant 2 jours qui fait le succès de ce framework
• Un Scrum of Scrums hebdomadaire (RTE + SM) et un PO Sync (PM +PO) hebdomadaire pour vérifier que le train avance correctement

Autres spécificités :

• Contrairement aux 2 autres frameworks, la planification ne se fait pas pour une itération mais pour un « intervalle », composé de 4 à 6 itérations de 2 semaines. Cela permet notamment de limiter la fréquence de l'événement
• Chaque équipe possède son propre backlog de User Story. De plus, un backlog de niveau train est composé de features et chaque feature se décompose en User Story qui alimentent les backlogs des équipes.

Choix du framework d’agilité à l’échelle

Le déploiement de l’agilité à l’échelle est une approche incrémentale. Périmètre par périmètre, chaque expérimentation va permettre à votre entreprise d’apprendre en marchant et de s’améliorer en continu.

Je vous conseille de choisir un premier périmètre fonctionnel abordable qui met en jeu un nombre limité d’équipes et un faible niveau de dépendances entre celles-ci.

Vous pourrez ainsi faire le choix d’un framework léger qui permettra à vos équipes d’intégrer à leur rythme les premiers principes d’agilité à l’échelle.

1) 4 questions essentielles pour faire le bon choix

Pour faire un choix éclairé de framework pour votre périmètre, 4 critères importants sont à prendre en compte.

Pour mieux vous aider dans l’évaluation de ces critères, nous vous proposons de répondre aux questions suivantes :

1.1) Combien d’équipes vont être amenées à collaborer ?

Votre solution complexe qui apporte de la valeur à vos utilisateurs met certainement en jeu différentes applications et différents langages de programmation.

Commencez par cartographier vos applications et faites l’état des lieux des équipes qui développent ces applications.

Prenons l’exemple d’une solution complexe qui permet de gérer les prêts dans un organisme bancaire.

Dans un premier temps, il faut recenser l’ensemble des étapes qui constituent le processus de gestion des prêts bancaires.

Dans un second temps, il faut lister les applications qui soutiennent ces étapes du processus.

Enfin, il faut identifier pour chaque application les équipes qui les développent.

Dans notre exemple, 5 équipes sont nécessaires pour adresser l’intégralité du processus de gestion des prêts bancaires :

• Les équipes 1 et 2 développent l’application qui permet à un client de faire une demande de prêt
• L’équipe 3 est responsable d’une application stratégique qui permet de décider ou non d’accorder un prêt 
• L’équipe 4 gère l’application qui permet la mise en place du prêt accordé (déblocage de l’argent et déclenchement des mensualités)
• Enfin, l’équipe 5 s’occupe d’une application qui permet le remboursement d’un prêt et sa clôture.

Pour assurer la compétitivité de l’organisme bancaire sur ce marché des prêts fortement concurrentiel, la collaboration entre ces 5 équipes est un élément clef !

Vous avez peut-être prévu de commencer avec uniquement quelques équipes, mais prenez surtout en compte le nombre d’équipes prévues à la cible afin d’éviter de devoir changer de framework en cours de route.

1.2) Quel est le niveau de dépendances entre vos équipes ?

En théorie, vous avez constitué vos équipes pour que chacune soit en capacité à délivrer de la valeur indépendamment des autres.

Malheureusement, en pratique, la forte complexité de votre système d’informations et la diversité des technologies de votre parc applicatif rendent illusoire l’indépendance totale de vos équipes.

Pour mesurer le niveau de dépendances entre les équipes, il est nécessaire de connaître les dépendances entre les applications dont elles ont la responsabilité.

Mesurer le niveau de dépendance entre 2 applications peut se faire en utilisant par exemple les règles suivantes :

• Niveau FORT : modifier la première application implique souvent de modifier la deuxième. Les deux applications sont fortement imbriquées.
• Niveau MOYEN : les applications échangent des données par web service.
• Niveau FAIBLE : les applications échangent peu de données.

Reprenons notre exemple de gestion des prêts. Interroger les équipes est une bonne pratique pour connaître le niveau de dépendances entre les différentes applications :

Au final, 3 équipes sur 5 sont fortement dépendantes entre elles. Nous pouvons considérer que le niveau de dépendances au global dans le dispositif est plutôt FORT.

1.3) Quel est le niveau de maturité agile de vos équipes ?

Rappelez-vous, si la maturité agile de vos équipes est faible, il est peut-être trop tôt pour passer à l’agilité à l’échelle !

Pour mesurer la maturité agile, vous pouvez vous aider d’une grille de maturité.

Dans notre exemple ci-dessus, nous pouvons considérer que le dispositif possède un FORT niveau de maturité.

1.4) Quel est votre horizon de planification ? 1 sprint ? Plusieurs sprints ?

L’horizon de planification est la durée pour laquelle votre dispositif s’engage à réaliser des travaux.

Durant cet horizon de planification, le périmètre est protégé : il n’est donc pas possible d’embarquer des changements en cours de route pendant cette durée.

Connaissant votre marché et le niveau de réactivité qu’il nécessite, est-il acceptable d’attendre le prochain trimestre pour embarquer des nouvelles fonctionnalités ou bien faut-il être plus réactif ?

2) Outil d’aide à la décision

Pour vous guider dans votre choix de framework, je vous propose d’utiliser l’outil d’aide à la décision ci-dessous :

Grille de lecture :

Si vous avez moins de 5 équipes :

• LeSS et Scrum@Scale sont suffisants car le coût engendré par la mise en place du framework SAFe ne vous permettra pas d’obtenir un bon retour sur investissement
• Préférez Scrum@Scale si vos équipes ont peu de dépendances. Sinon, préférez LeSS car les évènements à l’échelle de LeSS réunissent tout le monde et permettront donc de faciliter la collaboration entre vos équipes. Attention néanmoins au niveau de maturité de vos équipes. LeSS limite le nombre de rôles donc vos équipes doivent posséder un fort niveau de maturité.

Si vous avez plus de 5 équipes :

• LeSS reste pertinent jusqu’à 8 équipes sauf si vos équipes sont fortement dépendantes. Dans ce cas, nous vous conseillons de privilégier SAFe qui embarque des outils et des pratiques spécifiques pour traiter un grand nombre de dépendances.
• Avant d’adopter SAFe, vérifiez bien que l’horizon de planification est compatible avec les évolutions de votre marché. Les priorités ne sont pas censées changer pendant les 4 à 6 itérations préconisées par SAFe, ce qui peut rendre moins « agile » votre dispositif. Par ailleurs, retenez que le coût d’implémentation de SAFe est élevé. Il doit donc être choisi pour des bonnes raisons.

Conclusion

N’oubliez pas que la mise en place d’un framework d’agilité à l’échelle et son utilisation quotidienne entraîne des coûts importants pour votre entreprise (formation, nouveaux rôles et évènements).

Pour assurer un bon retour sur investissement, le choix du framework le plus adapté à vos besoins est crucial.

Les frameworks du marché sont de véritables capitalisations de savoir-faire.

Ils ont fait leurs preuves sur le terrain et constituent des sources d’inspiration.

Chaque framework comprend un certain nombre de principes et de pratiques.

Le respect des principes est important mais les pratiques sont à adapter à votre contexte.

Si vous êtes amenés à tordre les pratiques de votre framework au point de dénaturer ses principes, vous faites probablement fausse route.

Dans ce cas, reposez-vous les 4 questions essentielles.