Article d'expert
Par Stéphane Déprès
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.
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.
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.
– 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.
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.
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.
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 :
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.
Les objectifs de nos Pre-PI Planning ajustés sont les suivants :
La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :
Les participants au Pré-PI Planning sont les suivants :
La cérémonie dure 3 heures et son agenda est le suivant :
– 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.
Les objectifs de nos Post-PI Planning ajustés sont les suivants :
La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :
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 :
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é.
Les objectifs de nos Solution train Sync ajustés sont les suivants :
La cérémonie est préparée à l’avance et les travaux préparatoires suivants sont demandés :
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.
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 ».
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 !
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 »
Envoyer à un ami