Le Strategic Portfolio Review (SPR) est un processus clé pour aligner les objectifs stratégiques avec l’exécution opérationnelle. En synchronisant les ressources, les Epics et les objectifs trimestriels, il assure un delivery optimal dans un cadre SAFe. Découvrez comment cette cérémonie collaborative garantit une prise de décision efficace et un ajustement continu des projets stratégiques
Les architectes d’entreprise peuvent utiliser Archimate pour modéliser les Epics et Features du framework SAFe. Ces modèles offrent une vue abstraite et simplifiée des concepts manipulés, facilitant ainsi l’analyse et la gestion des exigences.
Dans cet article, nous décrivons comment établir un mapping entre SAFe et ArchiMate.
En SAFe, les Epics, Features et Stories sont des exigences qui modifient des parties du système d’information. Une Feature représente une fonctionnalité apportant une valeur métier, dimensionnée pour être livrée par une équipe agile. Une Epic, quant à elle, est une initiative de développement de grande envergure nécessitant un produit minimum viable (MVP) et une approbation du portefeuille.
Depuis 2014, nous avons observé que les Epics impactent plusieurs utilisateurs à travers un processus collaboratif. En revanche, les Features permettent à un utilisateur de réaliser une activité métier spécifique.
Caractéristiques des Epics et Features
Un Epic :
• Implémente un processus ou un sous-processus métier.
• Impacte une seule chaîne de valeur opérationnelle.
• Est géré dans un seul portefeuille.
• Impacte plusieurs acteurs métier.
• Peut être implémenté dans plusieurs Program Increments (PI).
• Utilise des Features pour réaliser ses activités métier.
Une Feature :
• Respecte les principes du Minimum Marketable Feature.
• Représente une seule transaction sans interruption.
• Est utilisée par un seul acteur métier dans un seul produit.
• Implémente une seule capacité métier (Business Capability).
• Est développée en un seul PI.
Archimate propose plusieurs niveaux de modélisation :
• Le niveau Stratégique modélise des chaînes de valeurs réalisées par des capacités métier (Business Capabilities).
• Le niveau Business contient des processus métier découpables en activités métier réalisées par des services métier.
• Le niveau Applicatif décrit comment ces éléments métier sont réalisés par des systèmes applicatifs.
• La couche de Motivation héberge des exigences et objectifs pour modéliser les Epics et Features.
Nous mappons les exigences de SAFe directement sur l’objet exigence d’Archimate :
• Une Epic est mappée à un Business Process au niveau Business.
• Une Feature est mappée à un Business Service au niveau Business.
• Une Story est généralement trop petite pour être représentée sur un diagramme d’architecture.
Les Value Streams de SAFe sont représentés par des Value Streams Archimate. Les OKR sont modélisés comme des objectifs Archimate, et leurs résultats clés comme des Outcomes.
En synthèse
| SAFe | Archimate | Archimate Level |
| Value Stream | Value Stream | Strategic |
| Epic | Requirement | Motivation |
| Epic réalise | Business Process | Business |
| Feature | Requirement | Motivation |
| Feature réalise | Business Service | Business |
| Story | Requirement | Motivation |
| OKR | Goal | Motivation |
| Key Result | Outcome | Motivation |
| Product | Product | Business |
Prenons un exemple : l’Epic “eCommerce Sell” optimise une partie du processus de vente d’un eCommerce et implémente le Business Process “eCommerce Sell”. Les Features associées, comme “Manage client Fraud & policy abuse”, implémentent des Business Services spécifiques.
Ce diagramme montre un Feature Mapping, découpant un Epic en plusieurs Features, reliant ainsi clairement l’intention Business avec les exigences SAFe.
En conclusion, utiliser Archimate pour modéliser les Epics et Features de SAFe permet de structurer et de clarifier les exigences et leur impact sur le système d’information. En effet, Cette approche facilite l’analyse et la gestion des initiatives de développement en alignant les besoins métiers et techniques.
Pour aller plus loin, consultez nos offres Architecture d’Entreprise et Modèle Opérationnel IT.
A la suite de l’article « Approche Produit : les trois perspectives pour transformer votre SI », passons à la maille supérieure, celle des trains ! La bonne conception de vos trains est clé dans leur efficacité au quotidien. J’observe régulièrement que leur conception est souvent héritée de l’organisation précédente et ne tire pas pleinement parti de tout le potentiel lié à ses organisations.
Je vous partage dans cet article nos règles et astuces pour construire les trains chez nos clients.
Commençons par rappeler ce qu’est un train dans un contexte SAFe (Scaled Agile Framework).
Un train est une organisation virtuelle qui planifie, s’engage, développe et déploie ensemble. En somme, c’est une équipe d’équipes. Le train permet d’aligner la vision, la planification et les interdépendances de nombreuses équipes via une synchronisation et une cadence commune. L’objectif est de fournir aux équipes le juste niveau de structure et de gouvernance pour faciliter le développement de fonctionnalités complexes qui requiert la collaboration d’équipes multiples.
Un exemple de train dans le contexte d’un retailer, est celui d’un train Commerce englobant des équipes eCommerce et vente magasin.
Règle générale : De la même manière que l’on cherche à disposer d’un maximum de cohérence au sein d’un produit et d’un maximum d’autonomie entre produits, on cherche un maximum de cohérence au sein d’un train et un minimum de dépendances entre trains.
Si vous devez construire plusieurs trains, assurez-vous que chaque train regroupe des équipes ou produits qui répondent à une étape ou plusieurs étapes contiguës de la chaine de valeur. Évitez par exemple d’embarquer dans un train des équipes ou produits qui seraient sur des étapes discontinues.
Le nombre de personnes dans un train doit être idéalement comprise entre 40 et 120 personnes. En dessous de 40 personnes, la gouvernance du train peut être une solution trop lourde pour aligner les équipes.
Au-delà de 120 personnes, un train est trop lourd à synchroniser : Pi Planning, ART Sync et Inspect & Adapt sont difficiles à gérer.
Les produits que vous embarquez dans un train doivent être cohérents. Ils doivent répondre au maximum aux même acteurs de la chaine de valeur ou contribuer à une création cohérente sur la chaine de valeur. Il peut y avoir des dépendances entre les produits du train, cela n’est pas gênant.
Par conception, les trains doivent être indépendants les uns des autres. Si ce n’est pas possible, les trains doivent être couplés de manière la plus lâche possible.
Afin de repérer ces dépendances, dessinez une carte des dépendances structurelles entre les produits. Identifiez l’ensemble des produits qui sont suffisamment indépendants pour être embarqués à l’intérieur du même train.
Les dépendances structurelles signifient que pour 80 % de chaque Feature que vous construisez, une équipe a besoin d’une autre équipe pour le construire.
La conception de train comme celle des produits sous-jacents est une affaire d’équilibre et de compromis. Vous ne trouverez pas la meilleure solution du premier ! En conséquence, autorisez-vous à explorer plusieurs pistes et à expérimenter pour apprendre.
Validez les hypothèses de conception de vos trains en simulant l’écoulement de votre backlog d’Epics et de Features déjà connus. Cela vous permet à moindre frais d’en évaluer la pertinence.
Commencez par expérimenter sur un train afin d’apprendre avant d’étendre sur le reste de votre organisation. Pour cela donnez-vous quelques orientations sur les possibles trains suivant afin de ne pas hypothéquer la conception du premier.
Testez vos trains pendant quelques PI et procédez à des ajustements afin de les optimiser au fur et à mesure.
La conception de vos trains a une grande influence sur leur performance au quotidien. Une mauvaise conception entraine des dépendances structurelles et donc une synchronisation qui va vous faire perdre en efficacité. Trouvez un équilibre entre se lancer rapidement et sur concevoir à l’avance.
Si vous avez un doute sur votre démarche, contactez-nous. Nous disposons de tous les outils et de la démarche pour vous accompagner sereinement.
Introduction : le défi de la relation Métier / IT
Vous êtes nombreux à rencontrer des difficultés dans la relation entre le métier et l’IT. Souvent, la DSI est perçue comme un simple exécutant plutôt qu’un partenaire créateur de valeur. Cet article vous propose une solution : l’instauration de la co-responsabilité dans des contextes agiles, produit ou agile à l’échelle.
Du Point de Vue de l’IT
– Un manque d’implication du métier dans l’analyse et le suivi des exigences.
Du Point de Vue du Métier
– Une incompréhension de la valeur de l’IT, qui ne livre pas ce qui est demandé dans des délais raisonnables.
Le Principe de Base
Notre approche repose sur la création de binômes co-responsables à tous les niveaux de l’organisation. Ces binômes sont composés d’un acteur métier et d’un acteur IT.
L’Acteur Métier
Il incarne le besoin, la valeur à créer et les changements à implémenter.
L’Acteur IT
Il identifie les impacts sur le système d’information, propose des alternatives et estime les coûts.
La Collaboration
Ensemble, ils trouvent le meilleur équilibre entre valeur et coût, renforçant ainsi leur collaboration et optimisant les ressources de l’organisation.
Côté IT
Il faut passer d’une posture réactive à une posture proactive, où vous conseillez, orientez et challengez le besoin.
Côté Métier
Il faut évoluer d’une posture de demandeur à une posture de collaborateur, où la valeur et les enjeux sont partagés.
Le Respect Mutuel
Dans les deux cas, le respect et la considération sont essentiels pour la réussite du binôme.
Au Niveau Équipe
Le binôme est composé du Product Owner et de tous les membres de l’équipe.
Au Niveau Produit
Le binôme est formé du Product Manager et du System Architect.
Au Niveau Portefeuille
Le binôme inclut l’Epic Owner et l’Enterprise Architect.
En somme, la co-responsabilité permet une collaboration plus étroite et efficace entre le métier et l’IT. Elle favorise une meilleure utilisation des ressources et conduit à des décisions plus éclairées. Ce modèle, lorsqu’il est bien appliqué, peut transformer la dynamique de votre organisation.
N’attendez plus, faites le pas vers la co-responsabilité et récoltez les fruits d’une collaboration réussie.
Pour aller plus loin, consulter notre offre sur les modèles opérationnels et l’article Approche Produit: les trois perspectives pour transformer votre SI.
Les organisations traditionnelles fonctionnent souvent selon une logique de projet ou d’application. Adopter une approche orientée produit exige de trouver un équilibre subtil entre trois perspectives, chacune avec ses propres contraintes :
La partition de votre SI en produits est un exercice d’équilibrage entre ces différentes perspectives. Cet équilibre peut être précaire au moment où vous démarrez pour de multiples raisons historiques. Vous pouvez lancer des initiatives pour l’améliorer au fil du temps. Par exemple, vous pouvez envisager des initiatives pour moderniser votre SI ou rationaliser les technologies. Ceci permet de mieux aligner le partitionnement sur vos chaînes de valeur. Vous pouvez également travailler sur l’homogénéité technologie de certains périmètres afin de faciliter la construction d’équipes pluridisciplinaires.
Pour réussir cette transformation, vous aurez besoin :
Les produits ainsi construits sont stables dans le temps car arrimés à un métier de l’organisation. Là où les technologies vont et viennent au gré des obsolescences, les produits s’adaptent au fur et à mesure à leur environnement technologique et métier. Ces produits sont de véritables assets de l’organisation.
Pour aller plus loin, voir notre offre sur l’architecture d’entreprise.
L’article discute de l’importance de comprendre et d’intégrer l’agilité à grande échelle dans les organisations pour favoriser la digitalisation. Il souligne les trois processus clés de l’agilité à grande échelle – Lean Portfolio Management, Feature Management et Story Management, et comment ceux-ci s’interconnectent avec les processus régaliens de la DSI. L’article conclut en mettant l’accent sur la nécessité d’une expertise approfondie de l’IT et du numérique pour assurer une intégration efficace de l’agilité à grande échelle, tout en proposant plusieurs facteurs clés de succès pour faciliter cette transformation.
OKR et Lean-Portfolio Management, le duo gagnant, découvrez comment les combiner
Comme à son habitude, le framework d’agilité à l’échelle SAFe va proposer une nouvelle version majeure, la cinquième depuis ses débuts.
Plusieurs évolutions sont au menu, d’importance plus ou moins grandes. Par exemple, un nouvel onglet Overview vient résumer les « compétences » sur la page principale, l’étage portfolio se complète, l’orientation client prend une place centrale dans le framework, la notion d’agilité business fait son apparition, …
Mais est-ce tout ? Pas tout à fait…
Car là où SAFe 5.0 apporte une grande nouveauté, c’est sur sa posture vis-à-vis de la structure des entreprises. En effet, nous avions jusqu’alors un modèle orienté delivery qui ne présumait pas spécialement de la façon dont l’entreprise était organisée.
SAFe 5.0 semble (enfin) prendre position, notamment à travers deux introductions majeures :
On aurait d’ailleurs presque envie de voir cette dualité agilité du delivery versus agilité structurelle dans l’Overview, toutes deux supportées par le lean agile mindset au service d’une entreprise « orientée client ».
Si cette tendance se confirme dans la version finale de SAFe 5.0, cela sera une grosse évolution… et sans doute un gros argument de moins pour nombre de ses détracteurs !
Ces éléments nouveaux contribuent à porter l’agilité à l’échelle de l’entreprise en proposant une ébauche pour embarquer les fonctions support (RH, légal, finance, marketing) tout en intégrant la culture d’entreprise comme un facteur clé de succès pendant et après la transformation !
Nous continuerons à vous donner plus détail sur le blog au fur et à mesure que les informations arriverons.
SAFe 5.0: https://scaledagileframework.com/#
Pour aller plus loin :
Nos offres de conseil en entreprise agile.
La gestion de portefeuille lean-agile a pour rôle de décliner la stratégie de l’entreprise en initiatives opérationnelles. C’est en quelque sorte une membrane d’échange entre l’écosystème de l’entreprise et son environnement. Elle permet l’implémentation de la stratégie et sa validation ou sa révision suite à sa mise en œuvre.
L’essor des nouvelles technologies et l’accélération de la concurrence raccourcissent la durée de vie de s nouvelles opportunités. Cette volatilité accrue du marché vient percuter le mode d’analyse des opportunités des portefeuilles classiques, ainsi que leur capacité à aligner rapidement toute l’organisation à une nouvelle stratégie. Vous devez réduire le temps nécessaire pour lancer de nouvelles initiatives et évitez de perdre en coût d’opportunité.
De plus, la mise en place de modèles de delivery agiles à l’échelle s’accélère. Ceci vient apporter de la flexibilité à l’organisation, avec des équipes qui repriorisent régulièrement leurs taches. La gestion de portefeuille doit gagner en flexibilité pour maximiser votre production de valeur. Ceci se fait en revoyant régulièrement les initiatives prioritaires ainsi que l’effort à allouer à leur implémentation.
Premièrement, le processus de gestion de portefeuille doit pouvoir gérer plusieurs types d’activité. A minima, il doit traiter distinctement l’analyse des nouvelles opportunités et le pilotage des initiatives engagées.
En amont, le processus doit capter en continu chaque nouvelle opportunité sous forme d’initiatives. Leur affinage se fait progressivement pour ne conserver que celles avec le plus haut retour sur investissement. En aval, le pilotage de l’engagement doit se traduire par une repriorisation régulière des initiatives et une réévaluation de l’effort consenti. De plus, synchroniser ces revues avec un modèle de delivery agile facilite l’alignement de toute l’organisation sur une évolution stratégique.
Deuxièmement, vous devez placer le backlog des initiatives validées au centre du processus. Les hypothèses de résultats business ou technique sont challengées régulièrement, ce vous permet une repriorisation régulière et vous garantit que votre organisation travaille toujours sur ce qui a le plus de valeur pour vos commanditaires.
On constate que ces initiatives, stratégiques, sont très différentes des projets classiques. Celles-ci nécessitent un découpage permettant d’apporter de la valeur le plus vite possible.
Troisièmement, des critères de filtrages doivent supporter ce processus. Ils doivent porter sur l’alignement avec la stratégie d’entreprise (thèmes stratégiques) et sur la disponibilité de financement. A plus haut niveau, c’est un modèle économique de priorisation qui structure l’ordonnancement des initiatives.
En complément, une organisation Produits de l’entreprise facilite le fonctionnement d’un portefeuille lean-agile, grâce au financement capacitaire. Celui-ci rapproche la priorisation économique de la capacité opérationnelle. Cette organisation facilite aussi l’autonomie des équipes sur les chaînes de valeurs considérées.
Le temps passé avec une gestion de portefeuille classique représente un manque à gagner potentiel pour l’entreprise. Ce cout d’opportunité perdu joue en la faveur d’une gestion de portefeuille lean agile. D’autant qu’il n’y a pas de raisons techniques à attendre une mise en place d’un modèle agile complet pour finalement “étendre au portefeuille”.
De plus, la gestion de portefeuille regroupe plusieurs parties prenantes clés dans une organisation. Enfin, placer le sujet de sa transformation à l’ordre du jour, c’est vous assurer d’embarquer ces parties prenantes. Elles sauront devenir des agents du changement pour l’ensemble des étapes de transformation qui suivront.
Pour aller plus loin :
Nos offres de conseil en entreprise agile.