Pourquoi adopter le framework SAFe et pas un autre ?

Je suis pratiquant de l’Agilité à l’échelle depuis 10 ans et SPC depuis l’année dernière. SPC est le diplôme donné par SAFe à ceux qui sont en mesure de déployer SAFe en entreprise. Je publie une série d’articles concernant SAFe en ayant à la fois le bagage théorique et la pratique de longue date. Le contenu reste mon avis personnel, donc discutable, mais avisé.

Il existe de nombreux frameworks Agile. SAFe ou Scaled Agile Framework est aujourd’hui le plus populaire. Effet de mode ou vrai évolution ? Faut-il adopter ce framework ou se tourner vers un autre ? La réponse est OUI ! SAFe est LE framework à adopter et cet article va vous expliquer pourquoi. Mais attention, SAFe n’est pas adapté à tous les contextes. Explications…

Qu’est-ce que SAFe ?

SAFe ou Scaled Agile Framework est un framework d’Agilité dit à l’échelle, c’est à dire adapté pour les grands projets ou les grandes organisations. Il permet la coordination des activités de collaborateurs travaillant conjointement à l’atteinte d’un objectif commun. SAFe organise cette collaboration au-delà de 50 personnes jusqu’à plusieurs milliers. Les projets en question peuvent être IT ou non IT mais sont plutôt des projets de développement, c’est à dire la conception d’un produit, qu’il soit physique ou informatique.

Dans quels cas SAFe n’est pas recommandé ?

Si votre projet consiste à organiser des tâches répétitives comme un support technique ou une chaîne de production, d’autres frameworks sont plus adaptés comme Kanban ou Lean. Même dans ce contexte défavorable, vous pourriez être intéressés par certains aspects de SAFe. En effet, ce dernier intègre les modes de fonctionnement de Lean et de Kanban et propose des enrichissements.

Si votre projet n’implique pas plus de 10 personnes, vous devez résolument vous tourner vers Scrum et son mode de fonctionnement en équipe Agile. Scrum a fait ses preuves de longue date. Cette notion d’équipe Agile Scrum est au cœur SAFe. Le rajout de SAFe est la coordination de plusieurs équipes Agile.

Si vous êtes dans ce contexte de plusieurs équipes Agile mais que vous êtes en dessous de 50 personnes, SAFe risque d’être trop lourd pour votre besoin. La simple pratique de « Scrum of Scrum » décrite initialement dans Scrum et détaillée depuis 2017 dans Scrum at Scale est suffisante.

Maintenant, si vous êtes dans ce contexte de développement d’un produit, qu’il soit logiciel ou matériel et qui implique plus de 50 personnes, SAFe est à privilégier et voici pourquoi.

SAFe est le framework à l’échelle le plus populaire

Selon le 15ème rapport annuel de l’état de l’art du déploiement Agile publié par Digital.ai, le framework SAFe est adopté dans 37% des cas, loin devant son challenger Scrum@Scale / Scrum of Scrums qui est adopté dans 9% des cas et plus adapté dans les situations impliquant moins de 50 collaborateurs. Les autres frameworks sont beaucoup moins déployés.

Les autres frameworks ne traitent qu’un aspect particulier du besoin à l’échelle

Dans la présentation que j’ai faite à Agile en Seine en septembre 2021, « Panorama des frameworks Agile à l’échelle » et dont vous pouvez consulter les slides et la vidéo, j’ai montré que les frameworks challengers, qui totalisent chacun entre 1% et 6% d’usage sont généralement très spécialisés et n’adressent qu’un aspect particulier de l’Agile à l’échelle. Même s’ils apportent quelques petites choses intéressantes, ils ne sont pas suffisants pour couvrir tous nos besoins.

Par comparaison, SAFe adresse un panel de situation bien plus large et peut être comparé à un couteau Suisse de l’Agilité. Il est important de savoir que SAFe regroupe de nombreux concepts qui ne viennent pas tous de SAFe. Exploiter ces concepts, c’est faire de SAFe, même si ce n’est pas SAFe qui l’a inventé.

Les frameworks maison pas toujours Agile

Les 19% de « Don’t know » mentionnés dans le 15ème rapport annuel cité précédemment correspondent à des implémentations maison de l’Agilité. Ces méthodes maison sont issues généralement de pratiques historiques ancrées dans l’entreprise, de compromis faits pour que « ça passe » dans la culture de l’entreprise ou d’ajustements pour maquiller en Agile des pratiques Cycle en V ancrées ou des processus d’entreprise anciens et peu flexibles. Dans certains cas, plus rares, l’utilisation d’un framework Agile maison est nécessaire en raison d’un contexte bien spécifique. Il y a également ceux qui disent ne pas faire de SAFe à cause de sa réputation ou tout simplement pour éviter le paiement des licences d’utilisation du framework et ceux qui ne prennent qu’un petit bout de SAFe auquel ils rajoutent des pratiques venant d’ailleurs.

Dans ces contextes là, il est important de se poser la question de la présence de « Fake Agile », c’est à dire l’usage d’un vocabulaire Agile pour caractériser un mode de fonctionnement que ne l’est pas. Un lieu où le dysfonctionnement est la règle et l’efficacité le grand absent. Il y a de nombreux moyens de détecter le « Fake Agile », mais ce n’est pas l’objet d’aujourd’hui.

Dans les 8% de « Others », nous devrions trouver notamment des frameworks proposés par des cabinets de consultants qui vont justifier leurs émoluments en faisant la promotion de pratiques différentes qui ne sont généralement que des reformulations des autres frameworks.

SAFe pour toutes les tailles de projets à l’échelle

Au delà de 50 personnes, SAFe s’adapte à toutes les tailles de projets à l’échelle. Jusqu’à 100 personnes, la configuration « SAFe Essential » incluant le fonctionnement avec un train est adaptée. Dans SAFe, un train est un regroupement d’équipes avec une animation spécifique pour synchroniser les réalisations des équipes. Si le projet est composé de plusieurs centaines de personnes, la configuration « SAFe Large Solution » est à privilégier. Elle permet de faire fonctionner plusieurs trains indépendants et de les coordonner. Pour Agiliser le Business de l’entreprise, la configuration « SAFe Portfolio » permet d’identifier, rendre visible et prioriser les enjeux stratégiques de l’entreprise et leur déclinaison dans les projets. Enfin, si vous souhaitez Agiliser l’ensemble de votre entreprise, la configuration « SAFe Full » cumule l’ensemble des configurations pré-citées.

SAFe propose des solutions à tous les niveaux de l’entreprise pour toutes les problématiques qu’elles peuvent rencontrer. Le framework évolue tous les six mois en prenant en compte les nouvelles problématiques remontées par les entreprises. Ainsi, il est toujours au goût du jour.

Une décision managériale délicate

La décision de passer à SAFe ou à autre chose doit in fine être prise par un ou plusieurs managers qui ont la responsabilité d’un périmètre d’une centaine ou de plusieurs centaines de collaborateurs et où chaque journée gaspillée coûte une fortune. Lorsqu’ils se posent la question de passer à SAFe, c’est généralement à un moment où leur connaissance de SAFe est limitée ou inexistante. On parle d’Agile, donc de SAFe, tout le monde y va, donc cela doit être considéré, même si on ne sait pas tout ce que cela entraine.

Dans leur position, il est délicat de choisir autre chose que le framework le plus populaire au monde sachant qu’il n’existe pas d’autres alternatives sérieuses hormis pour les petits projets. S’ils prennent une décision différente, ils créent un risque sur le projet qui leur sera directement reproché si celui-ci tourne mal. Il est difficile de décréter, dès le début, que SAFe n’est pas adapté à notre contexte « compliqué » et se tourner vers une mixture maison. Tous les contextes d’entreprise sont compliqués !

Les pratiques des développeurs au cœur du framework

SAFe intègre au cœur de son framework les pratiques Agiles des développeurs. Le Continuous Delivery Pipeline, dont vous voyez l’image ci-dessous extraite de la page d’accueil du site, au plein milieu du schema représentant SAFe, se décompose en quatre notions :

  • Continuous exploration : s’aligner sur le besoin des utilisateurs (Backlog et priorisation)
  • Continuous integration : prototyper et développer par petits morceaux le produit pour récupérer le feedback des utilisateurs et adapter en conséquence la suite des développements (User Stories)
  • Continuous Deployment : déployer en production régulièrement avec le niveau de qualité requis notamment les tests de non régression (chaine d’intégration continue et automatisation des tests)
  • Release on Demand : mettre à disposition les nouvelles fonctionnalités à tout instant, sur demande.

Au cœur du framework, se trouvent également toutes les pratiques autour du DevOps (ainsi que le DevSecOps) et la notion de System Team qui est chargée de mettre à disposition des équipes les outils et environnements nécessaires aux développeurs.

La notion de System Demo, à chaque fin de sprint, c’est à dire toutes les deux semaines, incite toutes les équipes à intégrer leurs développements dans un unique environnement et ainsi traiter en temps réel tous les problèmes d’intégration.

Une adoption facilitée pour les nouveaux arrivants

Les projets d’envergure couverts par SAFe nécessitent beaucoup de monde et font appel à des sociétés de prestation. Les prestataires lorsqu’ils arrivent sur le projet doivent monter en compétence sur le contexte métier de leur prestation. Si l’entreprise a fait le choix d’un autre framework que SAFe, ils doivent également monter en compétence sur la pratique Agile de l’entreprise alors que si SAFe avait été privilégié, le prestataire devrait être sur un terrain connu, d’où un gain de temps dans son intégration. Leur montée en compétence est donc simplifiée et concentrée sur le contexte métier de l’entreprise.

Réduire les débats d’Agilistes spécialistes

Si vous demandez à dix Agilistes spécialistes de réfléchir à la mise en œuvre d’une nouvelle pratique, vous obtiendrez probablement dix propositions, certaines similaires, d’autres antagonistes. Laquelle choisir ? Chaque spécialiste fera la promotion de SA solution au détriment des propositions antagonistes. C’est consommateur de temps et d’énergie et vous risquez d’avoir des tensions importantes pour obtenir un consensus, tout cela au détriment du projet. Les propositions n’étant pas éprouvées, il est difficile d’identifier celle qui est la plus adaptée. Et dans tous les cas, la mise en œuvre sera compliquée car expérimentale.

Quand on n’a pas d’idée, on se tourne vers SAFe

Dans les projets où l’Agilité est déjà déployé, si une problématique nouvelle est identifiée, non couverte par l’Agilité mise en place, le premier reflexe est de se tourner vers SAFe : « que propose SAFe dans ce cas ? ». Dans la majorité des cas, SAFe couvre déjà ce cas car il évolue chaque semestre en s’enrichissant de réponses à des problématiques remontées par les entreprises clientes.

Aucun autre framework n’évolue de cette manière, une mise à jours tous les six mois. Sans SAFe, les Agilistes spécialistes devraient réfléchir à une réponse à apporter à cette situation et proposer la mise en place d’une expérimentation, là où SAFe propose une solution testée dans une autre entreprise et donc éprouvée.

Un vocabulaire commun

Chaque framework a son vocabulaire. Les déploiements en entreprise peuvent être générateurs d’un vocabulaire spécifique. La première difficulté pour s’entendre et se comprendre, c’est de partager un vocabulaire commun, avec une définition claire et non ambigüe. Adopter SAFe, c’est adopter son vocabulaire, définitions incluses, et donc faciliter la compréhension de ce que l’on déploie. Attention toutefois à ceux qui comprennent ce qu’ils veulent comprendre. Il arrive régulièrement que, bien qu’en se basant sur SAFe, la compréhension d’un concept puisse être mal comprise par certains et que la mise en œuvre soit éloignée de ce qui est préconisé. En effet, SAFe présente un certain nombre de principes mais ne décrit pas le comment.

En conclusion

De part sa boite à outils tout terrain et sa grande popularité, les principes du framework SAFe sont devenus incontournables. Les frameworks challengers sont moins disants et ce n’est que dans le contexte des projets à petite échelle (entre 10 et 50 personnes) que l’on se tournera vers un autre framework, en l’occurrence Scrum at Scale jusqu’à 50 personnes et Scrum si moins de 10 personnes. Attention aux frameworks maison qui peuvent cacher des pratiques « Fake Agile » ou générer des débats de spécialistes sans valeur pour le projet.

Mots clés : , , , ,

  1. GRANDEMANGE le 04.04.22 à 21:03

    Kool faut que j’essaye.

    Merci

Ajoutez un commentaire