Pourquoi SAFe divise autant ?

J'avais écrit un article autour de SAFe il y a un peu plus d’une d'année “6 mois de SAFe (c), ce que j’en retiens ?”. Et depuis j'ai pu contribuer à plusieurs implémentations chez divers clients en tant SPC (SAFe Program Consultant). J'ai eu beaucoup de discussions avec autant de "Coachs Agile" que de "clients". C'est intéressant de voir la différence d'avis entre différentes populations. Notamment le mélange de refus catégoriques et mépris de certaines personnes vis à vis du Framework d’une part, et un amour sans faille de l’autre. Je me pose toujours la question : Pourquoi SAFe divise autant ?

Il était une fois l'Agile

Pour revenir aux fondamentaux, l'Agile s'est essentiellement construit autour de la simplification, les livraisons incrémentales, l'auto-organisation des équipes et une attention particulière aux utilisateurs. C’était l'intention en tout cas des créateurs du manifeste Agile en 2001 (pour en savoir plus, la formation Découvrir les démarches agiles et la culture agile peut vous être utile).

Puis l'Agile à l'échelle

Au début l'agilité se limitait à une équipe multidisciplinaire d'une dizaine de personnes qui s'auto-organisent pour délivrer de la valeur de manière indépendante. Cela marche très bien dans certains contextes ... mais pas partout et pas avec le même niveau de succès. Ceci est dû à plusieurs limites, majoritairement dans les grandes entreprises, qui font qu’une approche centrée sur une équipe n'est pas suffisante. Ces contraintes sont essentiellement :

• L'application des principes Agile au développement de systèmes complexes nécessitant le travail de quelques dizaines voire une centaine de personnes.
• L'alignement des équipes sur la stratégie de l'entreprise et les objectifs business fixés.
• Le déploiement continu/fréquent de systèmes complexes et volumineux avec un même niveau de confiance dans la qualité produite.
• Un mode de financement, souvent par projets et axé sur la seule variable des coûts, qui n'est pas compatible avec un mode de fonctionnement Agile.

C'est là que nous avons observé la naissance de plusieurs "frameworks" qui tentent de trouver des réponses à ses limites. Aujourd'hui les “frameworks” les plus répandus étant Nexus, LeSS, Scrum@Scale, DAD et ... SAFe

Quel différenciateur de SAFe?

A la différence de tous les autres framework (ou démarches Agile), SAFe a fait le choix d'être prescriptif, détaillé et exhaustif. Ce qui change tout, vu qu’il nous fait passer d’un modèle d'entreprise apprenante à un modèle plutôt basé sur l'application du framework et de “déploiement”. Et c’est essentiellement ce qui divise les personnes.

Après tout, pourquoi pas ? Il y a des standards aujourd'hui qui émergent tant au niveau organisationnel que technique, et autant en faire profiter les entreprises pour donner un premier coup d'accélérateur (remise à niveau) qui sera suivi d'une "digestion" et compréhension des concepts les amenant à "un monde meilleur". Ça tombe bien, c'est ce que me demandent mes clients aujourd'hui. Plus le périmètre est large, plus nos clients nous demandent un modèle de base sur lequel construire leur organisation et se projeter vers le futur. Rien ne vous empêche d’ailleurs d’utiliser plusieurs approches et voir ce que chacune apporte à votre entreprise.

Quels avantages à faire du SAFe ?

Les avantages essentiels à faire du SAFe :

• Un packaging cohérent et complet, une approche globale de la transformation : là où les autres framework ne traitent que les aspects organisationnels, SAFe évoque toutes les composantes d’une transformation (Craftsmanship, DevOps, budgétisation, stratégie, leadership et gestion du changement). Le packaging clarifie l’articulation globale de tous ces éléments afin qu’ils forment un ensemble assez cohérent.
• Il provoque un changement suffisamment conséquent pour faire bouger les lignes : la plus petite maille pour faire du SAFe c’est le train (une 50aine de personnes minimum). C’est un changement assez petit pour se faire rapidement, mais assez grand pour “déstabiliser” le status-quo et mettre l’entreprise en mouvement.
• SAFe utilise un langage qui parle aux leaders; même quand il s’agit de parler technique. Cette prise de hauteur permet d’avoir un discours impactant permettant d’embarquer certains leaders et les amener à prendre les décisions nécessaires à la réussite de la transformation.
• Un référentiel commun et public avec une communauté (SPC, SPCT) assez conséquente vous permettant entre autre de ne pas être dépendants de vos prestataires et donc de sécuriser les sponsors. Une offre de formation variée suivant le sujet d'intérêt (surtout avec les nouvelles formations Lean Portfolio management et SAFe for architects).

Quel est le problème alors ?

Aujourd’hui nous observons que malgré tout, certaines implémentations sur le terrain sont très souvent pauvres et n'amènent aucun changement véritable dans les entreprises,  mis à part une meilleure gestion des dépendances. Les causes essentielles sont :

• Les entreprises ne se posent pas la problématique de résoudre la vision de la transformation. Elles plongent directement dans la solution et se limitent aux  déploiement de la partie programme de SAFe (souvent réduite au PI planning) sans un intérêt réel pour les autres aspects. Certaines entreprises ne passent jamais à l'étape d'après (et qui est la plus intéressante en terme de transformation d’entreprise) qui consiste à résoudre les problèmes de fond : des structures d’équipes et une architecture qui ne favorisent pas l’autonomie, Une culture d’entreprise qui ne supporte pas la transparence, Un processus de build qui ne favorise pas un flux continu de valeur.
• Deuxième souci, assez flagrant, le niveau très hétérogène des consultants SPC. La certification est assez facile à passer (il faut bachoter) et permet donc à beaucoup de personnes d’opérer une reconversion professionnelle. Ne connaissant pas les fondamentaux de l’Agile, ils font du déploiement de SAFe en oubliant que la finalité c'est de faire de l'Agile, d'aider les entreprises à s’approprier leur transformation et à se changer en profondeur. ScaledAgile en est conscient et bientôt nous verrons arriver une nouvelle certification plus crédible (entre le niveau SPC et le niveau SPCT).
• Troisième problème, les entreprises qui adoptent SAFe ne poussent pas assez loin la réflexion sur la simplification de l'entreprise et de sa structure. Pourquoi autant de rôles ? Est-ce nécessaire ? Comment repenser le modèle pour aplatir l'entreprise et rapprocher décisions stratégiques et exécution ? A-t-on vraiment besoin de tous les artefacts de l'Epic à la User Story pour aligner l'entreprise ? Pourquoi ne pas responsabiliser l'équipe sur ses objectifs business et lui donner l'environnement nécessaire pour y arriver ?

Au final SAFe : bien ou pas bien ?

Réponse de coach "et vous, vous en pensez quoi ?", réponse de consultant "ça dépend".

Plus sérieusement, SAFe ne correspond effectivement pas à un idéal à atteindre en termes d'Agilité. Je n'ai pas vu une entreprise des GAFA ou un éditeur reconnu sur la place faire du SAFe. Ce sont des entreprises qui dès le départ ont réfléchi leur organisation dans l’optique de l’Agilité et n’ont donc pas besoin d’un tel framework pour se transformer. Puis, une transformation Agile en profondeur consisterait à faire moins (limit the wip), à simplifier les produits et leur architecture et puis à simplifier l'organisation. Less is more!

En revanche, il est difficile, voire impossible, d’atteindre cet idéal avec une entreprise qui repose sur un Legacy autant sur le plan organisationnel que technique.  Chez beaucoup de clients, l’organisation et le SI sont trop complexes pour tenter d’emblée une approche radicale. Dans ces contextes SAFe apporte beaucoup de structure et de transparence. Il favorise un développement plus incrémental, une meilleure maîtrise de la gestion des sujets transverses et un modèle de budgétisation adapté. SAFe leur apporte beaucoup, les clients sont satisfaits …  et c’est le plus important.

Pourquoi priver vos clients d'apports qui ne sont pas négligeables par pure défiance ou dogmatisme ? Beaucoup de transformations peuvent se faire sans SAFe et tant mieux. Mais dans certains cas c’est nécessaire, et dans ces cas une intervention de coachs Agile avisés, expérimentés pour compléter les compétences SPC est incontournable.

Pour aller plus loin :

https://ronjeffries.com/xprog/articles/safe-good-but-not-good-enough/

https://agileforest.com/2018/06/24/why-safe-is-not-the-scaled-agile-approach-you-need/

https://www.agilealliance.org/resources/experience-reports/what-safe-doesnt-tell-you/

Glossaire

SAFe : Scaled Agile Framework

SPC : SAFe Program Consultant

SPCT : SAFe Program Consultant Trainer