S’inspirer du Framework SAFe pour organiser le développement d’une solution complexe (Large Solution)
SAFe est un framework basé sur des principes, des valeurs et des recommandations issues de retours d’expérience concrets pour guider une entreprise dans la transformation en profondeur de ses modes d’organisation du travail et lui permettre de prospérer à l’ère du digital. Dans les grandes entreprises, sa mise en œuvre est progressive et graduelle et se traduit par un déploiement incrémental et un apprentissage continu des principes, pratiques et compétences qu’il est nécessaire de maîtriser pour réussir sa transformation. La configuration Large Solution permet de développer des solutions complexes nécessitant la coordination de plusieurs trains.
Note : cet article est destiné à des lecteurs connaissant les fondamentaux du framework SAFe.
SAFe définit 4 configurations
SAFe définit 4 configurations permettant d’assurer ce déploiement progressif, adapté au contexte et au niveau de maitrise des concepts d’Agilité à l’échelle :
- « Essential » : qui permet de mettre en œuvre un train (« équipe d’équipes » coordonnées, regroupant jusqu’à 125 personnes)
- « Large Solution » : au-delà de 125 personnes, cette configuration permet de développer des solutions complexes nécessitant la coordination de plusieurs trains
- « Portfolio » qui permet de mettre en place des pratiques lean et agile de gestion de portefeuille.
- « Full » qui intègre toutes les autres configurations.
Les différents éléments du framework (Compétences, rôles, cérémonies) permettent d’adresser en particulier certaines configurations.
Dans cet article, nous allons nous intéresser à la configuration « Large Solution » et en particulier explorer l’opportunité de mettre en œuvre partiellement des éléments décrits dans cette configuration.
La configuration « Large Solution » inclut la configuration « essential » et apporte les éléments supplémentaires suivants (voir figure 1 et 2):
- Des rôles et des cérémonies permettant de gérer les dépendances entre les trains et d’assurer leur coordination :
- Rôles: Solution Train Engineer, Solution Architect, Solution Management
- Cérémonies : pre-PI planning, Post PI planning, Solution Demo, PO sync, Scrum of Scrum, Architect Sync
- De nouveaux artefacts (Solution Intent, Solution Backlog)
- Une compétence supplémentaire « Entreprise Solution Delivery » (voir la bulle dans la figure 2)
Nous allons voir que la compétence « Entreprise Solution Delivery » comporte des éléments qu’il peut être intéressant d’appliquer, même si on déploie un seul train, ou plusieurs trains dont le niveau de dépendance ne justifie pas la création d’un train de solution et la mise en œuvre des rôles et cérémonies associées.
La compétence « Enterprise Solution Delivery » comporte 9 pratiques regroupées en 3 dimensions:
Les pratiques lean d’ingénierie des Systèmes et des Solutions
1. Affiner continuellement les élément fixes et variables de la solution (« Solution intent »)
2. Gérer plusieurs horizons de planification (Train PI roadmap, Solution PI roadmap, Solution Roadmap)
3. Concevoir une architecture qui est évolutive, modulaire permettant la mise en service de nouvelles versions des systèmes à des rythmes différents
4. Adresser les besoins de conformité en continu
Les pratiques de coordination des trains et des fournisseurs
5. Construire et intégrer les composants et les capacités de la solution avec les Agile Release Trains (ARTs) et les Solution Trains.
6. Mettre en œuvre l’intégration continue
7. Assurer l’alignement des fournisseurs avec les trains internes
Les pratiques permettant de faire évoluer les systèmes en continu
8. Construire un pipeline de livraison continue
9. Faire évoluer les systèmes déployés
Plus la solution est complexe et intègre de nombreux systèmes et les contributions de nombreuses équipes, plus ces pratiques sont incontournables.
Pour autant, certains éléments peuvent avoir un intérêt pour des solutions développées par des trains avec un faible niveau de dépendance et non regroupés dans un train de solution
Nous allons en donner quelques exemples.
Les pratiques lean d’ingénierie des systèmes et des solutions
Quelques mots sur les pratiques 3 (conception d’une architecture évolutive) et 4 (adresser les besoins de conformité) avant de nous intéresser plus en détail à la pratique 1 (« Solution intent »).
Ces pratiques répondent à des besoins qui ne sont pas propres aux larges solutions.
Concevoir une architecture modulaire permet de faire évoluer plus facilement les solutions et d’adresser de nouveaux marchés. Cela permet également la mise en service indépendante des fonctionnalités et d’adapter le rythme de ces mises en service aux besoins du marché.
De même, des exigences de conformité peuvent aussi s’appliquer à des solutions développées par des trains uniques. Ces exigences qui proviennent de multiples sources (règlementations financières, sécurité, engagements sociétaux et environnementaux) évoluent de plus en plus rapidement et doivent être intégrées en continu dans les activités de développement de la solution au même titre que la qualité (« Built-in quality »).
Affiner continuellement le référentiel de la solution (« Solution intent »)
La « Solution intent » (intention de la solution) introduite par la pratique 1, est un référentiel où sont stockées, gérées et partagées les connaissances sur l’état actuel et l’état futur de la solution.
Le besoin de maintenir un référentiel pour partager la connaissance sur ce qu’est notre solution et comment elle est réalisée n’est bien sûr pas une innovation. Les organisations de développement ont depuis longtemps mis en œuvre des référentiels et des pratiques de gestion de configurations plus ou moins structurées afin de garantir l’intégrité de leurs solutions et l’accès à tous les acteurs impliqués. SAFe le met en avant au niveau de l’organisation « Large Solution » car à cette échelle la maitrise du référentiel de connaissance décrivant la solution complexe à réaliser est critique pour la réussite de la démarche.
L’organisation doit s’assurer de la bonne structuration des informations, maintenir le référentiel à jour pour refléter en permanence l’état actuel de la solution et la vision sur son état futur et assurer le bon alignement de centaines voire millier de contributeurs qui doivent travailler ensemble.
Par ailleurs les principes lean apportent un éclairage différent sur la manière de créer et faire évoluer ce référentiel :
- Un référentiel non statique mais dynamique qui se construit au fur à mesure en capitalisant les éléments qui émergent du développement
- Une collaboration étroite entre Product/Solution Managers, Product/Solution Architect et équipes pour faire évoluer ce référentiel
Un référentiel dynamique permet de prendre en compte les inconnues qui sont souvent nombreuses lorsque l’on commence à développer de nouvelles fonctionnalités : des besoins qui évoluent, des technologies nouvelles à mettre en œuvre.
Certains éléments de la solution (Besoins, spécifications, design) seront fixes car structurants et non négociables, par exemple la conformité à un standard.
D’autres sont négociables ou pourront émerger au cours du développement par exemple le niveau de performance à atteindre.
Au fur et à mesure du développement, les équipes réaliseront des études exploratoires afin d’améliorer la connaissance sur la solution.
Voici quelques exemples d’éléments pouvant être contenus dans la « solution intent » : Diagrammes d’architectures, Eléments de conception, Spécifications, Modélisation, standards applicables, tests fonctionnels et non fonctionnels, traçabilité.
La gestion des développements sous-traités
Nous voyons assez souvent chez nos clients des trains dont tout ou partie des développements sont sous-traités.
La pratique d’alignement entre les équipes du fournisseur et les équipes du client introduit la notion de train fournisseur (« supplier train »). Elle décrit comment coordonner les trains fournisseur avec les trains internes et propose aussi un modèle contractuel favorisant le travail en mode collaboratif. Cela permet de répondre aux problématiques de contractualisation et leur cohérence avec les principes Agile et Lean.
Ainsi l’article Agile contracts compare les avantages et les inconvénients de différents types de contrats (forfait avec objectif de résultats, objectifs de moyens) et propose une approche collaborative consistant en une phase de préparation (pre-committment) au cours de laquelle l’entreprise et son fournisseur vont définir ensemble la vision, la roadmap, le MVP (Minimum Viable Product) et aboutir à un contrat qui permettra de financer les premiers PIs. Le rythme d’évolution du contrat est calé sur la cadence du train. A chaque fin de PI, en fonction des résultats obtenus sur la solution et des objectifs futurs, l’entreprise adapte les futurs niveaux d’investissement pour les prochains PIs.
Les pratiques permettant de faire évoluer les systèmes en continu
La notion de pipeline de livraison continue est introduite dès la configuration “essential”. En effet, assurer un flot continu des activités d’exploration des besoins, d’intégration et de déploiement de nouvelles fonctionnalités est nécessaire pour mettre en œuvre les principes lean et agile (livrer de la valeur en continu, assurer une boucle de feedback rapide afin d’adapter en continu la solution).
La compétence Entreprise Solution Delivery va un peu plus loin sur le sujet en abordant la problématique de devoir intégrer des composants hardware dans le pipeline de livraison continue. Des options de design (composants programmables) et la mise en œuvre d’outils de modélisation permettent d’augmenter la fréquence d’intégration des systèmes incluant du hardware. En effet, à cette échelle de complexité un grand nombre de solutions ne comportent pas que du logiciel mais également des équipements électroniques voire mécaniques.
Là, encore cette problématique incontournable pour des solutions complexes peut également se poser sur un train unique développant une solution comprenant des composants hardware.
Dans cet article, nous avons choisi d’éclairer certains aspects peu connus et peut etre plus difficiles à comprendre de la compétence fondamentale du framework SAFe (« Entreprise Solution Delivery »), qu’une entreprise doit développer progressivement pour produire des solutions cyber physiques (produits, services, systèmes) complexes.
Si vous souhaitez échanger sur la façon d’organiser la réalisation de solutions complexes avec des modes de collaboration lean Agile n’hésitez pas à nous contacter !
Sylvain Hochart, Consultant Senior et Pascal Hagneré, Consultant Manager Agilité à l’échelle