J’ai retiré le mot « agile » de mes pages d’offres, remplacé par Product Operating Model. Pas par posture, par cohérence : l’agile n’est pas mort, il a gagné. Et 64 % des dirigeants IT préparent déjà leur DSI agentique (Gartner, 2026).

Le contexte : l’agile a gagné, il ne différencie plus

Entre 2015 et 2025, j’ai accompagné des dizaines de DSI dans leur bascule agile. SAFe, LPM, trains de release, cérémonies trimestrielles. Le vocabulaire tenait lieu de feuille de route.

En 2026, les DSI ont bouclé ce chapitre. Elles ne cherchent plus à « devenir agiles » : elles cherchent à industrialiser l’IA sans casser leur capacité de livraison. Le constat est brutal : selon le baromètre CAST × Cigref de mars 2026, les DSI françaises mesurent 20,75 % de gains de productivité IA en moyenne. Mais les processus hérités les absorbent aussitôt. Sprints figés, validations manuelles, gouvernance en silo.

Le paradoxe est cruel : plus une DSI est mature sur l’agile, plus elle peine à intégrer les agents IA dans ses flux produits. Le cadre 2015 a gagné, et il étouffe désormais les gains de 2026.

Un cabinet qui parle encore « transformation digitale » ou « passage à l’échelle agile » en 2026 parle une langue morte. Les CIO avancés ont déjà tourné la page.

Le lexique post-SAFe qui remplace l’agile

Depuis six mois, j’ai refondu mes offres autour d’un nouveau noyau sémantique. Trois concepts structurants remplacent l’ancien lexique.

Du mode projet au Product Operating Model

Le Product Operating Model n’est pas une méthode. C’est un choix d’allocation de valeur. Il acte la mort du mode projet : fin des livraisons sur périmètre fixe, fin du sprint comme unité de travail universelle.

À la place, des équipes produit pérennes branchées sur des chaînes de valeur, qui intègrent nativement les agents IA dans leur cycle de livraison. Le SDLC n’est plus un tunnel séquentiel, c’est un flux orchestré où le développeur augmenté produit à une vitesse incompatible avec les validations manuelles de 2020.

Des chaînes de valeur aux Agentic Value Streams

Les chaînes de valeur traditionnelles étaient cartographiées en humains qui manipulent des systèmes. Les Agentic Value Streams intègrent les agents IA comme acteurs du flux, pas comme add-ons. Chaque initiative se trace jusqu’à l’impact métier livré, avec mesure explicite de la contribution de l’IA.

Le portefeuille IT ne se pilote plus par la vélocité d’équipe. Il se pilote par la valeur livrée le long des Agentic Value Streams.

Du CIO solo au Trio CIO-CISO-CDO

Wavestone observe la même rupture dans son dossier Tendances 2026 : la gouvernance IA performante repose sur un trio CIO-CISO-CDO. Aucune de ces fonctions ne détient à elle seule la vision. La bascule culturelle est aussi profonde que la bascule technique — c’est tout l’enjeu de la transformation IA des directions IT.

Trois concepts, zéro redondance avec l’ancien lexique : voilà le vocabulaire 2026.

4 signaux que votre DSI parle une langue morte

Testez votre propre DSI contre cette grille. Quatre signaux indiquent que votre vocabulaire n’est pas aligné 2026 :

1. Votre roadmap IT parle encore de « passage à l’échelle agile » sans mention explicite d’IA agentique ou de Product Operating Model
2. Votre gouvernance IA reste dans les mains du seul DSI, sans instance trio CIO-CISO-CDO formalisée
3. Votre cartographie des chaînes de valeur n’intègre pas les agents IA comme acteurs du flux
4. Votre portefeuille se pilote encore par la vélocité d’équipe, pas par la valeur livrée

Un seul signal allumé ? Votre DSI est en retard sur son propre langage. Deux ou plus ? Le décalage vocabulaire / réalité devient un angle mort stratégique.

Le vocabulaire trace les priorités. Une DSI qui parle encore 2020 arbitre encore ses investissements avec les grilles de 2020 — au moment où ses concurrentes passent à celles de 2026.

Pour aller plus loin

L’agile n’est pas mort : il est devenu le standard invisible, celui qui ne se revendique plus. 2026 impose un nouveau marqueur de maturité : la capacité à industrialiser l’IA dans un modèle opérationnel cohérent.

Chez AEP, j’ai tiré cette conséquence jusqu’au bout dans mes offres et mon lexique. Les DSI qui prendront le virage seront celles qui oseront questionner leur propre vocabulaire.

Quel mot utilisez-vous encore pour décrire votre DSI, et qui ne veut plus rien dire en 2026 ?

Maillage interne : Product Operating Model · Leadership Transformation IA · Gouvernance IA & AI Act

Sources : CAST × Cigref (mars 2026) · Gartner 2026 CIO Survey (octobre 2025) · Wavestone Tendances 2026 (février 2026)

L’article J’ai retiré l’agile : place au Product Operating Model est apparu en premier sur Agile Enterprise Partner.

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.

Définition des Concepts SAFe

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.

Utiliser Archimate pour modéliser les Exigences SAFe

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.

Mapping SAFe Archimate

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

Exemple de Modélisation utilisant ce mapping SAFe Archimate

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.

L’article Mapping SAFe Archimate est apparu en premier sur Agile Enterprise Partner.

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).

Définition d’un train

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.

Les règles pour construire des trains SAFe

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.

Règle #1 : un train aligné avec votre chaine de valeur opérationnelle

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.

Règle #2 : une juste taille de train

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.

Règle #3 : une cohérence de produits et d’équipes au sein du train

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.

Règle #4 : une indépendance entre trains

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.

Les astuces pour construire des trains SAFe

Astuce#1 : Itérez dans la conception de vos trains

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.

Astuce #2 : Testez votre organisation avec votre backlog

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.

Astuce #3 : expérimentez vos conceptions

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.

Conclusion

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.

L’article Construire des trains SAFe efficaces : règles et astuces clés est apparu en premier sur Agile Enterprise Partner.

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 :

1. Perspective Business : Cette vue privilégie l’alignement des produits avec les besoins des clients, qu’ils soient internes ou externes, tout au long de la chaîne de valeur ou des processus métier.
   Par exemple, un produit de merchandising e-commerce pourrait servir une équipe d’e-merchandising en intégrant plusieurs applications (PIM, DAM, Intégration, Merchandising, Gestion de contenu).
   
2. Perspective IT : Ici, l’accent est mis sur l’architecture du SI existant, sa modularité et sa capacité à évoluer. Les produits, dans cette perspective, s’alignent sur des groupes d’applications étroitement liées qui servent des étapes spécifiques de la chaîne de valeur.
   
3. Perspective RH : La construction et la maintenance des produits nécessitent des compétences à la fois fonctionnelles et techniques. Une équipe produit doit disposer d’un périmètre clairement défini, avec un minimum de 5 développeurs et un maximum de 20, pour fonctionner efficacement.

L’approche produit, une question d’équilibre

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.

Les étapes de Construction de vos Produits

1. Identifiez la chaîne de valeur que le périmètre SI doit supporter.
2. Mappez les systèmes informatiques sur cette chaîne pour identifier leur couverture et leurs dépendances.
3. Recensez les collaborateurs et leurs compétences associées à ces systèmes.
4. Élaborez une première version d’une architecture SI orientée produit, puis validez et itérez jusqu’à consensus. Un produit sert une partie de la chaine de valeur. Il est constitué d’un ensemble d’applications et des personnes qui sont nécessaires à sa construction et son maintien. Vous pouvez jouer sur ces trois dimensions dans vos scénarios et évaluer leurs intérêts respectifs. 

Les acteurs Clés de la transition vers votre approche produit

Pour réussir cette transformation, vous aurez besoin :

• D’acteurs métier : Des responsables métier pour identifier la chaîne de valeur et ses acteurs majeurs.
• D’architectes d’entreprise : Les Architectes d’entreprise sont clés dans la définition de la chaine de valeur et l’identification des systèmes contributeurs sous-jacents. En sus, les architectes systèmes quant à eux apportent la vision des compétences techniques nécessaires pour construire et maintenir les systèmes.
• Des représentants du cycle de développement à la production afin de valider la capacité à construire, tester et opérer les ensembles ainsi formés.
• D’un Animateur : Une personne pour faciliter les ateliers et faire converger les différentes perspectives.

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 Approche Produit: les trois perspectives pour transformer votre SI est apparu en premier sur Agile Enterprise Partner.

Afin de servir la digitalisation croissante des organisations, vous avez surement pris la vague de l’agilité à l’échelle, souvent avec SAFe. Celle-ci arrive avec son cortège de termes exotiques, ses processus et sa gouvernance cadencée bousculant ainsi profondément les modes de fonctionnement existants. Elle touche au cœur des processus de production de logiciels informatiques, la plaçant ainsi au cœur des enjeux de productivité des organisations. 

• • Le Lean Portfolio Management (ou Epic Management). Ce processus  transforme votre stratégie en Epic (initiatives) opérationnelles et gère ces Epics de leur découverte jusqu’à leur mise à disposition réelle sur le terrain.

• • Le Feature Management. Ce processus  gère le cycle de vie de la découverte à la finalisation de Features (fonctionnalités) produit (issues ou non d’initiatives du Portfolio).

• • Le Story Management. Ce processus gère le cycle de vie de leur découverte jusqu’à leur terminaison de User Stories (issues ou non de Features).

Processus SAFe

Ce modèle semble simple, il est composé de trois niveaux d’exigences qui se subdivisent progressivement pour modéliser vos initiatives métier et IT. La réalité est un peu plus complexe durant la phase de transition qui peut être longue. Les modèles de delivery agile et traditionnels vont souvent devoir cohabiter et le portfolio doit être en mesure de gérer cette dualité sur son champ d’action.

Facteur clé de succès 1 : assurez-vous de concevoir un seul portfolio management en capacité de gérer des initiatives délivrées en agile, en cycle en V ou en partie l’un et l’autre.

Vue globale des connexions avec les processus régaliens d’une DSI

Afin de décrire les interconnexions avec les autres processus d’une DSI, je suis parti d’une sous-partie du framework IT4IT V3. Celui-ci est le plus proche en termes d’orientation produit et de comptabilité avec un modèle d’agilité à l’échelle. Il est possible de faire le même exercice avec tout autre framework IT comme Cobit, l’ITCMF ou ITIL (dans une moindre mesure).

Schema Global SAFe IT4IT

On constate immédiatement que ces processus agiles à l’échelles sont centraux et s’intègrent avec de très nombreux autres processus du cadre global. Seule une bonne compréhension de l’ensemble vous permet de les intégrer correctement et surtout efficacement à la chaine de valeur IT.

 

Zoom sur le processus de Lean-Portfolio Management SAFe

Le Lean-Portfolio Management est interconnecté avec 7 processus :

Lien Portfolio et autres processus IT4IT

Ce processus se retrouve ainsi au carrefour de tous les processus stratégiques de votre organisation : la stratégie, la gestion budgétaire, les gestion des trajectoires stratégiques et la gestion capacitaire.

Facteur clé de succès 2 : revoyez progressivement chacun des sept processus et leurs interconnexions avec le Lean-Portfolio Management. Le Processus de Lean-Portfolio Management ne peut pas fonctionner seul, il faut le connecter à minima au démarrage avec la gestion de la demande pour l’alimenter.

Facteur clé de succès 3 : expérimentez votre design du processus LPM et améliorez / étendez le progressivement. Au vu du nombre de processus interconnectés, il est illusoire de concevoir tous les impacts sur les sept processus et leurs relations lors de la conception et du déploiement du processus de LPM.

Exemple : une gestion budgétaire qui impose la construction d’une liste figée de projets de manière annuelle est incompatible avec un Lean portfolio trimestriel dynamique. Vous devez revoir la maille et le cycle d’allocation de vos budgets.

Zoom sur le processus de Feature Management 

Le processus de Feature Management SAFe est connecté avec 4 processus :

Lien Feature Management IT4IT

Ce processus est beaucoup plus simple à déployer mais il doit être correctement connecté au processus de gestion de la demande en amont lorsque l’on gère des features produit indépendants du portefeuille et en aval avec la gestion de Release pour déployer et activer les Features en production.

Le Time 2 Market que l’on cherche souvent à améliorer en agile transverse ces trois processus de la Demande jusqu’à la mise ne production.

Facteur clé de succès 4 : au-delà de la verticalité de conception en connexion au LPM et au Story Management, intégrez le Feature Management aux processus de Demand Management et de Release Management. Vous disposez ainsi d’une chaine canonique de l’idée à la mise en production efficiente. Le processus de Demand management protége le processus de Feature Management d’une complexité et d’une charge de capture qui risque de l’écrouler et de lui faire perdre son efficacité.

Zoom sur le processus de Story Management

Le processus de Story Management SAFe est connecté avec 3 processus :

Lien Story Management IT4IT

On retrouve la gestion de la Demande pour les petites demandes d’évolution et le processus de release Management en sortie qui vient gérer les Release captant les Stories et les corrections d’anomalies.

Facteur clé de succès 5 : intégrez horizontalement le Story Management avec les processus de Demand Management et de Release Management pour conserver l’efficacité et les bénéfices de l’agilité classique.

En conclusion, l’agilité à l’échelle nécessite une bonne expertise et compréhension de ce qu’est une DSI ou une direction Digitale pour l’intégrer efficacement. Vous pouvez bénéficier de nos nombreux retours d’expérience sur la construction ou l’évolution de modèle opérationnels IT et Digitaux pour faire évoluer le vôtre de manière sécurisée. Voir nos offres NexT Operating Model et Lean Portfolio Management et l’article CIO Office Design & Déploiement.

 

Avez-vous réellement réussi à l’intégrer efficacement au sein de votre modèle opérationnel IT / Digital ?

Pourquoi cette question se pose ? Les processus sous-jacents à l’agilité sont étroitement interconnectés avec des processus régaliens de la DSI. De nombreuses transformations agiles échouent par méconnaissance de ces connexions. En effet, c’est la cohérence d’ensemble du nouveau modèle opérationnel qui permet d’atteindre les promesses d’efficacité d’une transformation agile à l’échelle. Au-delà de l’IT, c’est le fonctionnement fluide et cohérent de l’ensemble de votre organisation qui est en jeu ici.

Dans la suite de l’article je vous propose d’explorer ces processus agiles à l’échelle et leurs interconnexions et  je vous propose quelques facteurs clé de succès.

Les processus agiles à l’échelle SAFe

Si l’on se base sur le cadre d’agilité à l’échelle le plus connu, à savoir SAFe, nous trouvons essentiellement trois processus interconnectés et hiérarchiques : 

• • Le Lean Portfolio Management (ou Epic Management). Ce processus  transforme votre stratégie en Epic (initiatives) opérationnelles et gère ces Epics de leur découverte jusqu’à leur mise à disposition réelle sur le terrain.

• • Le Feature Management. Ce processus  gère le cycle de vie de la découverte à la finalisation de Features (fonctionnalités) produit (issues ou non d’initiatives du Portfolio).

• • Le Story Management. Ce processus gère le cycle de vie de leur découverte jusqu’à leur terminaison de User Stories (issues ou non de Features).

Processus SAFe

Ce modèle semble simple, il est composé de trois niveaux d’exigences qui se subdivisent progressivement pour modéliser vos initiatives métier et IT. La réalité est un peu plus complexe durant la phase de transition qui peut être longue. Les modèles de delivery agile et traditionnels vont souvent devoir cohabiter et le portfolio doit être en mesure de gérer cette dualité sur son champ d’action.

Facteur clé de succès 1 : assurez-vous de concevoir un seul portfolio management en capacité de gérer des initiatives délivrées en agile, en cycle en V ou en partie l’un et l’autre.

Vue globale des connexions avec les processus régaliens d’une DSI

Afin de décrire les interconnexions avec les autres processus d’une DSI, je suis parti d’une sous-partie du framework IT4IT V3. Celui-ci est le plus proche en termes d’orientation produit et de comptabilité avec un modèle d’agilité à l’échelle. Il est possible de faire le même exercice avec tout autre framework IT comme Cobit, l’ITCMF ou ITIL (dans une moindre mesure).

Schema Global SAFe IT4IT

On constate immédiatement que ces processus agiles à l’échelles sont centraux et s’intègrent avec de très nombreux autres processus du cadre global. Seule une bonne compréhension de l’ensemble vous permet de les intégrer correctement et surtout efficacement à la chaine de valeur IT.

 

Zoom sur le processus de Lean-Portfolio Management SAFe

Le Lean-Portfolio Management est interconnecté avec 7 processus :

Lien Portfolio et autres processus IT4IT

Ce processus se retrouve ainsi au carrefour de tous les processus stratégiques de votre organisation : la stratégie, la gestion budgétaire, les gestion des trajectoires stratégiques et la gestion capacitaire.

Facteur clé de succès 2 : revoyez progressivement chacun des sept processus et leurs interconnexions avec le Lean-Portfolio Management. Le Processus de Lean-Portfolio Management ne peut pas fonctionner seul, il faut le connecter à minima au démarrage avec la gestion de la demande pour l’alimenter.

Facteur clé de succès 3 : expérimentez votre design du processus LPM et améliorez / étendez le progressivement. Au vu du nombre de processus interconnectés, il est illusoire de concevoir tous les impacts sur les sept processus et leurs relations lors de la conception et du déploiement du processus de LPM.

Exemple : une gestion budgétaire qui impose la construction d’une liste figée de projets de manière annuelle est incompatible avec un Lean portfolio trimestriel dynamique. Vous devez revoir la maille et le cycle d’allocation de vos budgets.

Zoom sur le processus de Feature Management 

Le processus de Feature Management SAFe est connecté avec 4 processus :

Lien Feature Management IT4IT

Ce processus est beaucoup plus simple à déployer mais il doit être correctement connecté au processus de gestion de la demande en amont lorsque l’on gère des features produit indépendants du portefeuille et en aval avec la gestion de Release pour déployer et activer les Features en production.

Le Time 2 Market que l’on cherche souvent à améliorer en agile transverse ces trois processus de la Demande jusqu’à la mise ne production.

Facteur clé de succès 4 : au-delà de la verticalité de conception en connexion au LPM et au Story Management, intégrez le Feature Management aux processus de Demand Management et de Release Management. Vous disposez ainsi d’une chaine canonique de l’idée à la mise en production efficiente. Le processus de Demand management protége le processus de Feature Management d’une complexité et d’une charge de capture qui risque de l’écrouler et de lui faire perdre son efficacité.

Zoom sur le processus de Story Management

Le processus de Story Management SAFe est connecté avec 3 processus :

Lien Story Management IT4IT

On retrouve la gestion de la Demande pour les petites demandes d’évolution et le processus de release Management en sortie qui vient gérer les Release captant les Stories et les corrections d’anomalies.

Facteur clé de succès 5 : intégrez horizontalement le Story Management avec les processus de Demand Management et de Release Management pour conserver l’efficacité et les bénéfices de l’agilité classique.

En conclusion, l’agilité à l’échelle nécessite une bonne expertise et compréhension de ce qu’est une DSI ou une direction Digitale pour l’intégrer efficacement. Vous pouvez bénéficier de nos nombreux retours d’expérience sur la construction ou l’évolution de modèle opérationnels IT et Digitaux pour faire évoluer le vôtre de manière sécurisée. Voir nos offres NexT Operating Model et Lean Portfolio Management et l’article CIO Office Design & Déploiement.

 

L’article Intégrez efficacement SAFe dans votre modèle opérationnel est apparu en premier sur Agile Enterprise Partner.

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 : 

• Un 10ème  principe « Organize Around Value », qui explique ni plus ni moins comment une entreprise grandissante perd son agilité en se structurant, et propose le framework comme un « Second Operating System » pour un regain d’agilité. 
• Deux nouvelles « compétences » (qui portent le total à 7),  Organizational Agility  et  Continuous Learning Culture, qui mettent l’emphase sur l’agilité au-delà du delivery, comme le faisait déjà la compétence  Lean Portfolio Management.  

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.

L’article SAFe 5.0 : une posture (enfin) assumée sur l’évolution globale de l’organisation  ? est apparu en premier sur Agile Enterprise Partner.

De très nombreuses organisations en France et dans le monde adoptent l’agilité à différentes échelles de l’entreprise. Sont-elles néanmoins devenues pour autant plus agiles, plus performantes, plus fiables ou plus résilientes ?

1/ Faire ou Être agile, quelle importance ?

« Faire » de l’agile, est relativement simple, il suffit de choisir une méthode ou un framework du marché, d’identifier les personnes amenées à jouer les rôles nécessaires et de lancer les premières cérémonies agiles.

Par exemple avec Scrum, vous identifiez vos Product Owner, Scrum Master et Team Member puis lancez vos cérémonies de Sprint Planning, Daily Scrum Meetings, Backlog Refinements, Sprint Review et Sprint Retrospective et vous voilà à « faire » de l’agile.

Pour autant, les comportements de vos collaborateurs ont-ils fondamentalement changé ? Avez-vous amélioré la performance de votre organisation ? Avez-vous amélioré la collaboration, la synchronisation et l’alignement ? L’information est-elle transparente et partagée par tous ?

Vous allez constater dans le meilleur des cas une amélioration de la performance de vos équipes, mais allez passer à côté du gain réel proposé par l’agile qui repose plus sur un changement de dynamique interpersonnelle que sur de la méthode.

En effet, pour améliorer la performance de votre organisation, il ne vous suffit pas de « Faire » de l’agile. Il faut réellement que tous vos acteurs impliqués comprennent l’intention derrière chaque rôle, chaque cérémonie, chaque interaction et ajustent leurs comportements à la fois individuels et d’équipe vers cette intention. C’est à cette condition que vous basculez de « Faire » de l’agile à « Être » agile et que vous ancrez durablement ce changement dans l’esprit collectif.

2/ L’essence de l’agilité, un profond changement culturel et comportemental

« Être » agile est essentiellement un changement de comportement individuel et collectif et un changement de culture. Changer de culture ne se fait qu’en ancrant de nouvelles habitudes et s’avère donc bien plus long que de « Faire » de l’agile.

L’agilité repose sur des marqueurs culturels forts : l’esprit d’équipe, la collaboration, le développement humain, le partage du sens, la transparence, l’alignement, l’orientation client ou encore la conscience de la valeur apportée. Cette culture requiert d’améliorer la collaboration, la synchronisation et la pédagogie auprès de vos collaborateurs impliqués et de leur environnement direct.

Pour vos équipes, cela passe aussi par une réelle prise d’autonomie et de responsabilité sur leur travail. Tout le monde n’appréciera d’ailleurs pas forcément cette responsabilité proposée. Pour vos managers un lâcher prise et une dimension humaine plus forte.

Au-delà de ses changements culturels et comportementaux, pour être agile, vous devez comprendre le sens du produit que vous cherchez à construire et l’intention derrière chaque cérémonie des pratiques agiles que vous employez ?.

Par exemple, le Daily Scrum Meeting, qui ne dure que 15min et dont les 3 questions rituelles sont très simples, est certes une vraie opportunité de découvrir et traiter les blocages potentiels de l’équipe, mais c’est aussi un vrai acte d’engagement quotidien de l’équipe sur ses travaux de la journée. Ce n’est certainement pas une cérémonie de reporting ni de contrôle de l’avancement de l’équipe, qui est pourtant le travers que l’on constate régulièrement.

Autre exemple, le Sprint Planning est aussi une cérémonie d’engagement collectif de l’équipe sur un backlog sur la base d’une vision et de priorités exposées par le Product Owner. Ce n’est pas une distribution de tâches à des individus, une obligation à faire l’intégralité du backlog ou l’engagement de faire un exploit individuel pour réaliser une Story ou une autre.

Les travers sur toutes les cérémonies sont nombreux et souvent issus de la culture initiale de l’organisation qui peut être plus portée sur le contrôle ou l’exploit individuel par exemple.

Peter Drucker, auteur renommé sur le management, nous dit que “La culture mange la stratégie au petit déjeuner”. Vous pouvez effectivement mettre en place toutes les cérémonies agiles que vous voulez, tant que les comportements de vos collaborateurs n’ont pas changé pour que vos équipes se concentrent sur la finalité et pas uniquement la forme, vous n’aurez que l’apparence d’agilité et n’obtiendrez au final pas grand-chose de bien différents de vos modes de travail existants.

3/ Quels bénéfices pour votre organisation et vos collaborateurs

« Être » agile va largement améliorer la motivation intrinsèque de tous, qui vont trouver un sens dans leurs actions, une responsabilité ou encore une autonomie qu’ils n’avaient pas forcément. Cette motivation est pour beaucoup le moteur de l’efficacité, de l’engagement et de la qualité.

Pour l’organisation c’est un processus plus fiable délivrant plus rapidement des produits de meilleure qualité que vous allez obtenir et donc des clients ou usagers plus satisfaits au final.

Attention néanmoins à un point, pour tirer pleinement le bénéfice de l’agile, il faut que toute votre entreprise se transforme : le marketing sur son approche produit, les RH sur le recrutement et la mesure de la performance, les achats et le juridique sur les modalités de sourcing et de contractualisation et toute les chaines hiérarchiques existantes.

4/ Où en êtes-vous de votre transformation agile ?

« Faire » ou « Être » agile, comment savoir où vous en êtes ?

Pour changer votre culture et les comportements de vos collaborateurs, vous devez commencer par prendre conscience de votre situation initiale et intégrer cette dimension humaine comme dorsale de votre transformation agile

Concernant la culture, vous pouvez par exemple vous demander : Quels sont les marqueurs culturels forts de votre organisation ? Comment ces marqueurs culturels se marient-ils avec ceux de l’agilité ? Sont-ils compatibles ? Que va-t-il émerger de cette nouvelle culture mélangeant la culture historique de votre organisation et cette culture agile ? Votre culture actuelle est-elle un frein ou un vecteur d’accélération à l’adoption de l’agilité ? Votre culture est-elle homogène dans toute l’entreprise ou bien locale à chaque équipe ?

Exemple 1 :  une organisation dans laquelle la peur d’échouer est très présente ne sera pas à l’aise avec le principe “test and learn” sous-jacent à l’agilité.

Exemple 2 : une organisation hautement hiérarchisée et centralisée aura de vraies difficultés avec la délégation et la responsabilité à accorder aux équipes.

Exemple 3 : une organisation qui érige l’excellence individuelle comme principe de reconnaissance aura du mal à reconnaître l’équipe dans sa globalité comme entité performante. On constate souvent dans ce cas des injonctions contradictoires qui déboussolent les équipiers entre la reconnaissance individuelle issue des modèles d’évaluation annuels et l’attente de collaboration au sein des équipes.

Concernant les comportements, vous pouvez vous demander : Quels sont les comportements dominants de mes collaborateurs ? Comment les évaluer ? Comment votre culture influence-t-elle le comportement de vos collaborateurs ? Ces comportements sont-ils un frein ou une opportunité pour adopter l’agilité ? Comment serait-il souhaitable que ces comportements évoluent ? Comment agir sur ces comportements ?

Pour appréhender cette situation initiale, nous disposons d’une démarche et d’outils d’analyse vous en offrant une lecture simple. Sans cette prise de conscience, il n’est pas possible de changer fondamentalement et d’ajuster votre transformation à votre contexte spécifique. Chaque organisation est en effet unique et sa transformation doit être complètement calée sur ce qu’elle est au départ et souhaite devenir. Sur la base de cette compréhension initiale, nous vous proposons un accompagnement mêlant la fois du coaching professionnel et du mentoring de vos personnes clés ou un coaching collectif d’équipe.

Pour en savoir plus vous pouvez consulter nos offres de conseil et de coaching :

• L’offre de conseil en entreprise agile : https://agile-enterprise-partner.com/articles/work/conseil-en-agilite-dentreprise/
• L’offre de coaching de managers : https://agile-enterprise-partner.com/articles/work/coaching-de-dirigeants-et-managers/
• L’offre de coaching de collaborateurs et d’équipes : https://agile-enterprise-partner.com/articles/work/coaching-de-collaborateurs/

L’article Faire de l’agile ou être agile ? est apparu en premier sur Agile Enterprise Partner.

Le PI Planning de SAFe concentre toutes les attentions tant cet événement est marquant dans la vie d’un incrément de programme. L’Inspect & Adapt, la cérémonie d’amélioration continue de niveau programme, est pourtant toute aussi importante et difficile à préparer que le PI Planning.

L’inspect & Adapt une combinaison de revue et de rétrospective sous la responsabilité du RTE³

Comme dans toutes les cérémonies de niveau programme, c’est le RTE qui est aux manettes de l’Inspect & Adapt. Les participants sont les mêmes que ceux du PI Planning et de par sa nature hétérogène, elle nécessite aussi beaucoup de préparation.

L’inspect & Adapt se déroule en trois parties et dure en général 3 à 4 heures :

1. Une démonstration système des Features terminés les plus intéressants ;
2. Une revue des engagements du programme et des équipes ;
3. La résolution des problèmes systémiques.

1. La démonstration système à grande échelle

La démonstration système de l’Inspect & Adapt se déroule devant toutes les équipes du programme, les demandeurs et le management. Comme pour les autres démonstrations système, elle nécessite la collaboration du RTE, des Product Managers et de la System Team pour respectivement s’assurer de la logistique, des scénarios de démonstration et des environnements. A la différence des autres démonstrations système qui se déroulent en petits comités, celle-ci se déroule devant un large public et nécessite une logistique beaucoup plus importante. En effet, il faut que tout le monde puisse visualiser et comprendre la démonstration.

2. La revue des engagements du programme et des équipes

La revue des engagements de programme (PI objectives) ou d’équipe montre l’atteinte partielle ou totale des objectifs de PI fixés par le Business Owner lors du PI Planning. On y indique les causes d’atteinte partielle et le lien avec les fiches A3⁴ qui vont être traitées dans la partie suivante si le problème doit être adressé.

Cette revue est préparée en amont entre le RTE, le Business Owner, les Product Managers et les Scrum Masters et Product Owner des équipes. Cette préparation permet de déterminer les taux d’atteinte des objectifs de PI et de formaliser les causes d’atteinte partielle des objectifs.

Cette partie fait le lien direct avec la résolution des problèmes qui suit. En effet, la cause d’atteinte partielle d’un objectif peut être due à un problème systémique identifié. L’impact de ces problèmes est d’autant plus criant qu’il concerne plusieurs équipes.

3. La résolution des problèmes systémiques : anticipée dès le début de l’incrément de programme

Les problèmes systémiques (ceux qui concernent plusieurs équipes du programme) sont identifiés lors des 4 rétrospectives des différentes équipes du programme. Lorsqu’un tel problème est découvert, le Scrum Master doit le formaliser sous la forme d’une fiche A3 et la donner immédiatement au RTE. Le RTE se charge alors de voir avec les autres Scrum Masters si le problème les concerne aussi, de valider le degré d’urgence de son traitement (immédiat ou durant l’Inspect & Adapt) et de consolider des métriques pour comprendre son impact.

Le RTE consolidant toutes les fiches A3 au fur et à mesure doit les challenger, les dédoublonner, les rapprocher si elles sont similaires, suivre leur résolution si elles doivent être traitées immédiatement.

Afin d’être efficace, ce travail de constitution des fiches A3 se fait donc tout au long de l’incrément de programme. Il est extrêmement difficile de constituer ces fiches au dernier moment en fin de Sprint 4, les équipes ont en général oublié une bonne partie de ce qui s’est passé en début de PI et sont trop occupées à terminer leur dernier Sprint pour réellement avoir le temps de s’occuper de formaliser ces fiches.

L’animation de la résolution de problème en grande partie déléguée aux Scrum Masters

L’animation de cette troisième partie de l’Inspect & Adapt se déroule en sous-groupes. Dès la fin de la présentation des problèmes, formalisés sous forme de fiches A3, le RTE passe la main aux Scrum Masters pour animer des ateliers de résolution de problème en sous-groupes. Les sous-groupes sont constitués en temps réel autour des problèmes. Les participants d’un sous-groupe doivent avoir la capacité à résoudre le problème par eux-mêmes.

Les 6 étapes du Problem solving de l’Inspect & Adapt

Le RTE garde la main sur le cadencement des étapes 2 à 6, mais ce sont réellement les Scrum Masters qui en assurent l’animation, ils doivent être prêts à animer toutes ces étapes.

Chaque groupe doit ressortir de cet atelier avec une fiche A3 complète, une liste d’actions faisables dans le prochain incrément de programme et des porteurs identifiés au sein du groupe.

La formation nécessaire des Scrums Masters pour animer la partie résolution des problèmes / amélioration

Les outils proposés par SAFe comme l’analyse causale grâce au diagramme d’Ishikawa¹ (l’arête de poisson) ou les 5 pourquois² ne sont pas simples à appréhender pour tout le monde. Avant même l’analyse causale, la formalisation des problèmes sous forme de fiche A3⁴ est en elle-même une vraie difficulté si on n’y est pas formé. Le RTE doit impérativement former les Scrum Masters du train à l’utilisation des différents outils de l’Inspect & Adapt avant que le train ne démarre.

Des problèmes, oui, mais on peut aussi renforcer ce qui fonctionne bien

SAFe recommande l’analyse de problèmes pour la troisième partie, c’est effectivement efficace mais pas très positif. Certaines équipes peuvent mettre en place des outils ou des pratiques qui leur donnent une performance et un engagement meilleurs que les autres. Ce qui fonctionne bien peut être renforcé ou diffusé à d’autres.

Je vous recommande d’identifier plusieurs sujets de ce type avant l’Inspect & Adapt et faire travailler des groupes dessus au même titre que les problèmes, c’est bien plus positif !

Des actions d’amélioration à suivre tout au long de l’incrément de programme

L’Inspect & Adapt terminé, l’amélioration continue ne s’arrête pas là, il faut impérativement suivre l’avancement des actions que les groupes ont pris.

Les actions doivent avoir été planifiées dans des Sprints durant le PI Planning et celles-ci doivent être suivies par le RTE et les Scrum Masters durant l’ART Sync.

Conclusion

L’inspect & Adapt nécessite un véritable travail de préparation et d’anticipation tout au long de l’incrément de programme. Son efficacité a un véritable impact sur le moral des équipes tant lors de l’animation que lors du suivi des actions qui en découlent ; rien n’est plus frustrant que d’identifier des actions qui ne mènent à rien par la suite !

Aller plus loin : Notre offre de conseil en entreprise agile, Vous former à SAFe par la formation Leading SAFe.

Articles connexes :

1. Le RTE clé voute du PI Planning
2. Adieu COPILs, bienvenue aux ART Sync

¹Diagramme d’Ishikawa : https://fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets

²5 pourquois : http://www.wikilean.com/Articles/Kaizen/1-La-resolution-de-problemes-20-articles/2-Le-5-pourquoi

³RTE (Release Train Engineer) : Scrum Master du programme SAFe.

⁴Fiche A3 : formalisme pour décrire un problème dans sous la forme d’une fiche qui tient au format A3. Exemple.

L’article SAFe Inspect & Adapt, une alliance incontournable RTE / Scrum Masters est apparu en premier sur Agile Enterprise Partner.

Issu du Framework SAFe, le rôle de RTE (Release Train Engineer) est le plus critique d’un bon déploiement de l’agilité à grande échelle. Le RTE pose le cadre méthodologique et veille à sa bonne application tout en améliorant le système au fur et à mesure. Maitriser le Framework ne suffit pas, le RTE doit aussi disposer de qualités humaines certaines pour pouvoir mener à bien ses missions.

RTE clé de voute du trio de gouvernance programme

La gouvernance du niveau programme de SAFe s’appuie sur le trio Release Train Engineer (RTE), Product Manager et System Architect. Là où le Product Manager est garant du contenu fonctionnel du train et le System Architect, garant de l’architecture, le RTE est garant du cadre méthodologique.
Le RTE met tout en œuvre pour que le train parte toujours à l’heure, qu’il puisse avancer en toute circonstances avec un contenu de qualité fourni par ses deux rôles partenaires.

Le RTE, Scrum Master des Scrum Masters

Pour les adeptes de Scrum, le premier rôle visible et simple à appréhender du RTE est celui de Scrum master des Scrum Masters. Le RTE organise deux fois par semaines des ART Sync (voir l’article sur les ART Sync). Equivalents de Scrum Of Scrum avec les Scrum Masters et les Product Owners, cet événement a pour objectif d’identifier tous éléments pouvant bloquer tout ou partie du train agile et si nécessaire de définir les actions de contournement.

Le RTE veille à la montée en compétence des Scrum Masters des différentes équipes et à leur bonne appropriation des différents événements qu’ils doivent faciliter en commun.

Le RTE facilitateur des principaux événements de niveau programme

Le RTE s’appuie en effet sur les Scrums Master pour faciliter l’événement principal de SAFe, à savoir le PI planning. Véritable grand-messe qui réunit l’intégralité des équipes agiles et des donneurs d’ordre du programme, cet événement réuni des dizaines de personnes qui doivent collaborer de manière efficace durant les deux jours pour débroussailler le travail sur plusieurs Sprints. Le RTE et les Scrums Master s’assurent de leur alignement durant les deux sessions de team breakout. Pour cela ils doivent se coordonner de manière étroite et rapide durant les deux jours. Faciliter un PI Planning revient à surveiller une douzaine de casseroles de lait sur le feu proches de l’ébullition… cela demande une vraie capacité à jongler et un calme olympien.

Pour préparer cet événement le RTE doit s’assurer de la qualité des Features qui lui sont fournis par les Product Managers et System Architects, de la logistique de la salle, des fournitures, de la présence des parties prenantes, de l’agenda des différentes interventions… une telle mobilisation de moyens humains ne peut être freinée par un détail de logistique.
Préparer un PI Planning nécessite une vraie anticipation !

Hormis cet événement majeur, le RTE facilite l’ART Sync, l’Inspect and Adapt, les Systems Demos et potentiellement aussi le Release Management.

Alors à quoi ressemble un bon RTE ?

Vous l’aurez compris, RTE est un job full time les différents événements de niveau programme nécessitent de la préparation, de la coordination et de l’anticipation, son rôle de développeur des Scrums Masters est tout aussi crucial.

Le RTE doit avoir une vrai qualité d’écoute et de pédagogie relationnelle, une grande capacité d’organisation, de synchronisation et d’anticipation et une vraie intelligence de situation pour animer le PI Planning.

Le RTE doit adopter une posture haute pour fixer le cadre dans les différents événements qu’il facilite et une adopter une posture basse quant au contenu de ce qui est produit. Son style de leadership doit être à la délégation, notamment dans le PI planning qu’il ne peut animer seul sans l’aide des Scrum Masters.

Indispensable au bon fonctionnement du train, le RTE ne doit pas se transformer en sauveur et porter sur ses épaules tout le poids du train !

Si vous souhaitez déployer SAFe dans votre organisation, consultez nos offres de conseil en transformation.

Vous souhaitez former votre futur RTE et les autres rôles de management d’un train SAFe, participez à une formation Leading SAFe.

Vous êtes RTE et vous souhaitez continuer à transformer votre posture, le coaching de manager est fait pour vous.

L’article SAFe, le Release Train Engineer, clé de voute du train agile est apparu en premier sur Agile Enterprise Partner.

Que deviennent les vieux COPILs lorsque l’on passe à l’agilité à grande échelle avec SAFe ?

COPIL : coordination entre équipes, gestion des risques et dépendances  

Dans une approche classique, les comités de pilotage servent à coordonner piloter les risques, les jalons principaux et les dépendances avec d’autres projets. Ils débordent souvent sur des aspects opérationnels et viennent souvent constater des dérives difficiles à redresser.

Pourquoi sont-ils si peu efficaces ?

La lourdeur de leur préparation et la présence d’acteurs peu disponibles imposent une fréquence assez faible (en général un par mois) qui autorise les projets à dériver sur une durée trop importante. En effet, sur un mois une équipe a largement de dériver du plan établi et se retrouver dans une situation difficile par manque d’arbitrage et d’alignement intermédiaire.

L’ART Sync SAFe

SAFe, le framework d’agilité à grande échelle propose un mécanisme très simple à mettre en place qui permet de créer un alignement quasi permanent entre les équipes et une gestion des risques au plus près : l’ART Sync. Cet événement bi-hebdomadaire de 15 minutes sous l’égide du RTE (Release Train Engineer)  regroupe les Scrums Master et les Product Owners des équipes agiles du train¹. L’événement se tient devant le Program Board et le Tableau des risques tous deux construits lors du PI Planning.

Deux questions simples se posent à chacune des équipes : y-a-t-il un Feature en risque dans l’équipe ? existe-t-il un risque systémique actif dans l’équipe ?

Si une équipe a un Feature en risque, le RTE propose alors de traiter en rechercher en séance une solution pour sécuriser sa production. Pour cela il s’appuie sur les autres équipes qui peuvent proposer leur aide ou en cas d’impossibilité, le RTE peut chercher à éliminer un Feature moins prioritaire (WSJF plus faible) et dégager la capacité pour sécuriser celui en risque. Si une solution est trouvée en séance, le train reprend son cours, les Scrum Masters et Product Owner pouvant immédiatement communiquer aux équipes les retours de l’ART Sync.

Si la recherche de solution ne peut-être résolue en séance, elle est traitée en aparté et peut nécessiter de mobiliser les parties prenantes du train pour arbitrer sur l’élimination ou la dégradation d’un Feature important du PI. Dans tous les cas, les risques portant sur le contenu de l’incrément de programme sont immédiatement rendus visibles aux parties prenantes qui peuvent arbitrer au plus tôt.

Se tenant à une fréquence bi-hebdomadaire, les ART Sync, ne laissent jamais dériver le train qui reste en permanence sur ses rails. Cet événement renforce la collaboration entre les équipes et le pilotage par la valeur central au fonctionnement de SAFe.

Pour aller plus loin, consultez nos offres de conseil sur SAFe et nos formations Leading SAFe.

¹Train : ensemble des équipes agiles qui participent à la construction d’un incrément de programme dans le framework SAFe.

L’article Adieu COPILs, bienvenue aux ART Sync SAFe est apparu en premier sur Agile Enterprise Partner.