Blog

L’état des lieux de la mise en œuvre de SAFe® en France

Le déploiement du cadre SAFe Agile s’est accéléré en France ces dernières années. Grâce à des échanges entre praticiens du framework, il est possible de se faire une idée assez précise de l’étendue ainsi que des caractéristiques de ce déploiement dans l’Hexagone.  Je me propose de faire ici une synthèse de mes observations et conclusions.

 

SAFe® prend de l’ampleur

En 2013-2014, période à laquelle j’ai commencé à m’intéresser à ce cadre, il n’y avait que quelques sociétés qui utilisaient SAFe® en France. J’en dénombre désormais  plus de 50 et j’en découvre tous les mois de nouvelles qui se lancent. La vitesse d’adoption de SAFe® en France est ainsi un phénomène notable.

Autre élément significatif, l’ampleur du sujet au sein de certaines entreprises : sept sociétés ont plus de six trains « embarquant » des ressources en France. Sachant qu’un train comprend huit équipes en moyenne, on peut mesurer l’importance de la mise en œuvre de SAFe® pour ces sociétés.

On peut aussi remarquer la dimension géographique. Seuls 18% des trains sont monosites. Les 4/5e des trains sont en effet répartis sur plusieurs localisations, que ce soit en France ou à l’étranger. Dans le deuxième cas, il est principalement question de l’Inde, des Etats-Unis, de l’Allemagne, la Chine ou la Roumanie. On observe ainsi que SAFe® devient un rouage d’une grande chaîne de valeur de fabrication du logiciel qui va au-delà des limites des régions et des pays.

 

Les rôles et les cérémonies, points forts du déploiement

Aspect notable et positif de la mise en place de SAFe® en France, les rôles du framework sont généralement bien respectés. C’est en particulier le cas du RTE (ReleaseTrain Engineer) qui joue le rôle phare d’animateur du processus et que l’on trouve mis en œuvre sur tous les trains. Il  est devenu emblématique de SAFe®.

Les cérémonies sont elles aussi généralement bien déployées, notamment l’événement de planification collective que l’on appelle PI Planning. La durée de 2 jours préconisée par la méthode est respectée sur 75% des trains. Dans 22% des cas, c’est une autre durée qui est choisie, mais seulement 3% des trains ne font pas de PI Planning.

Quant à la cérémonie Inspect & Adapt, dédiée à l’amélioration, elle est elle aussi plébiscitée. On la trouve en effet sur 90% des trains.

Le Scrum de Scrums (qui permet la coordination entre RTE et Scrum Masters) et le PO Sync (c’est-à-dire la synchronisation entre Product Managers et Product Owners) sont mis en œuvre sur 67% des trains. SAFe® propose si nécessaire de fusionner les deux cérémonies en une seule appelée ART Sync mais seuls 17% des trains le font.

 

Pas assez d’innovation et trop plein de features

Du côté des points à travailler, on note que la System Demo, cérémonie essentielle qui permet aux équipes et à l’ensemble des parties prenantes de mesurer les progrès réalisés à chaque fin d’itération, n’est réalisée que par 58% des trains. 23% des trains ne réalisent en effet la System Demo qu’en fin de Program Increment (ou PI, ensemble d’itérations visant à délivrer un incrément de valeur). Et 19% ne la font pas. C’est un fait regrettable car se priver de la System Demo, c’est retirer un élément majeur de l’approche incrémentale de SAFe®.

La mise en œuvre des pratiques peut aussi s’avérer très variable. Autant les PI objectives sont plébiscités (ils sont en effet utilisés sur 83% des trains), autant la priorisation par la valeur au moyen du WSJF (Weighted Shortest Job First) paraît difficile à mettre en œuvre malgré son intérêt.  Elle n’est ainsi utilisée que par 40% des trains.

Autre fait notable, innover dans le sprint « Innovation and Planning » n’est pas offert à la majorité des équipes. Seuls 37% des trains innovent pendant l’itération IP, la majorité des trains cherchant plutôt à combler des retards pendant cette période. Le risque induit est l’essoufflement des équipes. Bien sûr, la vocation première est de délivrer de la valeur pour les Métiers. Mais SAFe® est un dispositif cadencé : s’il n’est pas accordé un temps pour que les équipes se consacrent à autre chose (comme par exemple proposer des innovations fonctionnelles ou techniques, se former, réduire la dette technique, s’industrialiser ou encore participer à des hackathons), elles peuvent progressivement s’épuiser. Ce point est sans doute trop négligé en France car culturellement encore nouveau.

Concernant les features, seuls 14% des trains embarquent moins de 11 éléments à travailler dans un PI Planning. C’est certainement le plus gros écart au référentiel, qui prône de se limiter aux 10 premiers features du backlog. Cela peut traduire un niveau de détail trop grand, rapprochant le feature d’une user story, ce qui amène le risque, en détaillant ainsi trop la solution, de brider la capacité de proposition des équipes.

 

Au fil des années, les écarts avec le cadre diminuent

On remarque que sur le temps, la mise en œuvre de trains plus petits est favorisée. Les gros trains de plus de 125 personnes deviennent ainsi plus rares. Ce découpage en trains plus faciles à gérer, qui peut être le résultat d’ateliers dits « Value Stream Workshops », fait assez souvent apparaître ce que l’on appelle des Large Solutions (des solutions plus grandes et complexes).

On note aussi que les durées des itérations et des Program Increments se calent de plus en plus sur le standard (respectivement 2 et 10 semaines), ce qui est une évolution positive.  En règle générale, on constate que le cadre tend aussi à être plus respecté que par le passé.

 

Le respect du modèle, une nécessité plus qu’un choix

Ce respect du cadre pourrait surprendre car, alors que l’agilité prônerait plutôt l’adaptation des processus, on remarque un besoin d’alignement sur un standard. Lors de la collecte des données, on se rend bien sûr compte que certains éléments du cadre ne sont pas toujours respectés, mais le plus souvent, cette personnalisation n’est pas le fruit d’une démarche volontaire.

C’est en fait bien plus fréquemment le résultat d’une difficulté de mise en œuvre de certains éléments, comme par exemple tenir des sprints de 2 semaines, appliquer le WSJF ou innover lors de l’itération IP.  J’en déduis que la volonté d’adapter le modèle est en réalité assez faible. L’adaptation est plus subie que souhaitée. Il y a cependant aussi une véritable volonté de respecter le modèle qui correspond probablement à une nécessité : il est en effet de plus en plus essentiel de travailler avec des partenaires ou des fournisseurs. Et c’est donc  une logique pragmatique qui s’impose : plus le langage et les modèles sont proches, plus cette coopération est possible.

 

SAFe® est présent sur tous les terrains

SAFe® est utilisé dans des secteurs d’activité très différents : principalement dans la banque, dans l’aéronautique, dans le secteur énergétique, mais aussi dans l’administration, la téléphonie ou dans l’automobile.

On utilise essentiellement SAFe® pour développer de l’informatique de gestion, mais aussi du logiciel dans des mondes industriels, parfois en embarquant des problématiques de conception et de production de matériel.

De nombreuses technologies peuvent se trouver intégrées dans des trains SAFe®. On retrouve prioritairement Java (présent dans 63% des trains), mais aussi AngularJS (39%), C++ (11%), Hadoop (11%) ou des progiciels, tels que par exemple les solutions de PLM (Product Lifecycle Management, littéralement « gestion du cycle de vie des produits »).

Sans dévoiler les sujets sur lesquels on retrouve SAFe®, je peux cependant dire que, sans qu’ils le sachent, bien des français sont des utilisateurs d’outils de traitement informatiques réalisés avec SAFe®.

Fait nouveau et récent, SAFe® intéresse aussi des PME (petites et moyennes entreprises de moins de 250 salariés). J’en ai ainsi identifié deux qui se sont lancées dans l’utilisation de SAFe®.

 

La question de la langue, un obstacle pas infranchissable

Il est courant d’entendre que la France est rétive au changement et il est donc intéressant de comparer l’adoption de SAFe® en France à celle des autres pays. Est-il possible que des phénomènes franco-français jouent un rôle dans ce contexte ?

Il est certain que le fait que le cadre soit en anglais a limité dans un premier temps son adoption en France. Ce frein est cependant en train de perdre en puissance grâce à des formations SAFe® délivrées en français, une francisation du glossaire et plus de souplesse dans la gestion du site web de Scaled Agile Inc. (avec la possibilité de copier-coller le contenu vers un outil de traduction). Il faut aussi noter le rôle positif des échanges accrus entre les utilisateurs francophones.

En conclusion, il me semble que la diffusion du cadre dans l’Hexagone est maintenant très rapide et se rapproche de ce qui s’est passé aux Etats-Unis ou en Europe du Nord. J’observe par ailleurs un déploiement aussi très actif dans les pays hispanophones. La France semble donc se mettre à la page de la mise en œuvre de SAFe® au niveau international.

 

A propos de l’auteur: Michel Levaslot

Michel Levaslot est adjoint de direction dans une DSI du secteur public. Il est en charge du développement des métiers et des compétences. Il mène avec ses équipesdes actions de transformation relatives aux ressources humaines, aux méthodes et aux outils de sa direction, principalement à travers la mise en œuvre de SAFe® depuis 2015. Il est aussi le créateur du club SAFe® francophone qui réunit une quarantaine de sociétés françaises, suisses et québécoises autour de retours d’expériences réguliers.

 


Si vous voulez en savoir plus sur les formations SAFe®, contactez:

Florence Colonne
Global Business Development Manager


|I: www.gladwellacademy.com
|T: +33(0)173053944
|E: florence.colonne@gladwellacademy.com

Nous utilisons des cookies pour vous offrir la meilleure expérience en ligne. En acceptant, vous acceptez l'utilisation de cookies conformément à notre politique de confidentialité des cookies.

Privacy Settings saved!
Paramètres de confidentialité

Lorsque vous visitez un site Web, il peut stocker ou récupérer des informations sur votre navigateur, principalement sous la forme de cookies. Contrôlez vos services de cookies personnels ici.

Veuillez noter que les cookies essentiels sont indispensables au fonctionnement du site, et qu’ils ne peuvent pas être désactivés.

Pour utiliser ce site Web, nous utilisons les cookies suivant qui sont techniquement nécessaires
  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

Nous utilisons WooCommerce comme un système d’achat. Pour le panier et le traitement de commande 2 cookies sont stockés. Ces cookies sont strictement nécessaires et ne peuvent pas être désactivée.
  • woocommerce_cart_hash
  • woocommerce_items_in_cart

Refuser tous les services
Accepter tous les services