Retours d’expérience croisés de la mise en œuvre de quatre Large Solutions
Chez Inspearit, nous accompagnons de plus en plus de mises en œuvre de « Large Solution » SAFe: au cours de ces 2 dernières années, nous (Christelle Boulan, Stéphane Déprès, Camille Placier et Sylvain Hochart) avons ainsi accompagné 4 Large Solutions, dans leurs créations et mises en œuvre, pour nos clients dans les domaines des Télécoms, de l’Assurance et du Transport aérien.
Il nous a paru intéressant de croiser nos retours d’expérience, afin d’identifier les adaptations du modèle qui se sont avérées pertinentes dans chacun de ces 4 contextes… Ces adaptations concernent les rôles, événements et artefacts du niveau Large Solution. Dans cet article, nous allons vous partager quelques éléments intéressants issus de la mise en commun de nos différentes expériences.
Les nouveaux rôles impliqués dans les Large Solutions
SAFe définit 3 nouveaux rôles pour guider une Large Solution : le STE (Solution Train Engineer), le Solution Manager et le Solution Architect.
Chacun de ces rôles peut être tenu soit par une personne seule, soit par un collectif comprenant dans ce cas un leader pouvant arbitrer en dernier recours. Nous avons pu expérimenter ces différents cas dans nos mises en œuvre, puisque :
- Dans un premier cas, nous avons mis en œuvre un triptyque STE/SolM/SolA constitué de 3 personnes à temps plein sur ce rôle.
- Dans un second cas, nous avons constitué un collectif de 3 personnes pour assurer le rôle de Solution Manager et un autre collectif de 3 personnes pour le rôle de Solution Architect.
- Dans un troisième cas, le rôle de STE était assuré par le collectif des RTEs des trains accompagnés, chaque RTE assurant à tour de rôle la facilitation des événements du niveau Large Solution.
L’analyse de nos missions respectives révèle une variabilité importante du temps consacré aux rôles de la Large Solution, selon la capacité à déléguer aux trains. Dans le cas extrême, les membres du triptyque ne consacraient qu’environ 10% de leur temps à leur rôle, uniquement pour faciliter les événements de niveau Large Solution, le reste des activités étant délégué le plus possible aux rôles des trains. A contrario, les charges deviennent plus importantes pour ces 3 rôles (entre 50 et 100%) lorsque les trains ne fonctionnent pas encore avec un niveau d’autonomie suffisant.
Les artefacts et la notion de « Capabilities »
Dans le cadre d’une Large Solution, SAFe introduit la notion de « Capabilities », permettant de décrire les besoins fonctionnels et techniques de la solution complexe requérant le travail collaboratif et complémentaire de plusieurs trains agile de livraison (ART). Ces « capabilities » permettent également de matérialiser les dépendances de « Features » (au sens SAFe) entre les trains composant la Large Solution. Pour adresser plus particulièrement la question des dépendances, nous avons mis en œuvre ce niveau supplémentaire de Backlog de façon différente sur les 4 Large Solutions accompagnées, pour l’adapter au mieux à chacun des contextes : le schéma ci-dessous illustre les différentes possibilités.
Les événements propres aux Large Solutions
En ce qui concerne les événements propres au niveau Large Solution, quelques éléments intéressants se dégagent :
Durée des Pré-planning et Coordinate and deliver
- Sur nos 4 mises en œuvre, nous avons raccourci de moitié la durée standard proposée pour les événements « Pré-planning » et « Coordinate and deliver » pour tenir compte de la difficulté des organisations accompagnées à adapter leurs plans tardivement : cela s’est traduit par une résolution anticipée de risques, dépendances et problèmes majeurs en amont de cet événement, pour éviter les « mauvaises surprises » de dernière minute.
Les « Solution Demo » s’ajoutent aux « System Demo » menées par chaque ART, en permettant de recueillir du feedback sur l’intégration des développements de tous les trains et fournisseurs de la Large Solution.
Nous avons implémenté différentes pratiques :
- La « Solution Demo » démontre l’ensemble des réalisations, qu’elles soient mono ou multi-trains.
- La « Solution Demo » ne démontre que les réalisations multi-trains. Elle est suivie immédiatement par les « System Demo » de trains pour démontrer les Features mono-train. Dans ce cas, les System Demos s’effectuent :
- soit à tour de rôle devant l’ensemble des acteurs de la Large Solution,
- soit simultanément, avec une audience limitée aux acteurs de chaque train.
- L’ évènement « Inspect and adapt » de niveau solution est particulièrement complexe à organiser. Nous mettons généralement en œuvre des pratiques alternatives : le plus souvent, une équipe est dédiée à la résolution des problèmes systémiques et à l’amélioration continue. Dans un cas, des rétrospectives Large Solution, avec un dispositif léger, sont organisées tous les 6 mois.
- Sur une des Large Solution de notre retour d’expérience, nous avons au départ expérimenté un format commun des « Inspect & adapt » de niveau train. Cela étant apparu très complexe à organiser d’un point de vue logistique (alignement de tous les trains sur un même format et déroulement), l’autonomie a ensuite été redonné aux trains pour organiser librement cet événement.
Nous avons expérimenté peu de variantes sur cet événement. Dans un cas, nous ne l’avons pas mis en œuvre car le Solution Manager assistait aux ART-Sync des 3 trains de la Large Solution et assurait la coordination par des points ad-hoc lorsque nécessaire.
Ce dernier événement entre souvent en conflit avec des événements existants, tels que des comités ou réunions de département d’architecture. Pour ne pas alourdir la gouvernance existante, il est possible de ne pas le déployer… à condition qu’un Solution Architect dédié à la Large Solution soit identifié et assure le lien entre les instances existantes et la Large Solution.
Conclusion
Le déploiement d’une Large Solution, au-delà de synchroniser plusieurs trains, nécessite de nouveaux rôles, événements et artefacts, ce qui introduit une complexité additionnelle pour instancier et adapter le modèle.
Vous préparez le lancement d’une Large Solution ? Voici notre conseil : essayez en première intention de comprendre les recommandations standards de SAFe les principes et le sens du modèle pour être en mesure d’adapter l’approche selon le contexte et les difficultés rencontrées. Puis expérimentez une première approche pour tester, apprendre et améliorer ensuite le dispositif. Gardez aussi en tête que rien n’est figé une fois pour toutes. Une première approche qui semblait convenir peut également s’avérer inadaptée après plusieurs PI parce que le contexte et l’environnement ont changé.
Christelle Boulan, Stéphane Déprès, Camille Placier et Sylvain Hochart, Consultants Coachs Agile à l’échelle chez inspearit