Large Solution : comment réussir le mariage de l’Agilité à l’échelle et de la gestion de projet classique ?

Cet article présente un retour d’expérience de la mise en œuvre dans le groupe Orange de mécanismes de type « Large Solution » SAFe adaptés pour non seulement coordonner des trains entre eux mais aussi les projets les intersectant.

La mise en place de l’Agilité à l’échelle dans une organisation se fait toujours de manière progressive si bien que l’Agilité à l’échelle et la gestion de projet classique doivent cohabiter un temps. Or cette cohabitation n’est pas toujours des plus heureuses.

« Large Solution », de quoi parle-t-on ?

Les « trains de solution » sont des structures organisationnelles décrites dans le framework SAFe et en particulier dans la core competency « enterprise solution delivery ». Ils sont utilisés pour construire et maintenir tout ou partie de solutions vastes et complexes (Large Solution), porteuses de valeur, qui nécessitent de coordonner, aligner, synchroniser le travail de plusieurs centaines voire, de milliers de collaborateurs et souvent également de fournisseurs.

Au sein d’un train de solution, les collaborateurs sont regroupés dans des trains de Release Agile (ART, que nous nommerons train dans la suite de l’article) composés chacun en moyenne de 8 à 12 équipes pluridisciplinaires pour un total par train représentant entre 50 et 125 personnes.

Un train de Solution permet d’aligner les trains de son périmètre sur une mission partagée en utilisant une vision de niveau Solution, un backlog Solution et en alignant les Program Increment (PI) des trains sur une même cadence, un même début et une même fin.

Des cérémonies dédiées de niveau « Large Solution » viennent supporter la coordination, la synchronisation et l’alignement entre les trains.

En particulier :

• Les cérémonies de Pré-PI Planning et de Post-PI Planning servent de wrapper pour la planification des PI Planning au niveau des trains où a lieu la planification détaillée des travaux à réaliser. Ils permettent de construire un plan unifié pour le prochain incrément sur le périmètre de la « Large Solution ».

– Le pré-PI est utilisé pour s’aligner sur le contexte, la vision métier, les fonctionnalités de haut niveau à développer (nommées capabilities) et les features candidates pour le PI Planning de chaque train.

– Le Post-PI Planning permet de consolider une photo du plan de création de valeur du train de solution sur la base des résultats des PI Planning de chaque train en analysant les dépendances. Il permet également d’acter des actions de résolution de problème et d’atténuation des risques.

• Les cérémonies de « Solution Train Sync » permettent une coordination entre les trains.
• Les cérémonies « d’Architect Sync » permettent de coordonner, aligner et synchroniser la construction de l’architecture intentionnelle tout en prenant en compte l’architecture émergente.
• Enfin les Solution Démos et l’inspect & adapt de niveau « Large Solution » adressent les mêmes objectifs que leurs pendants au niveau des trains de Release Agile.

De nouveaux rôles sont également introduits : le Solution Train Engineer, le Solution Management et le Solution Arch/Eng. Ces rôles sont les pendants des rôles de Release Train Engineer, de Product Management et de System Arch/Eng mais au niveau Large Solution.

Contexte de mise en place du train Large Solution « Divertissement »

Sur le périmètre de la chaine de valeur « Divertissement » incluant entre autres la TV d’Orange, le système d’information est particulièrement complexe et la construction et maintenance des solutions occupent plus de 300 personnes.

Malgré un alignement des chaînes de développement avec les flux de valeur, nous savions dès le départ que le couplage entre les trains serait important.

D’une part, car un des flux de valeur opérationnel – la « Découverte de contenu » – est transverse à plusieurs flux de valeur de fourniture de service et d’autre part, car de nombreux composants sont communs à plusieurs flux de valeur. Sans doute la loi de Conway n’est pas complétement innocente dans l’histoire, mais de la factorisation urbanistique est également à l’œuvre. La mise en œuvre de micro-services en cours devrait d’ailleurs diminuer ce couplage et permettre une meilleure modularité des interfaces utilisateur.

Compte tenu de ce couplage, nous avions prévu dès le départ de lancer un train Solution lors de la mise en œuvre du deuxième train du périmètre. Bien sûr les mécanismes « Large Solution » permettent de coordonner les trains du périmètre mais aussi de partager une vision et une roadmap communes !

Cela dit, un autre élément de contexte est également à considérer avec attention. En effet, nous mettons progressivement en œuvre de l’agilité à l’échelle sur ce périmètre mais il existe encore de très nombreuses chaînes de développement pour lesquelles des trains n’ont pas été lancés et qui sont restées avec des mécanismes de gestion de projet classique.

Or compte tenu du couplage, ces projets viennent intersecter les 2 trains du périmètre.

Nous avons donc décidé d’ajuster les mécanismes « Large Solution » pour non seulement coordonner des trains entre eux, mais aussi les projets les intersectant ainsi que certains composants clés non intégrés à ces trains.

Le train « Large Solution Divertissement » a été lancé en décembre 2021. Il est actuellement constitué de 2 trains (dont un gros train Découverte de 120 ETP), de 4 équipes isolées et d’une dizaine de projets intersectant les trains. Il regroupe plus de 200 personnes.

Mise en œuvre de mécanismes « Large Solution » adaptés

Les mécanismes « Large Solution » ont donc été adaptés pour ne pas uniquement gérer les dépendances entre les trains mais aussi pour concilier la gestion de projet classique et l’agilité coordonnée. En particulier pour aligner les attentes des demandeurs (projets et trains) avec la capacité de production des producteurs (trains ainsi que certains composants hors trains) et en prenant en compte la priorisation par la valeur à tous les niveaux.

Bref, fournir des mécanismes permettant :

• d’aligner les roadmaps des trains et des projets;

• d’éviter que les projets continuent à organiser des comités projets avec les équipes unitaires, ce qui induirait un double pilotage;

• de fournir les outils permettant de donner la visibilité nécessaire aux projets.

Les rôles de la « Large Solution », que ce soient le Solution Manager, le Solution Train Engineer ou le Solution Architect ont été très peu adaptés. A noter quand même, un Solution Manager est le porteur business du périmètre : cela fait sens car c’est cette personne qui porte la vision métier et qui est la plus à même d’arbitrer. Un inconvénient néanmoins est sa faible disponibilité.

Nous avons donc aménagé ce rôle de manière à ne le solliciter que pour des activités à forte valeur ajoutée.

Concernant le backlog du train de solution, des « capabilities » sont bien créées afin d’adresser des fonctionnalités à développer communes aux deux trains. Néanmoins, les projets travaillant au niveau features, pour l’instant le board de niveau « Large Solution » permettant de piloter et visualiser le flux de création de valeur contient les features et non les capabilities, ce qui diffère de la proposition standard du framework SAFe.

Concernant les cérémonies, nous avons déjà mis en œuvre les « Pré PI Planning », les « Post Pl Planning », les « Solution Train Sync ». Les « Architect Sync » sont en cours de déploiement et pour l’instant, nous n’avons pas mis en œuvre de « Solutions démos ».

Lors du premier incrément, le pré-PI Planning a été planifié pendant l’itération Innovation and Planning (IP). Le post PI-Planning a été planifié exceptionnellement ultérieurement mais nous avons bien la volonté de l’intégrer dans l’IP pour les prochains incréments.

Mais le plus intéressant est d’étudier comment nous avons ajusté le Pré-PI Planning, le Post-PI Planning et le Solution Train Sync. Les mécanismes mis en œuvre permettent d’aligner la roadmap des projets et la roadmap des trains, assurer la coordination trains-trains et trains-projets tout en permettant un arbitrage de manière naturelle par le porteur business.

Ajustement du Pré-PI Planning :

Les objectifs de nos Pre-PI Planning ajustés sont les suivants :

• Aligner les roadmaps trains et projets en amont des PI plannings des trains,

• S’assurer que les producteurs (trains et équipes isolées) ont bien connaissance de toutes les features que les demandeurs (trains et projets) souhaitent voir implémenter pour le prochain incrément. Ces features correspondent soit à des dépendances entre les parties, soit à l’implémentation de fonctionnalités portées par le demandeur mais nécessitant « l’usine » du producteur pour les mettre en œuvre,

• Identifier le niveau de confiance d’embarquement de ces features dans le prochain incrément et arbitrer au besoin.

La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :

• Identification des projets métiers et des projets de rénovation intersectant les trains et les équipes isolées (hors trains);

• Construction des roadmaps trains et projets;

• Identification par les demandeurs des features qu’ils souhaitent voir implémenter dans le prochain incrément par un producteur et identification de leur priorité en utilisant l’approche par WSJF (Weighted Shortest Job First) de SAFe au niveau features.

Les participants au Pré-PI Planning sont les suivants :

• Solution Manager, Solution Train Engineer, Solution Architect;
• RTE, Product Manager et System Arch/Eng des trains;
• Responsable Projets;
• Représentants des équipes isolées (hors trains);
• BO (Business Owners) du périmètre.

La cérémonie dure 3 heures et son agenda est le suivant :

• Présentation des roadmaps et identification d’éventuelles incohérences,

• Identification des features candidates pour le prochain incrément :

– Chaque demandeur présente les features qu’il souhaite voir réaliser par chaque producteur en précisant la priorité. Il y a, bien sûr, un arbitrage possible par le Solution Manager et les BO.

– Chaque producteur identifie le niveau de confiance sur la planification de la feature dans l’incrément.

Le board est une matrice demandeurs X producteurs et chaque feature est positionnée sur la colonne correspondant au niveau de confiance de planification de la feature dans l’incrément : niveau de confiance fort, niveau de confiance incertain, non candidat pour l’incrément.

La complexité principale de la cérémonie ajustée consiste à adresser un volume important d’informations en un temps limité. D’autant plus que comme précisé précédemment, nous travaillons au niveau features et non capabilities. Néanmoins, avec une gestion dynamique de la cérémonie, nous avons systématiquement tenu le timing.

Ajustement du Post-PI Planning :

Les objectifs de nos Post-PI Planning ajustés sont les suivants :

• Une fois achevés les PI planning des trains, consolider une photo des features intégrées à l’incrément et celles qui ne le sont pas afin d’analyser et partager les impacts pour les demandeurs;

• Identifier par demandeur, les dépendances entre les features implémentées par un producteur et les features non implémentées par ce producteur afin de pouvoir analyser les impacts d’un éventuel retard d’implémentation d’une feature sur les features en dépendances (une partie des dépendances a déjà été identifiée lors des PI Planning, mais de nouvelles dépendances sont en général identifiées, en particulier pour les demandes liées aux projets),

• Identifier les risques et problèmes associés au plan et les actions d’atténuation des risques / de résolution de problèmes associés (consolidation des risques et problèmes identifiés lors des PI Planning et identification de risques et problèmes complémentaires prenant en compte la vision globale),

• Mettre en œuvre l’amélioration continue via une rétrospective du fonctionnement du train de solution.

La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :

• Positionnement par chaque producteur de l’itération dans lesquels les features sont planifiées (en fait, l’outillage permet désormais de le faire automatiquement à partir de JIRA);

• Identification des dépendances entre les features.

Les participants au Post-PI Planning sont les mêmes que pour le Pré PI Planning.

La cérémonie dure 3 heures et son agenda est le suivant :

• Présentation du Plan : chaque producteur (train ou équipe hors train) fait un statut sur les features planifiées et non planifiées en précisant les features liées à un « uncommited objective » (features sur lesquelles il y a un risque qu’on ne puisse pas les faire du tout ou en partie seulement, souvent à cause de dépendances). Puis chaque Demandeur présente les dépendances avec les features externes au demandeur et avec les jalons métiers imposés (contractuel, évènement…) ;

• Identification des risques, problèmes et plan d’actions;

• Vote de confiance sur l’ensemble des plans présentés;

• Rétrospective du train de solution.

Le board est une matrice demandeur X producteur et les features sont positionnées sur les colonnes correspondant à l’itération.

Les dépendances sont présentées dans le contexte d’un couple demandeur-producteur comme présenté dans le schéma ci-dessous. C’est un choix qui ne permet pas de bien visualiser la transitivité des dépendances mais qui a le mérite de gagner en lisibilité.

Ajustement des Solution train sync :

Les objectifs de nos Solution train Sync ajustés sont les suivants :

• Identifier et partager les décalages et leurs impacts;

• Arbitrer si nécessaire;

• Identifier les risques et les problèmes. Planifier et suivre les actions d’atténuation des risques et de résolution des problèmes;

• Commencer à créer un alignement sur les nouveaux besoins au niveau solution en amont du pre PI Planning.

La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :

• Déplacement des features décalées dans le Solution board (automatiquement à partir de JIRA);

• Identification des risques et problèmes ou points notables à adresser.

Les participants sont les mêmes que pour le Pré PI Planning. La durée est d’une heure et la fréquence est bimensuelle.

Mise en place d’un outil dédié

L’utilisation de Klaxoon s’est avérée non appropriée pour les cérémonies de Solution train sync. D’une part, compte tenu de la taille de la matrice, il était difficile de naviguer efficacement. Et d’autre part, les features n’étaient pas synchronisées avec JIRA.

Nous avons donc construit un outil basé sur Excel et synchronisé avec JIRA par appel REST. L’outil est configurable pour prendre en compte la non-homogénéisation des pratiques JIRA. Il permet de prendre la référence après les PI Planning et de mettre en avant les écarts par rapport au plan.

L’outil est désormais utilisé par le Train de Solution et tient toutes ses promesses ! Il a été un élément clé pour le succès de la « Large Solution ».

Conclusion

Nous avons donc ajusté les mécanismes de « Large Solution » en adaptant la proposition standard de SAFe. Et la solution mise en œuvre s’est avérée répondre parfaitement aux besoins en permettant non seulement de coordonner les trains de release entre eux mais aussi les projets les intersectant. Elle évite un double pilotage Projets/Trains, demande peu de bande passante aux principaux acteurs et est peu coûteuse à mettre en œuvre.

Bien sûr, le train de Solution vient de naître et de nombreux sujets restent à améliorer.

En particulier, la granularité des objets du board est fine ce qui induit une complexité de gestion. Sans doute faudra t’il envisager d’introduire complétement les capabilities.

D’autre part, nous ne disposons pas encore des outils nécessaires pour prendre en compte en temps réel la vélocité des équipes lors d’un arbitrage en particulier si les features concernées impactent un nombre important d’équipes.

Quoiqu’il en soit malgré ces quelques axes d’amélioration, le train Large Solution Divertissement est clairement un succès !

Par Stéphane Déprès, Consultant coach chaine de valeur au sein du Centre d’Excellence Agile Orange France

Avec la contribution et revue de Stéphane Bos, Solution Train Engineer du « train Large Solution Divertissement »