Si d’aventure vous avez suivi la blogosphère agile ces 18 derniers mois, il peu probable que vous ayez échappé au buzz créé par le framework SAFe : Scaled Agile Framwork. Est-ce le nouveau Grâal du déploiement de l’agile à l’échelle de l’entreprise ? Est-ce la recette de la potion magique des Google, Amazon, Netflix et autres (Gaulois) Géants du Web ? Je vous propose de gagner un peu de temps et répondre d’ores et déjà que non. SAFe n’est pas LE framework universel qui s’appliquera comme par enchantement à votre contexte et fera de vous l’Amazon de votre secteur d’activité.

« Tous les modèles sont faux, mais certains sont utiles » Georges Box

Ce framework n’est pas donc pas magique, mais a le très bon goût d’exister et de soulever des questions pertinentes via le modèle qu’il propose.Le modèle s’appuie sur un découpage qui qui sera familier à toute personne ayant flirté avec PMBOK puisque Leffingwell propose d’observer l’entreprise au travers du triptyque :
– Equipes — et leurs projets
– Programmes — gros projets ou grappes de projets
– Gestion de portefeuille d’investissement

Je vous propose dans cet article de parcourir les 3 couches de la Big Picture proposée par Dean Leffingwell tout en vous partageant mon avis.

Le niveau équipe

Le niveau équipe décrit le mode de fonctionnement d’une équipe agile autour d’un projet.

Ce niveau n’apporte pas de concepts fondamentalement nouveaux à ce que l’on connait déjà. L’auteur redonne sa définition des différents roles agile issus de Scrum et XP.

Sur la question de la méthodologie à suivre, le framework est peu préscriptif. Il pousse plutôt l’utilisation de scrum dans les équipes. Chez OCTO, nous préferons laisser la porte ouverte à Scrum comme toute autres méthodes favorisant un travail contraint dans le temps (timebox) réunissant des équipes suffisamment pluri-disciplinaires pour concevoir, réaliser et tester ensemble des fonctionnalités logicielle.

Le niveau programme

De l’A.R.T. de la livraison en rythme

Au niveau programme, Leffingwell introduit la métaphore du train de livraison : le Agile Release Train pour faire le bel acronyme ART.
C’est à mon sens l’un des points les plus intéressants du framework car simple à comprendre et fort dans le message qu’il envoie aux équipes. Si vous faites partie d’un très gros projet multi-équipes ou d’un groupe de projets utilisant des composants logiciels communs : vous faites partie du même train de release.

• Ce train sera donc votre unique véhicule pour livrer une fonctionnalité en production (ou dans tout autre sas « anté- production »).
• Ce train part et arrive à date fixe. Ainsi, si vous n’avez rien à livrer lors de son passage, vous prendrez le prochain.
• Le train n’attend personne, il prend ce qui aura été déposé dans ses « wagons ». Ainsi, si vous n’avez pas mergé, testé, documenté etc… vous ne pourrez pas profiter d’un wagon de livraison.

La métaphore est quasiement trop simpliste mais constitue pour autant l’épine dorsale de l’adage agile : « on ne négocie pas la date, on négocie le contenu » (cf. « inverser la logique du triangle ressource, temps, périmètre »).
Pour les afficionados de l’organisation Agile de Spotify, vous retrouverez la même idée dans ce schéma issu de leurs vidéos « Engineering Culture »

Release Train Engineers, les agents du « liant »

Pour s’assurer de la cohérence et de la consistance des livraisons, certains rôles apparaissent à cet « étage » du modèle.

Leffingwell propose plusieurs rôles qui nous semblent trop nombreux pour de petites structures (System Engineer, Release Train Engineer, Epic owner, Product Manager, Product Owner, Business Owner, System Architect, Enterprise Architect, QA, Developer, PMOs, etc. ). On peut voir ici les premices d’une bureaucratie fortement reprochée, à juste titre, à Lefingwell par ses alter ego de la communauté agile.

On retiendra tout de même le rôle de Release Train Engineer qui est clé pour un déploiement à large échelle multi-équipe. Il sera en quelque sorte l’aiguilleur du ciel, le scrum master « lead » des scrum masters et s’assurera de la cohérence d’un ou plusieurs train de release.

Release Planning, un nouveau rituel intéressant

La vue programme est essentiellement là pour adresser les enjeux de coordination de plusieurs équipes. Soit ces équipes travaillent sur un seul et même projet et elles partagent le même train de livraison qui partira toujours à fréquence fixe. Soit les projets sont disjoints mais peuvent être amenés à interagir entre eux de par le fait qu’ils évoluent au sein de la même entreprise et utilisent des ressources communes. Ce cas de figure nécessite un effort de coordination un peu plus en amont car le seul fait de partager un même train de release ne suffira probablement pas.
SAFe propose à cet effet un atelier de deux jours, le « release planning », sur une fréquence par exemple trimestrielle, où les différentes équipes agiles se retrouvent pour co-construire les roadmap des 3 prochains mois et ainsi évaluer les risques d’inter-dépendance entre projets.

Cette pratique s’avère vraiment efficace et est à vos roadmaps ce que le sprint planning est au backlog : un outil agile de planning et de réaction au changement.

Réaliser les ateliers sur 2 jours consécutifs permet d’économiser un temps précieux. En effet, lors de phases de mise à jour de roadmap, les réunions entre chaque corps de métier (métier, dev, ops, design, pmo…) se multiplient et surtout s’étalent dans le temps souvent faute de disponibilités. En planifiant longtemps à l’avance ces 2 journées consécutives avec tous les interlocuteurs nécessaires, il devient alors possible de consituer et valider une roadmap pour les 3 prochains mois en un temps record.

Voici ici l’agenda type de ces deux jours :

Le niveau portfolio

A ce niveau SAFe préconise d’appliquer un modèle Kanban à la gestion des programmes / gros projets qu’ils soient techniques ou métiers. A nouveau Leffingwell s’est vu chahuté pour cette proposition car l’idée de limiter l’encours de projets est une proposition intellectuellement intéressante mais opérationnellement critiquable et peu réaliste (cf. cet échange de David Anderson avec le communauté Kanban et SAFe à ce sujet). Il apparait assez difficile de positionner une limite d’encours sur son processus de gestion de porte-feuille quand les projets peuvent s’adresser à des équipes très différentes, quand des projet stratégiques doivent se lancer rapidement pour réagir à un changement marché etc… Il incombera à chacun de se faire son idée et de trouver une implémentation qui lui convient.

Je retiendrai cependant la formalisation des étapes du flux de sélection des projets où l’on s’essaiera à retirer du porte-feuille un projet dont la fiche de proposition n’est pas satisfaisante ou encore si une fois le cadrage fait, il apparait qu’il vaut mieux ne pas réaliser le projet (trop risqué, trop cher, pas pertinent etc…)

C’est finalement à ce niveau que le top management commence à goûter aux bénéfices de l’agile en repriorisant régulièrement son porte-feuille d’investissement.

Alors SAFe, c’est bien ?

Je ne pense pas qu’appliquer SAFe stricto sensus permette d’effectuer une transformation agile sans encombre. Le framework est un peu trop touffu (important nombre de rôles, templates de documents verbeux…) et manque parfois de pragmatisme.

Je ne participerai en revanche pas au bashing ambiant de la communauté agile qui vise à tapper un peu obstinément dessus car je trouve que SAFe permet de se poser des questions essentielles en l’utilisant comme prisme d’analyse.

Force est de le constater, les transformations agiles qui fonctionnent ne s’appuient pas sur le déploiement d’un framework magique quel qu’il soit. Elles reposent généralement sur une démarche de déploiement organique et surtout sur la création et la consolidation d’une culture favorisant la confiance, la responsabilisation, l’autonomie, le goût de l’excellence et le sens.

Et vous, avez-vous essayé SAFe ? Avez-vous rencontré des difficultés, ou mieux encore, de belles réussites ?