Pourquoi doit-on faire du Search eXperience Optimisation ?
Discipline peu répandue mais à fort potentiel, le Search eXperience Optimisation (SXO) est un agrégat des bests practices de l’UX et du SEO.
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.
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 :
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.
Le niveau du train est celui que nous allons détailler dans cet article.
On retrouve dans le train plusieurs éléments de valeur :
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.
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.
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 d’alignement sont capitales dans le framework SAFe.
Elles sont au nombre de trois :
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 :
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.
Après le PI Planning, l’ART Sync reste, selon moi, la cérémonie la plus importante.
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.
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.
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 :
📚 Lire notre article sur la rétrospective
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.
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 :
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.
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.
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision