Fondamentaux de SAFe : De l’agilité d’équipe à l’agilité d’échelle

Depuis son apparition en 2011, SAFe ne cesse de s’améliorer et de proposer des solutions d’organisation Agile à l’échelle. En mars 2023, nous avons vu apparaître la version 6.0 du framework. Durant ces dix dernières années, il est devenu la référence en termes d’organisation agile avec un retour d’expérience confirmant une augmentation de productivité de 20 à 50% pour les entreprises qui l’adopte et un time-to-market réduit de 30 à 75%.

Après une dizaine d’années d’activité dans le conseil en organisation et en stratégie agile, Mohamed, coach agile et SAFe Practice Consultant, présente le framework SAFe et son application en entreprise.
Dans cet article, il revient sur les notions de base du framework et ces conditions de mise en place pour pratiquer une agilité d’échelle.

Zoom sur le Framework SAFe

SAFe est une abréviation des termes anglais « Scaled Agile Framework ». On peut littéralement le traduire par « cadre de travail agile à grande échelle ».

Et si on essayait de décortiquer ces termes ?

• Commençons par le terme « framework » ou cadre de travail.

Par abus de langage, SAFe est parfois décrit comme une méthodologie, la méthode SAFe ou la méthodologie SAFe. En réalité le terme méthodologie et le terme « framework » sont assez différents. Une méthodologie est par définition une façon systématique de résoudre un problème. Elle décrit le processus qu’on doit suivre pour le résoudre. Or un framework est une approche structurée de résolution de problème. En d’autres termes, c’est un cadre dans lequel on pourrait mettre en place des méthodes de résolution et les faire évoluer.
Dans notre contexte, SAFe est défini comme un ensemble de valeurs et de pratiques inspirées du Lean et du manifeste Agile permettant aux organisations de développer leurs propres méthodologies de travail.

• Le deuxième terme de l’acronyme SAFe est « Agile ».

Le framework est conçu pour répondre principalement au besoin des organisations qui souhaitent évoluer vers des structures souples et réactives leur permettant de s’adapter aux besoins de leurs clients. SAFe est le modèle d’organisation qui pourrait remplacer ou compléter les structures organisationnelles du siècle dernier. Celles-ci sont davantage caractérisées par l’aspect compartimental de répartition des compétences.
À l’encontre de ces modèles, SAFe assure des flux de valeurs continus aux clients et ajustés à l’évolution rapide des marchés, accentuée par l’air du digital.

• Le troisième terme est « Scaled » ou à l’échelle.

Cette indication sur la taille des organisations auxquelles ce framework est destiné est si importante qu’elle est intentionnellement mentionnée dans l’acronyme. SAFe est adapté à des organisations allant de plus d’une centaine à plusieurs milliers de personnes.
Pour bénéficier de la capacité de SAFe à assurer l’agilité business, les petites structures auront plus d’intérêt à adopter un autre framework agile mieux adapté à leurs besoins, tel que Scrum, Kanban, Nexus…

Agilité d’équipe avec le framework SCRUM

Comme décrit précédemment, SAFe est un cadre de travail qui permet à une entreprise d’être agile dans sa façon de répondre aux besoins de ses clients. Mais avant d’envisager une agilité d’entreprise, il s’agit d’avoir une agilité au niveau de l’élément de base d’une organisation, c’est-à-dire l’équipe. Autrement dit, pour pouvoir mettre en place SAFe au sein d’une organisation, il faut d’abord construire des équipes agiles.

Pour ce faire, il est préconisé de s’appuyer principalement sur deux frameworks complémentaires en agilité d’équipe. Scrum en général ou Kanban pour certaines équipes dont l’activité est spécifique.

Les rôles de SCRUM

Scrum est un cadre de travail agile pour une équipe d’une dizaine de personnes.
Il s’appuie sur trois rôles répartis au sein de l’équipe :

• Le premier rôle est celui de la Dev Team.
  Il s’agit des membres de l’équipe qui participent à toutes les activités nécessaires à la création, la maintenance et la livraison d’un produit. La Dev Team est une équipe pluridisciplinaire. On peut y trouver des profils différents comme des développeurs, des testeurs, des DevOps…
• Le deuxième rôle est celui de Product Owner (PO).
  Il a la responsabilité de connecter l’équipe avec le client en collectant leurs retours et en prenant en compte leurs remarques. Mais aussi de contribuer à la vision du produit à travers la création et la priorisation des éléments du backlog de l’équipe. Et enfin de supporter l’équipe dans la construction du produit.
• Le troisième et le dernier rôle est celui de Scrum Master.
  C’est un rôle de leader au service de l’équipe. Il a pour objectif d’aider l’équipe à être la plus efficiente possible. Et il a comme mission de faciliter les cérémonies d’équipe, de coacher l’équipe dans la mise en place des indicateurs permettant la transparence et d’animer les ateliers en assurant l’amélioration des processus.

Agilité d’échelle avec Safe Agile Release Train

L’ART ou l’Agile Release Train est une équipe composée de plusieurs équipes agiles qui ont une mission commune. Ce train peut contenir de 50 à 125 membres. Ces derniers travaillent ensemble, au sein de leurs équipes agiles respectives, pour planifier, développer et déployer des solutions. Ils assurent ainsi la livraison de valeur au client à travers la chaîne de valeur desservie par l’ART.

Dans quels cas est-ce pertinent de mettre en place un ART ?
Quand la ou les solutions à concevoir nécessitent la mobilisation de plusieurs équipes sur une durée assez longue de l’ordre de quelques années. Il y a alors un besoin de synchroniser les travaux de ces équipes sous une organisation agile plus grande, l’ART.

Les rôles de l’Agile Release Train

À l’image d’une équipe agile, plusieurs rôles se retrouvent au sein d’un ART :

• Le noyau de l’ART est principalement constitué par les différentes équipes agiles. Ces équipes doivent notamment être organisées en équipe Scrum, ou parfois en Kanban. Idéalement, ces équipes, appelées features team, sont capables de transformer un item du backlog du train, une feature, en un incrément potentiellement livrable dans une durée de temps ne dépassant pas un PI (Planning Interval). Si une organisation en feature team est impossible, les équipes doivent être les plus indépendantes possibles de manière à être en capacité de travailler sur une feature avec le maximum d’autonomie.
• Le deuxième rôle qui apparaît dans un ART est le rôle de Product Manager. Un Product Manager (PM) est pour un ART, ce qu’est un PO pour une équipe Scrum. Le PM est responsable du backlog de l’ART : De la création de ses items, de leurs priorisations et de leurs acceptations. Il a pour mission de concevoir la vision des solutions sur lesquelles travaillent le train en concordance avec les retours et les besoins des clients. Il doit avoir une excellente analyse du marché. Et il supporte les équipes de l’ART dans la livraison de la valeur. Dans certains ART, on pourrait trouver plusieurs PM qui travaillent ensemble pour assurer le product management.
• Le troisième rôle est celui du Release Train Engineer, connu sous l’acronyme RTE. Il est pour un ART, ce qu’est le Scrum Master pour une équipe agile. Il a comme mission d’optimiser le flux de valeur livré par l’ART en assurant l’animation des évènements, la facilitation des ateliers d’amélioration continue, la mise en place des KPI mesurant les performances de l’ART, le coaching des équipes et le support à l’exécution des plans.
• Le quatrième et dernier rôle est celui de système architecte de l’ART. Il a pour mission de mettre en place la vision technique de l’ART. Cette vision doit être inspirée de la vision technique de l’entreprise. Il garantit la cohérence technique des travaux des équipes de l’ART et les supporte dans leurs défis techniques. Il contribue avec le PM et le RTE à la conduite de l’ART.

Les événements de l’Agile Release Train

À l’image d’une équipe agile élémentaire, l’ART a ses propres événements. Ils reprennent les mêmes activités des cérémonies Scrum mais avec une mise à l’échelle :

• Le premier terme à connaître est le PI, Planning Interval. Il est le conteneur de tous les autres évènements. Il est pour un ART ce qu’est l’itération ou le sprint pour une équipe Scrum. Il dure cinq itérations, et chaque itération dure deux semaines. Certaines entreprises pratiquent des PI de 6 itérations pour coller aux trimestres budgétaires de l’entreprise. Le PI est le pendule de l’ART.
• À l’image de l’itération en Scrum, le PI commence par une activité de planification qui est le PI planning (PIP). Il s’agit d’une grande réunion de planification où les équipes de l’ART planifient leurs activités et leurs livrables pour le PI à venir. S’ensuit une présentation de la vision du top management pour le PI, qui va ensuite être travaillée par les équipes pour donner un plan d’exécution. Ce plan prend en considération les capacités des équipes et les dépendances potentielles. À la fin de cette réunion qui dure deux jours et où tous les membres de l’ART sont conviés, un vote de confiance est organisé pour évaluer la confiance des équipes dans le plan qu’ils ont élaboré.
• Durant les cinq itérations les Product Owners, les Scrum Masters, le System Architect, les Product Managers et le Release Train Engineer suivent l’exécution du plan et l’ajustent en fonction des imprévus et des risques qui pourraient émerger. Cette inspection et ce suivi se font à travers les activités de synchronisation de l’ART qui sont principalement la synchronisation inter PO et la synchronisation entre les Scrum Masters.
• À chaque fin de PI, une démonstration de la solution ou des solutions sur lesquelles travaillent les équipes est faite. Durant cette réunion, les Business Owners inspectent les livrables et attribuent la valeur commerciale aux objectifs définis par les équipes lors du PIP. C’est le moment aussi d’écouter les retours des clients ou de leurs représentants pour ajuster la vision pour la suite. D’autres démos sont aussi organisées à la fin de chaque itération. Elles permettent de s’assurer de la bonne intégration et recenser en permanence les remarques des clients ou de leurs représentants.
• Après la system demo, le RTE de l’ART organise une rétrospective dédiée à l’amélioration du fonctionnement de l’ART. L’objectif est d’assurer l’amélioration continue et d’optimiser le flux de valeur livré aux clients. Ces deux dernières activités, la system demo et la rétrospective, sont planifiées dans l’itération I&A, Inspect & Adapt, qui est la dernière itération du PI.

Une mise en place complexe

Comme nous avons pu le constater ensemble, SAFe réorganise l’entreprise en se basant sur les principes Agile et Lean de base. Certes ces principes sont simples et ludiques, mais leur mise en place dans une organisation complexe est un challenge difficile. Il demande une maîtrise du framework d’une part, et des processus de transformations agiles d’autre part. C’est pour cela que le framework a prévu une formation certifiante pour chacun des rôles de SAFe.