SAFe est il Agile?

SAFe (pour Scaled Agile Framework) est un cadre de travail pour l’agilité à l’échelle qui fournit une approche pour aider les entreprises à livrer de la valeur de manière plus efficace et agile, c’est-à-dire en s’adaptant aux changements qui peuvent venir de toutes parts : du client, mais aussi du contexte de solution, des innovations technologiques ou des règles de marché. Ce cadre de travail ou framework offre une synchronisation et une coordination des efforts entre les différentes équipes dans un environnement d’entreprise.

L’agilité est une philosophie de travail axée sur la collaboration, l’adaptabilité et l’itération. Elle met l’accent sur la livraison continue de la valeur aux clients et la flexibilité face aux changements.

SAFe est l’un des nombreux cadres qui appliquent les principes de l’agilité à grande échelle. Il comprend des rôles, des responsabilités, des artefacts et des événements spécifiques qui aident à structurer le travail en équipes agiles. Il est particulièrement utile dans les grandes organisations où de nombreux groupes de travail doivent collaborer pour livrer de la valeur.

Pourtant depuis quelques années, j’entends plus souvent la question de savoir si SAFe est toujours agile. Je vous propose de commencer avec deux points qui me semblent cruciaux : complexité et rigidité de SAFe

Complexité

SAFe est souvent critiqué pour sa complexité. Avec ses nombreux rôles, responsabilités, artefacts et événements, il peut être difficile à comprendre et à mettre en œuvre, surtout sans une formation appropriée.

Avant de poursuivre, il semble pertinent de réexaminer la définition de ce terme. J’aime me référer à cette définition : un sujet est compliqué lorsqu’il nécessite l’intervention de différentes compétences, de différentes personnes, etc.., mais qu’au démarrage, nous avons plus de sujets connus que d’inconnus. Nous disposons dès le départ d’informations suffisantes pour établir un plan à la fois réaliste et faisable, car nous n’avons pas besoin de mener des études, des activités pour déterminer comment nous allons faire, les résultats de ces démarches ayant un impact sur le plan prévu.

Un sujet complexe, en revanche, présente un défi différent. Dès le départ, nous sommes conscients que notre connaissance est incomplète et que nous devrons découvrir des éléments inconnus. Ces découvertes nous mèneront probablement vers de nouvelles voies inexplorées au moment de l’initiation du projet. Ces nouvelles voies seront nécessaires pour parvenir à notre solution. Les projets de recherche en sont un exemple typique. Au début d’un projet complexe nous avons plus de sujets inconnus que de connus, et nous serons donc contraints de prendre en compte ses apprentissages au fur et à mesure.

En conséquence nous devrions plutôt dire que SAFe est compliqué, il y a beaucoup de rôles, artefacts, événement mais qui sont précisément définis (https://scaledagileframework.com/), ce qui en a fait certainement, à mon sens, un facteur de réussite : Toutes ces explications étant rassurantes.

L’organisation cible est donc connue, mais comment y parvenir ? C’est cette application de SAFe qui est complexe : vous ne savez pas du tout au démarrage comment les collaborateurs de l’entreprise vont accepter ces nouvelles pratiques. Vont-ils accepter de voir leur rôle évoluer et entendre qu’ils doivent faire autrement, ce qui sous-entend qu’avant, ce qu’ils faisaient, n’était peut-être pas « bien ». Comment organise-t-on 120 personnes pour qu’elles travaillent efficacement pour …aussi longtemps que possible sur un sujet mal connu (votre client ne vous a pas tout dit !), unique (vous ne l’avez jamais fait avant !), dans un environnement mouvant (les règlementations changent, les contraintes du marché, votre concurrence…) avec une technologie qui avance rapidement (AI, efficacité matériel…) ?

C’est un problème complexe ! Difficile d’y apporter une seule solution simple à mon avis.

La mise en place de SAFe est donc très dépendante du facteur humain, ce n’est pas qu’une méthode à appliquer, c’est un framework, un ensemble d’outils, un cadre de travail à déployer, et c’est ce déploiement qui est complexe. On connait SAFe au démarrage mais on ne connait pas les problèmes que l’on va rencontrer lors de son déploiement. Ceux-ci peuvent être très variés, à titre d’exemple : l’acceptation des rôles, le changement de processus existants, les problématiques d’influences hiérarchiques, les refus de prise de responsabilités, la difficulté de collaborer avec d’autres rôles, l’influences des objectifs annuels différents sur différents silos d’organisation de l’entreprise … On va donc devoir adapter ce déploiement à ce que l’on va apprendre au fur et à mesure : savoir et vouloir s’adapter est essentiel. L’expérience de ces mises en place vous sera évidemment très utile. Ce n’est donc finalement pas SAFe qui est complexe, c’est plutôt l’ensemble de l’organisation qui la met en place et par conséquent, cette complexité que vous rencontrez sera présente quel que soit votre framework. Un avantage de SAFe est que ses principes et valeurs sont très décrits, et que vous pourrez vous y référer.

Par conséquent, quand on vous parlera d’industrialisation de transformation SAFe, méfiez-vous ! Comment pourrait-on industrialiser (répéter de façon mécanique) un processus qui comporte plus d’inconnu que de connu au démarrage !

Rigidité

Bien que l’agilité mette l’accent sur la flexibilité et l’adaptabilité, SAFe est parfois perçu comme étant trop rigide ou prescriptif. Il peut donner l’impression d’imposer une structure “top-down” qui peut entrer en conflit avec le principe d’autonomie et d’auto-organisation promu par l’agilité.

Mais qu’entend-on par agilité ? Selon le « manifeste agile » (https://agilemanifesto.org/), il s’agit de la capacité d’une équipe à s’adapter au changement tout en livrant régulièrement. Je pense que vous conviendrez que l’augmentation de la productivité d’une équipe n’est pas proportionnelle au nombre de ses membres. Cela est dû au fait que si vous avez plus de personnes qui collaborent, elles devront communiquer, se synchroniser, partager leurs apprentissages pour se réaligner, partager des connaissances sur les compétences nécessaires à la réalisation du produit, etc. Comme on dit “Seul on va plus vite, Ensemble on va plus loin”. La diversité des compétences permet de réaliser de nouveau produit, mais elle a un coût en organisation. Cela nécessite plus de temps, et exige donc une timebox plus longue que le sprint pendant lequel les objectifs ne changent pas. C’est ce que le SAFe appelle le PI (Planning Interval depuis la version 6.0). SAFe donne le temps et délègue la synchronisation entre les équipes à celles-ci, qui doivent le planifier lors du PI Planning et le réaliser au cours du PI. Évidemment, en un sens, cela réduit l’agilité : la capacité à accepter le changement en termes d’objectifs, passe de tous les sprints pour une équipe agile à tous les PI pour un train SAFe.

Certains cadres d’agilité à grande échelle, tels que LeSS (https://less.works/), ne prévoient pas cette timebox plus étendue et n’offrent pas de mécanisme permettant aux équipes de s’aligner sur une stratégie à long terme. (Cela ne signifie pas pour autant que LeSS l’interdit explicitement)

Si des dépendances existent entre les équipes, celles-ci doivent être résolues en début de chaque sprint. Si un développement implique plusieurs équipes sur plusieurs sprints et est livré par incréments, nous nous réengageons à chaque sprint à continuer.

SAFe impose d’aller plus loin en se contraignant à s’engager pour le PI et à limiter le temps de réalisation au PI. Est-ce que SAFe est réellement plus contraignant ? Oui, mais SAFe s’appuie sur le lean, “stop starting, start finishing”. Si on veut commencer quelque chose, on doit être capable de le finir, sinon cela ne sera que du gaspillage, certains auront travaillé pour rien et l’efficacité de l’organisation ne sera alors pas optimale. Le principe du PI et la limite d’une fonctionnalité à un PI visent à nous aider dans ce principe, SAFe agit donc bien en tant que cadre de travail lean-agile.

Le PI Planning a pour but de définir des objectifs de PI sur lesquels toutes les équipes s’accordent pour être alignées, et pour cela peuvent définir un plan, et non l’inverse. Le plan n’est pas parfait au démarrage, il va changer, s’adapter au cours du PI pour permettre la réalisation des objectifs à la maille du PI pour l’ensemble du train. SAFe est donc plus contraignant pour éviter le gaspillage.

Je tiens à préciser que je ne préfère pas LeSS à SAFe ou inversement, mon but est plutôt d’expliquer certains choix des cadres de travail et de leurs différences, qui s’appliqueront mieux à une organisation qu’à une autre en fonction des problématiques rencontrées, mais les deux en l’occurrence donnent un cadre agile, qui s’appliquent plus ou moins bien selon le contexte. Je pense que lorsque l’on parle de la rigidité de SAFe, on fait référence une fois de plus à l’implémentation qui en est faite, et je suis d’accord, celle-ci peut être ou non agile.

Un autre point de vue concerne la structure de SAFe. Cependant, ce framework ne joue pas le jeu de définir la hiérarchie de l’entreprise, il définit clairement des rôles avec des responsabilités et c’est à vous (nous en tant que SPC…) de les assumer. Si votre entreprise souhaite aligner les rôles de SAFe avec vos différents types de carrières, en incluant une hiérarchie… ce n’est pas SAFe qui apporte cette nouvelle probable rigidité…

Agile ou pas Agile ?

Je suis d’avis que si votre organisation ne parvient pas à être Agile avec SAFe, le problème ne réside pas nécessairement dans le cadre lui-même. L’enjeu majeur se situe plutôt dans la façon dont SAFe ou tout autre framework est mis en œuvre. Cette mise en œuvre peut être basée sur des décisions prises dans un contexte spécifique pour résoudre des problèmes immédiats, mais ces décisions peuvent avoir des conséquences à long terme.

La transformation Agile est un parcours complexe et prolongé qui nécessite que les membres de l’organisation s’approprient les méthodes de travail tout en respectant les principes fondamentaux. Tout au long de ce parcours, divers obstacles peuvent entraver la progression, voire provoquer des reculs. Cependant, le véritable risque ne réside pas dans le choix de l’outil — que ce soit SAFe, LeSS ou le prochain cadre en vogue — mais plutôt dans son appropriation correcte. L’adoption des principes et des valeurs est cruciale pour maintenir l’agilité tout au long de ce cheminement.