Le Scaled Agile Framework® (SAFe®) est un ensemble de dispositifs organisationnels et de workflow pour mettre en œuvre de pratiques agiles à l’échelle de l’entreprise. Il présente un ensemble de pratiques concernant les rôles et les responsabilités, la façon de planifier et de gérer le travail et les valeurs à véhiculer.
SAFe définit le cadre pour l’alignement, la collaboration et le delivery entre un grand nombre d’équipes agiles. Il s’articule autour de trois principaux blocs de connaissances : le développement logiciel agile, le développement de produits lean et la pensée systémique.
À mesure que les entreprises grandissent, SAFe apporte une approche structurée pour le scaling agile. Quatre configurations sont proposées en fonction du niveau de scale souhaité : Essential SAFe, Large Solution SAFe, Portfolio SAFe et Full SAFe.
Dean Leffingwell et Drew Jemilo ont lancé SAFe en 2011 pour aider les organisations à concevoir de meilleurs systèmes et logiciels qui répondent mieux aux besoins changeants des clients. À cette époque, les équipes utilisaient des processus de gestion de projet classiques pour livrer des logiciels. Mais à mesure que la nécessité de répondre rapidement aux conditions évolutives du marché augmentait, de nouvelles méthodologies ont émergé pour aider les entreprises à améliorer la livraison de solutions dans leurs entreprises : SAFe a vu le jour. Aujourd’hui, SAFe est l’une des méthodologies agile à l’échelle les plus utilisées, et la communauté mondiale de praticiens de SAFe continue de le faire évoluer.
Les principes et les valeurs fondamentaux
Valeurs fondamentales
Les valeurs fondamentales de SAFe décrivent la culture que le leadership doit favoriser pour réussir la mise en œuvre de la méthodologie.
Alignement
L’une des exigences de SAFe est la mise en place des cadences de planification et de réflexion à tous les niveaux de l’organisation. Une fois en place, tous les collaborateurs ont une idée claire sur l’état actuel de l’entreprise, les objectifs et le rôle de chacun pour atteindre ces objectifs. En synchronisant régulièrement les personnes et les activités, tous les niveaux du portefeuille restent alignés. Les informations circulent à la fois vers le haut et vers le bas en temps opportun, contrairement aux structures traditionnelles top down.
Qualité intégrée
Dans le cadre de la démarche SAFe, l’agilité ne doit jamais se faire au détriment de la qualité. SAFe exige des équipes à tous les niveaux qu’elles définissent ce que « done» signifie pour chaque tâche ou projet et qu’elles intègrent des pratiques de développement de qualité dans chaque contrat de travail. Selon SAFe, il existe cinq dimensions clés de la qualité intégrée : le flux, la qualité de l’architecture et de la conception, la qualité du code, la qualité du système et la qualité des livraisons.
Transparence
SAFe encourage la mise en place d’un climat de confiance et de transparence, notamment en planifiant le travail en petits lots afin que les problèmes puissent être identifiés plus tôt, offrant une visibilité en temps réel sur l’avancement de la backlog à tous les niveaux, ainsi que les rituels d’inspection et d’adaptation.
Exécution du programme
L’exécution du programme est au cœur de SAFe et soutient tous les autres aspects du framework. Les équipes et les programmes doivent pouvoir fournir régulièrement un service de qualité, des logiciels opérationnels et une valeur business.
Direction
SAFe requiert un comportement de leadership Lean/Agile, car seuls les leaders peuvent transformer le système et mettre en place l’environnement nécessaire pour inculquer toutes les valeurs fondamentales.
Principes SAFe
Les principes SAFe sont destinés à améliorer l’entreprise dans son ensemble en éclairant la prise de décision Lean/Agile au-delà des limites fonctionnelles et organisationnelles. Les principes visent à influencer non seulement les décisions des dirigeants et des responsables, mais aussi celles de tous les membres de l’organisation, et à les encourager à passer d’une pensée classique en waterfall à une pensée Lean/Agile, qui applique des pratiques telles que la gestion de portefeuilles Lean.
Principe n° 1 : Adopter une vision économique
D’après les théories sur le flux de développement produit tirées des best-sellers de Donald Reinertsen, chaque intervenant dans la chaîne de décision doit comprendre les implications économiques des retards pour obtenir le délai d’exécution le plus court possible. Il ne suffit pas toujours de livrer tôt et régulièrement. Selon SAFe, classer les tâches pour optimiser les bénéfices, comprendre les échanges économiques et travailler en respectant des budgets serrés sont autant de responsabilités qui doivent être communiquées à l’échelle de l’organisation. De nombreux concepts et outils sont tirés des théories de Donald Reinertsen sur le flux de développement produit.
Principe n° 2 : Appliquer une pensée systémique
SAFe encourage les personnes qui utilisent le framework à appliquer une pensée systémique sur trois axes clés : la solution elle-même, l’entreprise qui développe le système et les flux de valeur. Les solutions peuvent concerner des produits, des services ou des systèmes fournis au client, qu’ils soient internes ou externes à l’entreprise.
Les solutions d’envergure comportent de nombreux composants interconnectés. Les membres de l’équipe doivent avoir une vision d’ensemble pour savoir comment leur élément s’intègre dans la solution.
Les adeptes de SAFe doivent prendre en considération l’ensemble des acteurs de la chaine de réalisation de la solution, du système de management et des processus de réalisation. Ainsi, si une organisation cherche à optimiser les méthodes de travail, elle devra peut-être éliminer les silos, devenir transverse, et conclure de nouveaux accords de coopération avec les fournisseurs et les clients. Finalement, l’entreprise doit clairement expliquer comment la valeur passe du concept au financement dans les flux de valeur de développement de solutions. Les dirigeants et la direction doivent optimiser le flux de valeur au-delà des limites fonctionnelles et organisationnelles.
Principe n° 3 : Supposer la variabilité, conserver les options
Par défaut, la conception de systèmes et de logiciels est un exercice incertain. Ce principe répond à cette incertitude en introduisant le concept de « Set-Based Design » (design basé sur un ensemble), qui implique de garder plusieurs exigences et options de design pendant une période prolongée dans le cycle de développement. Le « Set-Based Design » s’appuie également sur des données empiriques afin de se focaliser sur la dernière option de design dans la suite du processus.
Le « Set-Based Design » aide à prendre des décisions éclairées en période d’incertitude en identifiant les options et les résultats escomptés, sur le même principe qu’un choix stratégique. Le concept visant à intégrer des « étapes importantes d’apprentissage » (qui font référence à la date limite pour prendre des décisions) joue un rôle clé dans le « Set-Based Design ». Plus les équipes apprennent au fil du temps, plus elles peuvent éliminer de choix. Plus elles éliminent de choix, plus il est facile d’identifier la meilleure voie à suivre et de produire le meilleur résultat possible pour les clients.
Principe n° 4 : Se développer de manière itérative à l’aide de cycles d’apprentissage rapides et intégrés
À l’instar du principe n° 3, ce principe aborde le risque et l’incertitude par le biais d’étapes importantes d’apprentissage. Il ne suffit pas que chaque composant du système soit fonctionnel, il faut tenir compte de l’ensemble du système pour évaluer la faisabilité des choix de design actuels. Les points d’intégration doivent être planifiés à intervalles réguliers, afin d’accélérer les cycles d’apprentissage. Ces points d’intégration constituent un parfait exemple du cycle PDCA (plan-do-check-adjust) de Walter A. Shewhart, un framework pour l’amélioration continue de la qualité et un mécanisme pour contrôler la variabilité du développement. Les travaux de Walter Shewart et ceux qu’il a inspirés se concentrent souvent sur SAFe.
Principe n° 5 : Baser les étapes importantes sur une évaluation objective des systèmes de travail
La démonstration d’un véritable système de travail constitue une meilleure base pour la prise de décision qu’un document d’exigences ou toute autre évaluation superficielle de la réussite. Inclure dès le départ les parties prenantes dans ces décisions de faisabilité permet de renforcer la confiance et encourage une pensée systémique.
Principe n° 6 : Visualiser et limiter le travail en cours (Work in Process, WIP), réduire la taille des lots et gérer la longueur des files d’attente
Limiter le travail en cours aide les parties prenantes à évaluer avec précision le déroulement des opérations.
Les trois éléments de ce principe représentent les principaux moyens d’optimiser le débit et d’accélérer la création de valeur ou, en d’autres termes, d’implémenter le « flux ». Comme le dit l’adage « Ne mettons pas la charrue avant les bœufs ».
En appliquant ce principe au développement logiciel, vous limitez le nombre de tâches se chevauchant, la complexité de chaque tâche et le volume total de travail à réaliser à un moment donné. La petite taille des lots permet de vérifier en permanence que le travail est sur la bonne voie. Et que la longueur des files d’attente est correctement gérée…
Ce principe vise à donner des conseils sur l’optimisation de ce processus en vue d’obtenir les meilleurs résultats.
Principe n° 7 : Appliquer la cadence, synchroniser avec la planification transverse
Les équipes Agile appliquent naturellement la cadence par le biais de sprints ou d’itérations. La création d’une cadence pour tous les sujets possibles réduit la complexité, répond à l’incertitude, développe la mémoire musculaire, renforce la qualité et incite à la collaboration. La synchronisation de ces cadences permet aux personnes et aux activités de fonctionner comme des rouages où les informations apprises éclairent les décisions et la planification incrémentielle.
Principe n° 8 : Susciter la motivation intrinsèque des travailleurs du savoir
Inspiré par le conseiller en gestion influent Peter Drucker et l’auteur Daniel Pink, ce principe est l’un de nos préférés ! Il permet de libérer le potentiel des équipes et aide la direction à adopter une approche de commandement et de contrôle pour coacher ses équipes et répondre à leurs besoins.
Principe n° 9 : Décentraliser la prise de décision
Réduire la longueur des files d’attente et adopter une approche économique en décentralisant la prise de décision confèrent aux équipes l’autonomie dont elles ont besoin pour accomplir leur travail. Les dirigeants doivent conserver leur pouvoir de décision pour les sujets stratégiques et permettre aux équipes d’opérer des choix éclairés sur tous les autres sujets.
Comment fonctionne SAFe ?
Les organisations prêtes à implémenter SAFe bénéficient généralement d’un parrainage au niveau de la direction, d’une forte volonté de changement et d’une base Scrum.
Scaled Agile, Inc. fournit une feuille de route pour implémenter SAFA, qui contient des étapes détaillées pour vous lancer et configurer l’organisation en vue de l’adoption générale dans tous les portefeuilles. Voici les 12 étapes de l’implémentation de SAFe :
- Atteindre le point de bascule
- Former des agents du changement Lean/Agile
- Former des directeurs, des responsables et des leaders
- Créer un centre d’excellence Lean/Agile
- Identifier des flux de valeur et des Agile Release Trains (ART)
- Élaborer le plan d’implémentation
- Préparer le lancement de l’ART
- Former les équipes et lancer l’ART
- Préparer le lancement de l’ART
- Lancer d’autres ART et flux de valeur
- Étendre au portefeuille
- Maintenir et améliorer
Comment SAFe se situe-t-il par rapport aux autres frameworks Agile à grande échelle ?
Bien que SAFe® soit largement adopté par les entreprises disposant de grandes équipes de développement, d’autres frameworks Agile à grande échelle ont gagné en popularité au fil du temps. Tous ces frameworks partagent cinq composants principaux : l’inspiration des 12 principes du manifeste Agile, la cadence, la synchronisation, Scrum et les pratiques de développement de qualité. Comprendre les origines des autres frameworks, les différences fondamentales et les conditions pour une application réussie permet aux organisations de sélectionner le framework qui répond le mieux à leurs besoins.
Vous souhaitez en savoir plus sur certains des principaux frameworks Agile à grande échelle ? Consultez la page de présentation Agile à grande échelle sur le coach Agile.
SAFe et Scrum@Scale
Dans Scrum@Scale (S@S), tout le monde fait partie d’une équipe Scrum interchangeable. En fonction de leurs objectifs, les réseaux d’équipes Scrum se rassemblent pour former un écosystème. L’objectif de S@S est de créer un réseau d’équipes Scrum grâce à une architecture « scale-free », ce qui signifie que les rôles et les événements Scrum de base sont mis à l’échelle de façon linéaire, sans introduire de nouvelle dynamique de processus. Par exemple, un Scrum de Scrums (SoS) peut ne pas être suffisant pour un produit très complexe comptant 25 équipes Scrum, donc un Scrum de Scrum de Scrums (SoSoS) avec un Scrum de Scrums Master (SoSM) peut être nécessaire.
Bien que S@S soit généralement moins normatif, il propose une question directrice afin d’aider les organisations à déterminer si elles sont prêtes à évoluer : si vous ajoutez d’autres personnes au système, les performances augmentent-elles de manière exponentielle ou la productivité en souffre-t-elle ?
Tout comme SAFe, S@S propose un contenu de référence en ligne, notamment un guide Scrum@Scale complet dont la popularité ne cesse de croître.
Le framework S@S est le plus approprié dans les cas suivants :
- La stack technique est orientée objet (c’est-à-dire que les user stories verticales peuvent être livrées en deux semaines).
- Les « feature teams » de l’organisation possèdent des compétences en forme de T, adoptent des valeurs axées sur le produit et gèrent un minimum de paperasse.
- Aucun outil Agile ou de gestion du cycle de vie Agile (ALM) n’est requis tant que les pratiques ne sont pas devenues une seconde nature.
- L’équipe de direction est prête à se familiariser avec Scrum et à lever les obstacles pour l’organisation.
SAFe et Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS) adopte une approche minimaliste des rôles, de la structure et des artefacts. Alors que SAFe propose quatre configurations pour satisfaire des équipes de plus en plus grandes et offrant des solutions de plus en plus complexes, LeSS en propose deux : LeSS pour deux à huit équipes et LeSS Huge pour plus de huit équipes. LeSS se distingue également par sa position selon laquelle les Product Owners devraient disposer d’un contrôle complet sur le contenu et d’une influence stratégique, alors que SAFe encourage une approche plus démocratique. Et si SAFe s’accompagne de nombreux facteurs qui influencent la stratégie, LeSS met l’accent sur une approche orientée client axée sur les clients payants.
À l’instar de S@S, LeSS évolue depuis les événements, les artefacts et les rôles Scrum. SAFe et LeSS mettent tous deux l’accent sur la pensée systémique, la pensée Lean et d’autres principes directeurs similaires. LeSS, en revanche, met fortement l’accent sur la réduction du gaspillage dans l’ensemble de l’organisation, avec pour objectif une amélioration continue.
Le framework LeSS est le plus approprié dans les cas suivants :
- Les équipes Scrum maîtrisent Scrum.
- La direction cherche à se restructurer et à expérimenter en permanence pour le bien commun.
- Un alignement sur la définition du produit existe.
- Un alignement sur la définition de l’état « Terminé » existe.
- Des coachs externes travaillent avec des groupes d’équipes, organisationnels et techniques.
- Des « feature teams » et des « component teams » possédant des compétences en T sont disponibles.
- L’organisation cherche à se débarrasser entièrement de la gestion de projets.
SAFe et DA
Contrairement aux autres frameworks décrits, Disciplined Agile (DA) est un kit d’outils qui permet aux organisations de décider de la méthode de travail la plus logique pour s’y adapter. Il propose une gouvernance Agile légère, qui s’appuie sur Scrum et Kanban, ainsi que des connaissances en matière de transformation dans des domaines, tels que les RH et les finances, la gouvernance, la méthodologie DevOps ou la gestion de portefeuilles. DA implique l’utilisation de différents niveaux d’évolutivité pour chaque projet et met l’accent sur la capacité de prise de décision pour aider à orienter la direction stratégique.
Le framework DA est le plus approprié dans les cas suivants :
- Les organisations veulent définir leurs propres parcours Agile à grande échelle.
- Les organisations souhaitent rester flexibles au sein de l’entreprise.
- Les organisations entendent préserver les choix de processus et/ou de framework.
SAFe et Spotify
Le « modèle » Spotify est un ensemble de pratiques autonome et axé sur les personnes qui peut être appliqué pour coordonner les équipes Agile. Il n’a jamais été conçu comme un modèle ou un framework, mais certaines entreprises l’ont adopté en tant que tel. Spotify met l’accent sur les équipes auto-organisées, transverses et colocalisées appelées « squads » (l’équivalent d’une équipe Scrum). En comparaison, SAFe n’a pas de disposition de ce type sur la colocation des équipes. Elle est encouragée pour la planification d’incrément de programme.
Les squads sont organisés en unités plus importantes appelées « tribus ». Les dépendances entre les squads sont peu nombreuses et sont traitées par le biais d’un Scrum de Scrums lorsqu’elles se produisent. Le partage des connaissances est possible grâce aux « chapitres » et aux « guildes », et des groupes informels sont organisés en fonction des compétences et des intérêts.
Par rapport à d’autres exemples, où des ressources en ligne, des cours de formation et des certifications sont disponibles, les ressources sur le modèle Spotify se limitent à un blog accessible au public et à d’autres éléments complémentaires développés par ses pionniers et ses fans. Le modèle est de plus en plus populaire, il est donc probable que nous en verrons d’autres à l’avenir.
Le modèle Spotify est le plus approprié dans les cas suivants :
- Application des idées dans votre propre contexte commercial.
- La culture organisationnelle est axée sur l’apprentissage, la tolérance aux erreurs et la prise de risques contrôlés.
- Les équipes et les produits sont « légèrement couplés, étroitement alignés » pour éviter tout conflit de dépendance.
SAFe 5.0
L’un des principes fondamentaux du framework SAFe est qu’il continue à évoluer en collaboration avec sa communauté d’experts dans le monde entier. Récemment, Scaled Agile, Inc. a lancé la version 5.0 de SAFe. Les principaux changements comprennent l’ajout d’un 10e principe, « Organiser autour de la valeur », et le remplacement de l’étape 12, « Maintenir et améliorer », par « Accélérer ». Mais les implications sont bien plus nombreuses.
Conclusion
Les frameworks comme SAFe et ceux qui ont été évoqués ci-dessus constituent une option viable pour aider les entreprises à se développer efficacement au sein de leur organisation et à atteindre leurs objectifs commerciaux. Mais les outils que vous choisissez pour vous aider à amplifier les pratiques existantes et à en tirer pleinement parti sont tout aussi importants. Nos équipes sont à votre disposition pour vous présenter la solution Jira Align d’Atlassian, une plateforme de planification Agile d’entreprise développée pour SAFe. Grâce à Jira Align, vous pouvez améliorer la visibilité, l’alignement stratégique et l’adaptabilité de l’entreprise afin d’accélérer votre transformation digitale.