Introduction

Durant ma carrière (un peu pompeux mais bon) j’ai travaillé pour un client grand compte. Lorsque je suis arrivé en mission, le choix du framework SAFe avait déjà été fait et ce depuis un peu plus d’un an. A travers cet article, je vais vous donner mon retour sur ce framework, ce à quoi il répond chez ce client et ce que j’en pense. Accrochez vos ceintures on démarre !

C’est quoi SAFe ?

Comme vous le savez, l’agilité n’est pas une méthode à proprement parler mais un concept de travail autour de valeurs et de principes que vous pourrez consulter dans le manifeste agile : http://manifesteagile.fr/

D’un point de vue opérationnel pour appliquer ces valeurs et principes, des méthodes ou frameworks ont été créés (tels que Scrum, Lean, Kanban, SAFe…) afin de proposer des organisations de travail pour répondre à certains problèmes.

Je ne vais pas vous expliquer de long en large et en travers le framework SAFe, la source d’information la plus fiable étant le site officiel : https://www.scaledagileframework.com/

Par contre je peux vous expliquer le principe de SAFe. C’est ce qu’on appelle l’agilité à l’échelle. Nous savons tous que la taille d’une équipe Scrum est comprise entre 4 et 10 en comprenant tous les rôles (équipiers dev, Scrum Master et Product Owner). A 10, ça devient déjà un peu compliqué à gérer tant au quotidien que pendant les cérémonies. SAFe propose une organisation qui permet de travailler avec plusieurs équipes de taille « Scrum ».

Si vous avez creusé un peu sur le site officiel, vous avez dû voir qu’il existe différents stades d’implémentation de SAFe avec plus ou moins de couches hiérarchiques.

Pourquoi mon client a choisi SAFe ?

LA grande question ! Mais pourquoi avoir choisi SAFe ???

Un peu de contexte

Avant de répondre au pourquoi, je vais vous expliquer le contexte client. Il faut savoir que ce client est une grosse entreprise internationale de plus de 100000 personnes. Autant vous dire que la transformation agile d’une entreprise de cette taille c’est loin d’être gagné… Certaines mauvaises langues diraient même que cela relève plus de la science fiction ^^

Dans le service, il y a 11 équipes dont 9 Feature Teams (produisent des fonctionnalités), 2 System Teams (intègrent les différents composants) réparties sur différents sites à l’international. La création de cette plateforme est une initiative d’entreprise. Elle a pour vocation d’être utilisée par d’autres entités qui conçoivent des produits. En résumé, les clients de la plateforme sont des clients internes.

Pourquoi ?!

Cette décision a été prise avant que j’arrive sur la mission. Cela faisait déjà un an que SAFe était en place quand je suis arrivé.

Le choix du framework SAFe vient d’en haut. Dans l’entreprise, les hautes instances incitaient à se tourner vers SAFe pour les gros programmes qui souhaitaient faire de l’agilité. Le service a donc levé le doigt en disant : « on va le faire » et voilà le service entier transformé en beta testeur de SAFe dans l’entreprise. Pourquoi SAFe plutôt que le modèle Spotify ou autre ? Le mystère reste entier !

Après un argumentaire tel que celui-là, il serait assez facile de dire que c’est une très mauvaise décision. Oula oula oula, pas si vite ! En effet, à cette époque, il y avait une seule équipe d’une quinzaine de personnes avec un bon nombre de kilomètres entre elles. L’organisation tendait à faire du Scrum (je dit bien « tendait ») mais il n’y avait pas de Product Owner ! La croissance du service ayant été anticipée, ce choix n’est pas mauvais loin de là et cela permet d’avoir un levier en interne pour créer des postes afin d’avoir une organisation cohérente avec les objectifs de la plateforme.

En effet, le service est passé de 1 équipe à 11 équipes, il y avait donc un véritable enjeu par rapport à ce passage à l’échelle, notamment le besoin de synchronisation entre ces équipes. Autre point, les clients sont internes à l’entreprise et ne partagent pas forcément les mêmes cycles de développement que nous. Par conséquent pour eux il y avait une nécessité d’avoir une roadmap figée à 3 mois (vision par PI), chose que Scrum ne peut pas forcément garantir. Scrum garantit les délais de livraison mais pas le contenu des livraisons.

Vous en êtes où dans SAFe ?

L’application de ce framework se fait généralement par étape en partant de la version essential jusqu’à la version full. L’organisation du service est à la fois proche de full (le stade ultime^^) mais pas tout à fait non plus. Comme vous le savez mettre en place une organisation dans un service relativement gros, cela prend du temps et les recommandations ne sont pas toujours suivies à la lettre…

Schéma global de SAFe

Comme je l’ai dit précédemment il y a 9 Feature Teams et 2 System Teams le tout reparti sur 2 ART (Agile Release Train). Malheureusement le découpage en ART a été fait pour des raisons géographiques et politiques plus que pour un découpage fonctionnel ou architectural. Il y a 5 Product Owners et autant de Scrum Masters, des architectes, des architectes solution, des Release Train Engineers (RTE), des Product Managers et Solutions Managers (mais ils ont un autre titre dans l’entreprise). Bref comme vous le voyez, nous sommes proches du full SAFe.

Et donc t’en penses quoi ?

Est-ce agile ?

Je ne vais pas y aller par 4 chemins, NON, ce n’est pas agile. Après cette phrase choc, charge à moi d’étayer mes propos. Je vous propose de découper cela en 2 parties, ce qui est agile dans SAFe et ce qui ne l’est pas. Pour moi, ce qu’il ne l’est pas est trop important pour considérer SAFe comme une méthodes agile.

Ce qui est agile dans SAFe ?

Tout d’abord, au sein de l’équipe, SAFe prévoit d’utiliser Scrum. A moins que quelqu’un veuille me contredire, Scrum est une méthode agile. Son utilisation implique donc un cadencement en sprint de tailles régulières avec à chaque fin de sprint une démo, une rétrospective (voir ma retro sur un an de retro) et un planning. Je reparlerai du planning plus tard. Les notions d’amélioration continue et de livraison rapide pour avoir le plus rapidement possible du feedback sont respectées mais avec l’inertie d’une grosse structure.

Ensuite, SAFe insuffle la culture DevOps. La mise en place des ART et des System Teams encourage à la mise en place de la CI/CD ce qui permet de livrer plus rapidement avec un bon niveau de qualité (du moment que la stratégie de test est bonne…).

Pour finir, je parlerai du sprint d’innovation et planification. Cela n’est pas à proprement parler agile, mais c’est un point très positif de la méthode et je dois avouer ne jamais avoir vu de telles pratiques dans d’autres organisations. Après un certain nombre de sprints de production, on se réserve un sprint où l’on va préparer les prochaines features sur lesquelles on va travailler lors du prochain PI. On va également faire de la veille technique afin d’explorer des idées/solutions techniques qui pourraient être bénéfiques pour le produit. La veille technique, les devs adorent ça !!! Donc non seulement c’est bon pour le produits mais c’est également bon pour le moral des troupes !!!

Ce qui n’est pas agile dans SAFe ?

Je vais commencer avec le plus gros problème de SAFe selon moi qui choque assez sur le schéma :

Relation client équipe dans SAFe

Vous noterez la distance qui sépare l’équipe (aussi bien le PO que les équipiers) du client ! La voix du client passe par énormément d’intermédiaires avant d’arriver jusqu’à l’équipe. Certains clients assistent à la Solution Demo, mais l’équipe n’est pas impliquée lors de celle-ci et le feedback est long à redescendre jusqu’aux équipes et il y a quelques perturbations dans le message évidemment. Du coup, pour reprendre le manifeste agile, « La collaboration avec les clients, de préférence aux négociations contractuelles » est bien compliquée avec une organisation pareille. Dans notre contexte il y a une notion contractuelle avec nos clients actuels mais nos équipes ne sont pas concernées par cet aspect. Cependant, sur cette mission nous avons eu quelques présentations de clients qui nous ont montré ce qu’ils faisaient avec la plateforme. Pas évident d’avoir du contexte dans ces conditions ! A noter que les présentations des clients mises en place ne sont pas des recommandations de SAFe non appliquées mais des actions prise suite à des retros.

Pour enchaîner de manière plus globale, full SAFe propose tellement de couches hiérarchiques que, pour reprendre le manifeste agile, « Les individus et leurs interactions, de préférence aux processus et aux outils » est bien compliqué quand on cadence un nombre conséquent de personnes. La mise en place de processus et outils devient vite la solution à tous les problèmes. ATTENTION : Ce point est basé sur ce que j’ai observé dans cette mission. Peut-être que d’autres implémentations de SAFe n’ont pas ces travers.

En ce qui concerne la posture du PO, dans une équipe Scrum, c’est le garant des priorités et des fonctionnalités du produit. Plus on tend vers le full SAFe plus il y a d’intervenants sur le scope fonctionnel. Le PO n’est plus le seul décideur sur cette aspect ce qui donne lieu a des arbitrages et surtout de la latence. La réactivité et la simplicité d’organisation mise en avant par Scrum se retrouve mise en cause dans SAFe. SAFe ne répond donc pas à ces problèmes que toutes les grosses structures vivent.

Passons à la planification maintenant. Si vous avez jeté un coup d’œil à SAFe, vous avez vu que c’est rythmé sur des PI (Program Increment). Un PI commence par un PI planning suivi de sprint de production (3 de 3 semaines chez nous) puis d’un sprint d’innovation et planification. Lors du PI planning les équipes découpent les features en stories et on élabore un plan sur le PI entier. Là ou ça se gâte, c’est la notion d’engagement face à ce plan à 3 mois ! En effet, l’équipe s’engage à livré un certain nombre de features pendant le PI, là où avec Scrum l’équipe s’engage sur un sprint. Cela à alors 2 effets :

  • Pour encore citer le manifeste agile, « La réponse au changement, de préférence au respect d’un plan », on y est pas du tout. Là où Scrum permet de fixer un cadencement de livraisons mais ne garanti pas le scope, SAFe verrouille les 2…
  • Le sprint planning, ne permet que très très peu d’ajustements

Du coup on fait du SAFe ou pas ?

Tout dépend de pourquoi on veut faire du SAFe. Il faut bien comprendre que SAFe est un compromis entre le cycle en V classique et l’agilité. Si dans le choix de SAFe votre but est de faire de l’agilité pure, alors ce n’est pas le bon. Ne connaissant pas les autres modèles qui, selon leurs auteurs, permettent de faire de l’agilité à l’échelle, je ne peux pas vous dire s’il est meilleur (ou moins pire… ^^) que les autres. Cependant, si le but de votre choix est d’insuffler quelques pratiques issues des méthodes agiles telles que l’amélioration continue, l’intégration continue ou encore la culture DevOps, mais que vous souhaitez gardez le côté waterfall pour diverses raisons, SAFe peut être une bonne réponse.

Pour conclure je dirais qu’en regardant les différents niveaux d’implémentation de SAFe, plus on est proche du full SAFe, plus on s’éloigne de l’agilité. En y regardant de plus près la version essential SAFe, c’est là qu’on est le plus proche de l’agilité ! Il y a moins de distance avec le client, moins de couches hiérarchiques, mais toujours ce système de PI.