Le framework SAFe est-il dépassé ?

  • mise à jour : 25 septembre 2024
  • 7 minutes
Article écrit par

Antithèse agile, bureaucratie kafkaïenne, cadre rigide… Les qualificatifs peu flatteurs sont parfois nombreux quand il s’agit de parler de SAFe, le principal framework pour faire évoluer l'Agilité à l'échelle de l'entreprise. Mais ces critiques sont-elles justifiées, ou SAFe est-il victime d’une mauvaise presse, alimentée par certaines idées reçues ? Pour le savoir, nous avons interrogé plusieurs experts Thiga sur leurs expériences terrain et leurs conseils pour maximiser les bénéfices de ce framework.

Londres, mars 2024. Carlos González De Villaumbrosia, fondateur de la Product School, jette un pavé dans la mare lors de la conférence ProductCon en critiquant sans détour le Scaled Agile Framework (SAFe). Selon lui, les intentions sont bonnes mais le framework est devenu trop complexe, trop focalisé sur le delivery plutôt que sur l’impact, en oubliant les phases critiques de discovery et de Go-to-market.

Une critique régulièrement amplifiée par des voix influentes comme celle de Marty Cagan. Mais pourquoi tant de haine ? Revenons sur les principaux fondamentaux de SAFe pour déconstruire les mythes qui l'entourent et proposer une grille de lecture utile pour tout chantier de transformation.

🧑‍🍳 SAFe à la carte : à vous de choisir les ingrédients

SAFe 6.0 est défini par ses fondateurs comme une "base de connaissances composée de principes, pratiques et compétences intégrés et éprouvés pour atteindre la Business Agility en utilisant Lean, Agile et DevOps."

Le choix des mots interpelle. Car SAFe documente principalement des pratiques éprouvées qui existaient avant et qui existeront encore après. Il met en cohérence des domaines qui ont souvent tendance à travailler en silo, par exemple la user experience et le Product Management, versus le DevOps. C’est un cadre de référence et un langage commun pour aligner les équipes sur une roadmap de transformation et des compétences partagées, tout en permettant la flexibilité et l'adaptabilité nécessaires dans un marché en constante évolution.

"Souvent, le business parle business, l’IT parle IT et le marketing parle marketing. SAFe a l’avantage de poser un vocabulaire commun qui permet de dialoguer et d’éviter les incompréhensions", confie Romain Pabot, Coach Produit et Transformation Lead chez Thiga.

Une idée intimidante circule selon laquelle il faudrait tout appliquer dans SAFe pour réussir sa transformation. Mais utiliser SAFe, c'est avant tout faire des choix. Des choix entre différentes pratiques, associées à des compétences spécifiques, telles que le Design Thinking, Scrum ou encore la méthode OKR. À vous de choisir les compétences pertinentes et de piocher dans la boîte à outils pour les développer.

"Prenez dans SAFe ce qui vous intéresse. Si vous avez une problématique de convergence et d'alignement par exemple, peut-être que le concept de “train” - le Release Train (ART), un train virtuel composé d’équipes multidisciplinaires auto-organisées qui planifient, organisent et exécutent leur travail ensemble est pertinent pour vous. Dans ce cas, faites-le évoluer en fonction de la valeur et du retour des utilisateurs", confie Romain Pabot. 

SAFe est un modèle de conduite du changement par la pratique dont l'avantage réside dans sa capacité à être mis en œuvre rapidement. Vous avez à disposition une vaste littérature et de nombreux retours d’expériences de la communauté pour mettre en place rapidement les pratiques et outils. Prenons l’exemple des PI Planning, événements clés pour aligner le travail des différentes équipes autour d’objectifs communs. Entre la décision, la mise en œuvre et les premiers résultats, il se passe finalement peu de temps. Dès le premier PI Planning, des consensus autour de choix stratégiques sont trouvés en l’espace de quelques heures, accélérant les processus décisionnels. Non négligeable dans un contexte de transformation complexe et coûteuse.

Selon Renaud Chevalier, Partner Thiga et consultant certifié SPC (SAFe Program Consultant) depuis 2015, "SAFe est notamment utile pour de grandes entreprises qui opèrent toujours en mode projet MOA/MOE et où il y a de l’urgence, compte tenu des enjeux économiques post-covid et du Time to market qui n’est pas aligné aux enjeux business." C’est le concept de la “burning platform” de SAFe, qui évoque la métaphore d’une plateforme pétrolière en feu, où l'urgence force à prendre des décisions communes, radicales et rapides. 

Alors, quel est le point de départ pour choisir les pratiques SAFe adaptées à son contexte ? Vous pouvez établir un premier diagnostic à partir d’une matrice de maturité Agile et Produit pour identifier les premières aptitudes à développer en priorité dans le prochain PI, et permettre aux collaborateurs d’être performant. L’objectif étant de passer d’un SAFe mécanique à un SAFe professionnalisant.

L'adoption de SAFe doit être réfléchie et adaptée au contexte spécifique de chaque entreprise. Comme Marty Cagan le souligne souvent, les processus et les outils ne sont pas universels ou applicables de la même manière partout. Il faut s'assurer que les comportements et aptitudes qu'ils accompagnent sont en accord avec le contexte et les objectifs de la transformation. Bref, SAFe n'est pas une solution miracle, mais un cadre puissant lorsqu'il est adapté à vos besoins.

🤨 Une question d’état d’esprit

Que reproche-t-on à SAFe précisément ? Pour certains, le framework impose une rigidité qui contredit les principes mêmes de l'Agilité. Ces critiques accusent notamment  SAFe de devenir trop procédurier et de créer une bureaucratie qui ralentit les processus décisionnels. Cela peut conduire à une perte de flexibilité et à une résistance au changement.

Sans sponsorship fort, l’implémentation de SAFe est vouée à l’échec.

Alors oui, SAFe est un cadre et comme tout cadre les individus doivent suivre les mêmes règles et parler la même langue pour jouer collectif. La rigidité que certains attribuent à SAFe n'est pas intrinsèque au cadre lui-même, mais résulte souvent de problèmes de gestion du changement. Si le déploiement de SAFe devient rigide, c'est généralement parce que les équipes n’ont pas reçu le soutien adéquat pour s’approprier ces pratiques à travers les différentes phases du changement. Le modèle de change management ADKAR est une excellente boussole pour définir le plan d’action et soutenir les équipes sur les différentes phases de la transformation : 

  • A pour Awareness : Expliquer pourquoi le changement est nécessaire. 
  • D pour Desire : Motiver les individus à s’impliquer dans le changement.
  • K pour Knowledge : Communiquer les informations nécessaires pour expliquer comment opérer la transformation.
  • A pour Ability : S’assurer que les équipes possèdent les compétences nécessaire. 
  • R pour Reinforcement : Renforcer le changement pour assurer sa pérennité dans le temps. 

Pour Kai Hansen, consultant chez Peak Product, beaucoup de réflexions intelligentes de SAFe sont éclipsées par les règles et les processus. Les entreprises appliquent souvent le framework sans comprendre pourquoi elles le font, ce qui les empêche de s'aligner sur des objectifs communs. Il propose d'instiller avant tout le bon état d'esprit en se concentrant sur les principes plutôt que sur les règles. Les outils et processus peuvent ensuite être sélectionnés pour opérationnaliser ces principes.

“SAFe propose une hiérarchie de rôles qui peut rencontrer des écueils, mais cela a le mérite de mettre l’humain au centre. Il n’est pas parfait, mais il propose des évaluations régulières, des sondages, rétrospectives, de l’amélioration continue, et c'est puissant“, ajoute Élodie Dufour, consultante et coach Agile chez Thiga. Si l’Agilité nécessite une transformation culturelle, la prise en compte du facteur humain dans le changement est donc essentielle. Selon Renaud Chevalier, “il faut intégrer le middle management qui, jusque-là, n'a pas encore trouvé sa place dans SAFe. Sans sponsorship fort, l’implémentation est vouée à l’échec.” Première étape : les intégrer véritablement dans l’équipe de conduite de changement pour les rendre acteurs.

"SAFe met en avant la nécessité de personnes en transverse, ce qui devient critique quand on augmente de taille, affirme Romain Pabot. Cela peut aider le middle management à se projeter dans un rôle de “servant leader”, c’est-à-dire à se mettre au service des équipes qui, elles-mêmes, sont au service des clients."

La clé réside dans l'accompagnement du changement, où les leaders doivent encourager une compréhension profonde des principes Agiles, tout en offrant la liberté d'adapter SAFe en fonction des besoins spécifiques. SAFe ne dicte pas une façon rigide de travailler : c’est la culture que vous saurez mettre en place qui permettra aux équipes de conserver leur capacité à innover.

🚨 Spoiler alert : SAFe est une organisation Produit !

On reproche à SAFe d’être focalisé uniquement sur la delivery et les développements, plutôt que sur l’impact et la valeur. Syndrome de la “feature factory” ? 

Le framework met au cœur de son approche la Business Architecture, qui permet de structurer et aligner le travail sur les objectifs de l'entreprise et les besoins des utilisateurs. Un concept clé est celui des “value streams”, qui organisent le développement autour des étapes par lesquelles un produit ou un service passe pour apporter de la valeur à l'utilisateur. Par exemple, pour un prêt bancaire, cela inclut des étapes comme l'évaluation du prêt, la décision du prêt et la gestion du prêt. Ces étapes forment une chaîne de valeur, qui représente l'ensemble des activités nécessaires pour fournir ces services aux utilisateurs.

Aujourd’hui, certaines entreprises constituent leurs équipes Agiles autour de limitations finalement cognitives. Par exemple, le précepte selon lequel il faut limiter la taille des équipes à sept pour réduire et optimiser le nombre d'interactions. Le risque : démultiplier les équipes Produit, créer des silos et finalement créer cette fameuse “feature factory” dont l’objectif est de livrer fréquemment des fonctionnalités au détriment des enjeux stratégiques communs. Cette réflexion sur la taille est certes importante, mais il s’agit avant tout de se poser les bonnes questions lors de la création des trains : quels sont les services de mon entreprise ? Quelles sont les actions que mon utilisateur va pouvoir mener à bien ?

Pour accompagner la mise en place de SAFe dans un contexte de Business Architecture, il est important d'utiliser des exemples concrets et des copies pour aider les parties prenantes à comprendre les concepts”, confie Renaud Chevalier qui accompagne notamment le groupe La Poste dans l’identification de ses chaînes de valeurs. Par exemple, dans une grande organisation publique, les trains sont découpés en fonction de la chaîne de traitement des ressources humaines pour développer les systèmes et compétences nécessaires : paie, gestion du personnel, remplacements… Résultat ? Des dépendances contenues au minimum et des métiers embarqués. Le découpage leur permet d'avoir un nombre rationnel d'interlocuteurs du côté de la Direction des Systèmes d’Information (DSI) et d’être impliqués dans la co-construction des fonctionnalités majeures et la programmation du budget.

Comme le souligne Romain Pabot, "ce n'est pas parce que l'on suit SAFe selon les règles de l'art que l'on réussit. Il faut une connaissance intime du marché et ancrer ses décisions dans une stratégie business solide, pas uniquement être un expert des processus Produit." Il faut également lancer des mouvements progressifs et mesurables pour évaluer les bénéfices de cette nouvelle organisation, aux travers des grands indicateurs business de l’entreprise et de métriques opérationnelles telles que les DORA metrics (DevOps Research and Assessment) :

  • DF (Deployment Frequency) : la fréquence à laquelle du code est déployé en production.
  • MLTC (Mean Lead Time for Changes) : le délai moyen entre le début du développement et le déploiement en production.
  • CFR (Change Failure Rate) : le pourcentage de déploiements en production qui entraîne des incidents.
  • MTTR (Mean Time To Recovery) : le temps nécessaire pour restaurer un service stable après un incident.

Ces quatre grands indicateurs DORA permettent à l’organisation d’identifier les opportunités d’amélioration continue et de mesurer l'excellence opérationnelle des changements mis en place, et donc de traiter la transformation Agile tel un produit.

Interprété ou mal implémenté, SAFe peut effectivement créer des rigidités. Beaucoup échouent en se concentrant uniquement sur les aspects opérationnels et les processus, en oubliant la dimension de change management. La clé réside donc dans l’alignement sur une stratégie et des objectifs communs ; L’intégration et la formation des équipes et sponsors ; L'évaluation continue des pratiques. SAFe, adapté au contexte de l’entreprise, offre une structure solide pour réussir des transformations agiles à grande échelle. À vous de bien trouver ce que vous cherchez.

Si vous avez une question ou si vous souhaitez être accompagné.e, contactez notre équipe experte en organisation Produit.

La newsletter qui produit son effet

cover_pm-1

La newsletter Product Management

Contenus exclusifs, actualités, humeurs, devenez incollables en Produit