Créé en 2011, Scaled Agile Framework est maintenant la référence du marché pour les entreprises qui souhaitent étendre les principes agiles au-delà de quelques équipes. Son site internet qui met librement à disposition un contenu riche et bien agencé, permet d’expliquer en partie son ascension fulgurante.
Cette vitrine est ainsi particulièrement séduisante pour les entreprises qui ne savent pas forcément par où commencer leur transformation agile, et recherchent un cadre de transformation claire et structuré. Les nombreuses certifications proposées par SAFe apportent aussi de la crédibilité au modèle proposé, en plus d’être extrêmement rémunératrices pour les créateurs de SAFe.
Au-delà de toute critique du business model, intéressons-nous au bien-fondé du modèle SAFe lui-même.
Nous aborderons dans la suite de l’article les principaux défauts qui peuvent rendre SAFe inefficace voir contre-productif sur le terrain :
- Des trains créés à profusion
- L’absence de directives sur le management
- Une organisation trop virtuelle
- Une surcouche de complexité
1/ « Des Agile Release Trains, comme s’il en pleuvait »
Après les nombreuses phases de formation et de certification, la première véritable étape d’implémentation de SAFe est l’identification des chaînes de valeurs. SAFe recommande de partir du besoin métier, pour identifier les équipes IT qui y contribuent et ensuite les coordonner via un train. De ce postulat plutôt sain, nous constatons assez souvent un biais important lors de l’implémentation de ces recommandations.
SAFe demande par exemple de ne regrouper au sein d’un train que les équipes qui doivent se coordonner entre elles. Mais on constate souvent que les entreprises, après avoir analysé leurs chaînes de valeur, regroupent l’ensemble des équipes d’un périmètre au sein de trains et non pas juste les équipes qui en ont besoin, afin de ne pas laisser d’équipes « seules ».
On voit alors apparaitre deux effets pervers :
- des équipes participent à des trains alors qu’elles n’ont rien à y partager, ou n’ont pas de véritable dépendance avec les autres équipes
- des trains sont implémentés pour uniquement 2 ou 3 équipes, sans véritable besoins de coordination
Un point parfois négligé par les équipes de transformation est qu’un PI Planning qui regroupe plusieurs dizaines de personnes pendant 2 jours coûte plusieurs dizaines de milliers d’euros, sans compter les frais de logistique et les coûts cachés de préparation et de coordination. Il est ainsi primordial de n’implémenter des mécanismes de synchronisation lourds comme le train SAFe que lorsque les équipes en ont besoin, et si ce besoin est durable dans le temps.
Un train SAFe devrait ainsi être une exception permettant de gérer des problématiques de coordination et non pas la norme par défaut de déploiement de l’agilité de toutes les équipes.
2/« Des équipes auto gérées, mais avec des chefs, mais on ne sait pas trop qui »
Comme beaucoup de frameworks d’agilité à l’échelle, la question du management n’est pas directement abordée par SAFe.
Qui est le responsable hiérarchique des membres des équipes ? Le RTE ? un responsable d’équipe ? Le tech lead ? le product owner ? une autre personne ?
Aucune réponse n’est apportée. Concrètement, cela signifie qu’une entreprise qui choisit SAFe va déployer toute une structure pour coordonner ses équipes, prioriser ses activités, mais à aucun moment elle ne va remettre en question les lignes hiérarchiques historiques, et donc les centres de décision de son organisation.
Quelle est la portée d’un PI planning si au moindre coup de vent, le manager d’une équipe peut modifier à sa guise les priorités en mettant la pression à ses subordonnées ?
Bien que ces comportements ne soient ni d’agiles et ni alignés avec le leadership mis en avant par SAFe, ils sont encore souvent une réalité chez de nombreuses entreprises.
En ne redéfinissant pas le rôle du chef, SAFe laisse la porte ouverte à tous les ingérences possible du responsable hiérarchique au sein de l’équipe. Bien sûr, il n’y a pas de solution générique applicable partout, mais ne pas donner de pistes de réponses sur cette question entraîne de nombreuses difficultés sur le terrain.
3/ « Une structure virtuelle sur une organisation bien réelle »
Dans la continuité du point précédent, SAFe n’encourage pas l’entreprise à revoir son organisation lors de son passage à l’agilité à l’échelle. Après l’identification des chaînes de valeur, SAFe pourrait suggérer de refondre l’organisation le long de ces chaînes de valeur, d’aligner les équipes IT avec les enjeux métiers. D’autant plus que SAFe est bien conscient de ce problème d’alignement et des difficultés qu’il peut entraîner :
Mais l’approche proposée est au contraire de lancer rapidement un premier train puis de construire une organisation virtuelle constituée de trains et de portefeuilles au-dessus des équipes et départements existants. Ce choix qui peut sembler pragmatique à court terme, entraîne de nombreuses difficultés pour les entreprises sur le long terme :
- L’alignement : comment concilier les priorités et les objectifs de la hiérarchie avec les priorités et les objectifs de l’organisation virtuelle décidés lors des PI Planning ?
- Le financement : SAFe recommande de financer des initiatives et des trains, qui sont des structures virtuelles et n’existent souvent pas en tant que telles dans les référentiels de l’organisation. Comment allouer un budget à une initiative ? À une équipe virtuelle ? Qui en est le responsable ? Comment suivre sa consommation ? Comment concrètement passer dans un mode de gestion capacitaire ?
- Gestion du support/run : SAFe explique que chaque équipe doit être en charge de son propre support, mais cette vision n’est pas possible dans 100 % des cas (exemple : combien de personnes faut-il au minimum pour faire du support 24 h/24 7j/7 ? réponse : 5, soit la quasi-totalité d’une équipe Agile). En proposant un modèle qui intègre mal les activités de support, SAFe met de côté entre 10 et 40 % des équipes et coûts d’une DSI, et ne pousse pas à leur rationalisation.
- Les composants transverses : par définition, un composant transverse est un élément mutualisé qui sert de nombreux métiers et donc de nombreuses chaînes de valeurs différentes. Quel PI planning s’occupe de prioriser ses activités ? comment gère-t-on les priorités concurrentes ? Uniquement avec une Solution Train ?
4/ « SAFe ou la surcouche de complexité »
L’un des principes structurants de l’agilité est la simplicité : « la simplicité c’est-à-dire l’art de minimiser la quantité de travail inutile est essentielle » d’après le manifeste agile. SAFe, en proposant une méthodologie très détaillée et structurée perd parfois de vue ce principe de base. Ou plutôt en construisant une méthodologie applicable partout, propose en fait un framework qui ne convient réellement à personne sans de nombreuses adaptations.
À l’image des vêtements “prêt-à-porter”, SAFe met à disposition sur étagère un certain nombre de règles, de pratiques et processus qui permettent à une entreprise de structurer ses activités. Mais ces pratiques ne sont pas toujours celles qui conviennent le mieux à l’entreprise ni celles qui lui permettent de se transformer pour vraiment gagner en efficacité.
Il est ainsi essentiel de prendre du recul sur ces recommandations et demander conseil à des consultants ou coachs expérimentés (et non uniquement certifiés !) pour adapter ces pratiques au contexte de l’entreprise.
Même si dans notre vie de tous les jours, porter des vêtements sur mesure n’est pas forcément nécessaire, dans le monde concurrentiel des entreprises, un modèle opérationnel adapté est un levier indispensable pour rendre l’entreprise efficace.
Conclusion
De même que pour l’ensemble des autres méthodologies Agiles, SAFe ne reste qu’une boîte à outils au service des enjeux de l’entreprise.
La richesse et la taille de cette boîte à outils ne doivent en aucun cas se substituer au regard critique de l’équipe de transformation. D’autres modèles existent, copier un concept « parce que c’est dans SAFe » ne peut être un argument recevable dans une transformation, où l’objectif n’est pas de « faire du SAFe », mais définir et mettre en place le modèle opérationnel qui apporte le plus de valeur à l’entreprise.