Le framework SAFe : démystification par un RTE

Le framework SAFe est très complexe à appréhender car il fonctionne comme des poupées russes. Alors comment l’établir et le modeler en fonction de son contexte et produit? Réponse dans cet article à travers mon expérience de Relase Train Engineer.

Débuter avec SAFe

Le site de Scaled Agile (SAFe étant l’acronyme de Scaled Agile Framework) donne la définition suivante : une base de connaissances de principes, de pratiques et de compétences pour Lean, Agile et Devops qui sont tirés de l’expérience et qui ont fait leurs preuves.

Comme d’autres cadres plus connus, tel que Scrum, SAFe est avant tout un framework que les organisations peuvent utiliser pour se structurer.

SAFe a été créé par Dean Leffingwell en 2011 sur les bases de Scrum, un framework qui disposait de certaines limites selon Leffingwell.

La principale : Scrum peut se montrer limité dans des organisations complexes (à partir de 200 personnes, par exemple), et c’est justement dans ce contexte que SAFe apporte une valeur importante.

Le Framework SAFeSource :

SAFe, un framework à appréhender

Si vous n’êtes pas connaisseur de SAFe, je vous conseille vivement de passer un peu de temps sur le site officiel de Scale Agile et notamment de naviguer au sein du framework qui est disponible en page d’accueil.

Chez Hubvisory, nous avons essayé de résumer le framework pour en simplifier la présentation.

Framework SAFe 5.0 simplifié

SAFe contient ce qu’on appelle plusieurs “niveaux”. Le framework est organisé à la manière de poupées russes concernant les éléments de valeur.

Premier niveau : le “Portfolio” contient des Epics qui sont la déclinaison des thèmes stratégiques de l’entreprise, et qui sont organisées en fonction de la chaîne de valeur de l’entreprise. Ces Epics sont gérées par des Epic owners.

Deuxième niveau : le niveau “Large Solution” comprend des capabilities. Une capability correspond à un élément de valeur produit par plusieurs trains. Ces capabilities sont gérées par le solution management.

Troisième niveau : le Train. Ce niveau est nommé “Essential” dans le schéma ci-dessus, puisque c’est ici que s’opère le delivery.

Comment fonctionne un train dans SAFe?

Le niveau du train est celui que nous allons détailler dans cet article.

On retrouve dans le train plusieurs éléments de valeur :

• Les features Business, pilotées par les Product Managers
• Les Enablers (qui sont en fait des features techniques), pilotés par les architectes.

Ces mêmes features et enablers sont ensuite découpés en User Stories au niveau des équipes qui, elles, fonctionnent la plupart du temps suivant le framework Scrum.

📚 Lire notre article sur les User Stories

Le train comporte en moyenne entre 70 et 250 personnes. Ainsi, étant donné le nombre de personnes à synchroniser, le Framework prévoit plusieurs événements.

Le Program Increment planning (PI planning) aide l’ensemble du train à se synchroniser avec les autres niveaux et permet de planifier l’activité à l’échelle d’un Program Increment (PI). Ce dernier dure en moyenne 5 sprints (ou itérations), environ 3 mois en fonction de la taille de vos sprints : le PI est en quelque sorte au train ce que le sprint est à l’équipe.

Le Release Train Engineer

Comme expliqué précédemment, le Release Train Engineer, autrement appelé RTE, est au service du train (servant leader). A titre de comparaison, son rôle correspond à celui du Scrum Master dans la méthode Scrum.

📚 Lire notre article sur Scrum.

Les missions du Release Train Engineer

• planifier et présider les cérémonies qui composent un PI
• gérer le flux du backlog de features et enablers features

Le RTE est garant des cérémonies. Cependant, elles peuvent légèrement différer de la théorie à la pratique.

Les cérémonies

Les cérémonies d’alignement sont capitales dans le framework SAFe.

Elles sont au nombre de trois :

• L’ART (Agile Release Train) Sync permet la synchronisation des backlogs des équipes du train
• Le Scrum of Scrum rassemble les Scrum Masters du train
• Le Product Owner Sync rassemble les Product Owners du train pour échanger autour du produit.

Dans mon train, je ne réalise que l’ART Sync.

Cependant, je ne concentre pas seulement cette cérémonie sur la synchronisation des backlogs mais aussi sur les problématiques produit ou liées au fonctionnement des équipes.

📚 Lire notre article sur le backlog

C’est d’ailleurs le premier conseil que je peux donner concernant le modèle SAFe, à savoir : adapter le framework à son équipe. Attention à prendre ce conseil avec des pincettes puisque le rôle du RTE est d'être garant de la méthodologie et du maintien des pratiques issus de SAFe.

En revanche, au sein de ma mission, les équipes ont à de nombreuses reprises exprimé leur mécontentement sur la valeur versus la quantité des cérémonies. Nous avons donc rationalisé certaines cérémonies. Cela a été sans impact sur la synchronisation, tout en permettant aux équipes de récupérer un temps précieux.

J’ai donc fait l’impasse sur la PO Sync et le Scrum of Scrum. Les équipes dans lesquelles j’interviens travaillant surtout sur des sujets d’infrastructure, l’impact de la suppression de ces cérémonies a été très faible.

J’organise donc l’ART Sync chaque semaine sur un créneau d'1h30. Le triumvirat (trio qui regroupe le Release Train Engineer, le Product Manager et le System Architect) et tous les Product Owners doivent être obligatoirement présents. Dans le cas où un Product Owner ne peut pas être présent, il doit trouver un remplaçant.

Voici un ordre du jour classique de l’ART Sync :

• Partie 1 - Informations générales : pendant 10 minutes, on communique sur les messages qui concernent tout le train. Cela peut être par exemple lié à l’arrivée d’un nouveau membre dans le train, des sujets d’actualité globaux
• Partie 2 - Passage des équipes : chaque équipe prend 8 minutes pour présenter le board de son itération (ou sprint) en faisant le focus sur les risques rencontrés qui peuvent impacter les autres équipes. Cela permet au Product Manager et au System Architect (SA) de mener les actions nécessaires pour débloquer certains points et avoir de la visibilité sur les sujets générant des adhérences.

Attention, un sujet dérivant qui concerne une seule équipe peut avoir un impact sur tout le train si cela met en péril ses travaux sur une adhérence. Ne vous laissez pas piéger.

• Partie 3 - Client : pendant 10 minutes, on analyse le besoin de passer des messages à nos utilisateurs dans le cadre de nos mises en production. Cette partie est à adapter selon son produit, car elle peut être différente si le produit travaillé est un produit en interne ou bien un produit à destination du grand public.

Après le PI Planning, l’ART Sync reste, selon moi, la cérémonie la plus importante.

Affinage du backlog (ou refinement)

Similaire à celle que l’on retrouve au niveau Scrum, cette cérémonie permet aux Product Owners et au Product Manager de synchroniser et préparer les backlogs en vue du PI planning.

Calcul du Weighted Shortest Job First (WSJF) pour une featureSource :

Vous ne retrouverez pas cette cérémonie au niveau “Essential” dans le framework car en théorie, ce travail est mené par les Product Owners et le Product Manager en parallèle pendant le PI.

Avec mes équipes, je prévois une cérémonie d’affinage par Itération puis une cérémonie chaque semaine pendant la phase d’Innovation & Planification (ayant lieu le dernier sprint du PI). Au cours de la cérémonie d’affinage,il est essentiel que les Product Owners, le Product Manager et le System Architect soient présents.

Bien que cela ne soit pas, en théorie, la mission du RTE, j’ai souhaité avoir la gestion de cette étape car cela permet de s’assurer que l’affinage soit bien réalisé avant le PI planning.

Ayant effectué 7 PI, je remarque que cette solution est bénéfique car elle permet aux équipes d'être prêtes en arrivant le jour du PI planning, elles peuvent ainsi se concentrer sur les dépendances externes au train et à la mise à jour de Jira.

System Demo

Cette cérémonie se rapproche de la démo que vous connaissez en Scrum. L’objectif étant de présenter aux parties prenantes ainsi qu’aux clients la valeur délivrée par les équipes.

Ainsi, à chaque fin d’itération (sprint), les équipes présentent les features délivrées ayant une valeur pour les clients.

Si vous travaillez dans une chaîne de valeur qui comprend plusieurs trains avec des sujets liés et des parties prenantes transverses, n'hésitez pas à consulter les autres RTE pour organiser les démos à la suite. Les intéressés peuvent ainsi réserver du temps pour une session de démo commune.

Inspect & Adapt

L’Inspect & Adapt (I&A) du train a pour intérêt de regrouper l’ensemble des équipes au moins 1 fois par PI planning pour travailler sur l’amélioration continue.

_Exemple d’un atelier pour une rétrospective d’équipe_Source : https://www.neatro.io/daki-retrospective/

Cette cérémonie se déroule la dernière semaine du PI. Dans mon train, j’invite l’ensemble des équipes et triumvirat pour 2h de rétrospective.

Le point est organisé de la manière suivante :

• Partie 1 : pendant 30 / 40 minutes, je présente les statistiques du train. Cela me permet de mettre en avant l’atteinte des objectifs, l’engagement des équipes et d'ouvrir sur les points à améliorer.
• Partie 2 : la rétrospective. Elle dure en général 60 à 80 minutes avec un atelier qui varie d’un PI à l’autre. La rétrospective est le cœur de l’Inspect & Adapt. C’est le moment où on utilise un atelier pour permettre aux personnes du train de s’exprimer sur leur problématique, points de blocages, points de satisfaction...

📚 Lire notre article sur la rétrospective

• Partie 3 : la fiche Kaizen. Dernière étape de l’I&A, cette partie dure 30 minutes pendant lesquelles on détermine les points d’amélioration que l’on souhaite embarquer dans le PI avec les équipes et les leaders de chacun des points.

Cette cérémonie est intéressante car elle permet aux équipes de remonter les points de frustration systémiques qu’ils ne peuvent pas gérer à un niveau local notamment.

PI planning

C’est l’événement phare du framework qui se prépare tout au long du PI précédent. L’objectif est de préparer le plan des équipes pour les 3 prochains mois.

PI PlanningSource :

Au sein de ma mission, je suis principalement le même agenda que celui proposé par le framework ci-dessus. Cependant, voici les adaptations que nous avons mis en place :

• La première partie est réduite en temps
• On a 2 team breakout de plus mais sur une plus courte période
• Le déjeuner dure 1h et correspond à une vraie pause.

Incontestablement, il s’agit de l’événement le plus important pour les équipes qui vont devoir donner leur engagement pour les prochains mois en tentant de s’y tenir au maximum.

Un PI planning peut être bouillonnant d’idées mais c’est aussi fatiguant alors rappelez-vous que l’anticipation et l’organisation restent la clé pour que vous puissiez vivre sereinement ces 2 jours.

En conclusion

Au sein d’organisations complexes, le modèle SAFe a prouvé qu’il était bénéfique, et plus compatible que le modèle Scrum. Cependant, comme tout modèle, il est essentiel de le comprendre et de l’adapter plus ou moins à son organisation pour délivrer un produit de qualité, c’est cela la clé de réussite. Et c’est cela la mission du Release Train Engineer.