Devenu très médiatique en quelques années, le modèle SAFe, qui vise à rendre le delivery des projets IT d’une entreprise agile « à l’échelle », est extrêmement séduisant.
Les retours d’expérience qui s’accumulent font cependant apparaître aujourd’hui des écueils communs rencontrés par de nombreuses organisations. Ce framework est en effet très complexe et peut vite
devenir intimidant. Sa réputation fait que des organisations s’imposent de le choisir et tentent de l’apposer directement sur leur existant, quitte à ne pas mener les bons combats. La mise en œuvre de SAFe devient alors
douloureuse et donne des résultats décevants.
SAFe nécessite un mandat de transformation globale
L’un des principaux problèmes rencontrés est que le framework est le plus souvent appliqué pour améliorer le delivery informatique. Or, il faut que tous les acteurs se remettent en question pour faire émerger un
fonctionnement agile à l’échelle – c’est précisément l’intérêt de spécifier « à l’échelle ». L’agilité de bout en bout implique
un mandat de transformation global qui dépasse la DSI et l’amaigrissement de ses processus en mode Lean. Le framework étant appliqué au niveau de la DSI, on constate un manque de maturité des métiers sur le
product management, ce qui entraîne des difficultés lors des PI Plannings et donc sur le delivery des équipes.
En ce sens, la réponse à « pourquoi implémente-t-on SAFe ? » doit être partagée en permanence avec tous les collaborateurs. S’agit-il vraiment de seulement délivrer plus souvent ?
Ou cherche-t-on également un meilleur alignement IT-métiers ? Et un meilleur engagement des collaborateurs au quotidien, alors que le travail à distance amoindrit l’intelligence collective ?
Ce travail sur
le « why » est la fondation sur laquelle s’appuyer pour relever deux défis entremêlés : ceux de l’exploration continue et de l’excellence technique.
Exploration continue et excellence technique sont vitales
Un mode de fonctionnement agile implique en effet une démarche itérative permanente qui n’a rien d’anodin quand on veut la porter à l’échelle. Le framework existe ainsi pour créer un « collectif
de collectifs » agiles, qui se rattache clairement à la stratégie de l’entreprise. Il ne s’agit pas de reproduire les limites des équipes agiles très autonomes qui sont déjà nées
ces dernières années dans les grandes organisations. L’excellence opérationnelle recherchée ne s’atteint cependant que si tous les acteurs y sont préparés, alors que SAFe impose un rythme
très intense. Notamment, le rythme de PI planning implique pour les équipes de travailler en continu sur leur backlog et de tester les nouvelles fonctionnalités en permanence.
Ainsi, quand les équipes conçoivent un incrément de produit avec les utilisateurs finaux, elles doivent garder en tête que cet incrément doit pouvoir être testé concrètement ces utilisateurs. Se concentrer
sur les fonctionnalités sans prendre en compte cette dimension amont/aval fait perdre tous les bénéfices de l’agilité. En amont : les équipes ont-elles bien conscience de ce qu’implique côté
métier le fait de proposer des entrants de qualité et cohérents, de la vision stratégique, à la décomposition en user stories à la bonne granularité et vraiment exploitables par les équipes
? En aval : est-on capable de livrer très régulièrement aux utilisateurs ce qui est conçu tout en assurant la qualité de service attendue ? Concevoir « juste à temps », passer
un temps équilibré sur chacune des features travaillées, prioriser en continu… Sans cette excellence technique adaptée de bout en bout, l’entreprise finira par se rendre compte que son framework ne permet pas
de livrer régulièrement un incrément de valeur. Et ce pour une bonne raison : SAFe ne sera qu’un beau tapis cachant les poussières d’un cycle en V.
SAFe vient percuter la culture d’entreprise et le cadre RH
Après avoir dressé ce constat, qu’est-il possible de changer pour faire bouger les lignes ?
D’abord d’un point de vue stratégique : pour l’entreprise, il est déjà nécessaire de « faire un pas de côté », c’est-à-dire d’éviter d’appliquer
le modèle SAFe sans embarquer les métiers ou en ne faisant pas systématiquement le lien avec l’intention qui a suscité le changement. Arriver avec un nouveau vocabulaire, des cérémonies, des comportements
différents nécessite de jouer également d’une certaine flexibilité sur les rôles et l’emprise des pratiques, plutôt que d’appliquer à la lettre un code qui s’imposerait brutalement
aux métiers. SAFe vient percuter la culture d’entreprise : on ne peut tout simplement pas attendre qu’il entraine un changement de mindset mécaniquement. Il va falloir le développer à tous les niveaux.
Un tiers pour mesurer l’agilité et assurer la transparence de la nouvelle relation DSI-Métier
D’un point de vue opérationnel, d’autres bonnes pratiques peuvent aider, comme la généralisation du co-design et l’UX design. Intégrer les PO, PM et UX designers dans les équipes pour créer de
la mixité est en ce sens un facilitateur. Il est également intéressant de faire participer directement les développeurs aux interviews utilisateurs pour les rendre pleinement acteurs de l’amélioration continue.
Autant de partis pris qui permettent d’en appeler à la créativité de façon transversale et de sortir du mindset « donneur d’ordre vs. exécutant ».
Pour y parvenir, toutes les parties vont devoir jouer le jeu du changement. SAFe implique que les métiers puissent s’appuyer sur des personnes dédiées, tout au long du projet y compris dans sa suite, dans une logique d’amélioration
continue. C’est extrêmement exigeant. Installer une transparence réciproque sur les attentes de la DSI et des métiers est nécessaire. La transformation doit se faire au niveau de l’entreprise grâce à
une coalition globale (DG, DSI et métiers) permettant de construire une vision stratégique business consistante et une stratégie de delivery IT, l’ensemble piloté et aligné sur les enjeux de l’entreprise.
Pour mener à bien cette coalition, la discussion doit se faire sur un terrain neutre et la Direction Générale sera bien inspirée de faire appel à un tiers !
Une vigilance particulière va être nécessaire sur le plan des Ressources Humaines. C’est un chantier en soi que d’intégrer de nouveaux postes, profils et missions au modèle RH traditionnel, sacro-saint de
l’entreprise. Les postes de RTE (Release Train Engineer, le "conducteur du train”), de PM (Product Manager) et de PO (Product Owner) sont clés et n’existent pas au départ dans l’organisation. Transformer un manager
métier pour assurer un rôle de PM ne s’improvise pas : que devient sa responsabilité de manager traditionnel ? Quel parcours de carrière est-il possible d’imaginer dans ce nouveau cadre ? Cette
transformation d’entreprise nécessite donc de mobiliser jusqu’au directeur général car il va falloir réconcilier la transformation actuelle des métiers avec ce changement profond de fonctionnement.
Celui-ci devra avoir de plus la responsabilité importante d’auditer les nouveaux processus mis en place et de mesurer l’évolution de la maturité agile. Pour faire vivre le framework dans la durée, il est essentiel
de sortir du seul ressenti, pour être en mesure de suivre des indicateurs précis et leurs évolutions dans la durée. Est-ce que les solutions sont continuellement déployées en production ? Est-ce que les
cérémonies ont bien lieu et avec quelle régularité ? Est-on vraiment sorti du cycle en V dans la livraison régulière des incréments de valeur ? Montrer comment chaque nouvelle pratique amenée
par le Framework a un sens, sert concrètement l’agilité et la transformation, et justifie l’intérêt de ce nouveau fonctionnement.
SAFe ne peut constituer une fin en soi et il nous semble fondamental de rappeler qu’une transformation agile ne se réduit pas à calquer des frameworks et des artefacts. Ce type de déploiement, sans intention de transformation
plus profonde, constitue même un anti-pattern d’agilité. En effet, il convient d’appréhender ce genre de framework comme une boîte à outil, un référentiel de rôles, et savoir avec discernement
l’adapter à son contexte, à son organisation et à ses enjeux.