En 2009, j’ai découvert le monde de l’Agilité et ses valeurs, au sein d’une grande banque Française. A l’époque l’adoption de l’agilité n’en était qu’à ses débuts en France et peu d’entreprises avaient osées sauter le pas. Au fil des années, la communauté agile Française a grandie, les valeurs et apports de l’agilité ont commencés à démontrer leurs bénéfices sur les équipes et les organisations (même s’il reste encore du travail) et les entreprises sont passées de petites expérimentations à la volonté d’adopter l’agilité à grande échelle.

La problématique s’est alors posée sur la façon d’accompagner ce changement de paradigme, à l’échelle d’une entreprise. Jusqu’alors, les transformations agiles concernaient le plus souvent des équipes IT, de petite taille (principe de Scrum), rarement en dépendance entre elles. Ces équipes IT étaient souvent les seules à être passées à l’agilité (90% du temps sur du Scrum) et se retrouvaient déconnectées des autres services/équipes de l’entreprise, qui eux gardaient leur anciennes méthodes de travail.

Les Framework Agile ont alors fait leur apparition, dont Less pour la partie Scrum à l’échelle, suivi de son concurrent Nexus et le plus connu, SAFe (Scaled Agile Framework), qui commence à s’implémenter dans quelques grands groupes en France.

De nombreux articles ont été écrits sur ces Framework et sur SAFe en particulier, bien souvent très mitigés, voir négatifs. Ces derniers temps, je constate néanmoins une certaine atténuation de ces critiques et une analyse plus objective de la mise en place d’un framework agile, comme cette vidéo de Henrik Kniber et  Lars Roost sur l’expérimentation de SAFe chez Lego.

Cette série a pour objectif de partager avec vous ma modeste expérience dans la mise en place et l’utilisation de SAFe, auprès d’un grand groupe, sur une période d’environ une année.

Ce REX est basé sur la version 2.5. Une comparaison sera faite entre cette version et les nouveautés apportées par la V3.0.

Commençons par une description de la Big Picture SAFe.

 SAFe c’est quoi ?

SAFe, pour Scaled Agile Framework (Framework Agile à l’échelle), est un modèle d’organisation « Agile » de l’entreprise, créé par Dean Leffingwell et décomposé en 3 grandes couches, représentées par la Big Picture ci-dessous (cliquez dessus pour accéder au site SAFe).

La couche Team

Il s’agit du niveau d’ingénierie opérationnelle du framework, ou vont se retrouver l’ensemble des acteurs participants à la phase delivery de création de valeur d’un produit.

L’organisation proposée par SAFe reste très ancrée sur le cadre Scrum, avec un découpage en Release de 5 itérations de 2 semaines chacune, dont la dernière a pour objectif une synchronisation entre les Teams et une refactorisation avant livraison de l’incrément de produit.

On y retrouve décrit les rôles, cérémonials et artefacts de Scrum, ainsi que les best practices d’ingénierie agile XP (eXtreme Programming). Il est à noté, que SAFe met en avant l’importance de la qualité du code, en préconisant notamment une approche DevOps et les pratiques d’intégration continue. Autre pratique mise en avant par le framework SAFe, » l’architecture agile », qui est souvent le parent pauvre des pratiques agile.Le niveau Team peut regrouper de 5 à 15 équipes Scrum, au sein de ce que SAFe nomme un Agile Release Train (ART), piloté au niveau du Program. Cela signifie un lien fort et transparent entre la couche Team et la couche Program.

L’ensemble des équipes d’un même ART est synchronisé sur des releases et des itérations de même durée, avec une gestion forte des dépendances entre elles.

Apports de la V3.0

Welcome Kanban

La dernière version du Framework SAFe intègre (enfin !) les pratiques du système Kanban dans l’organisation et le fonctionnement des équipes. C’est, à mon sens, un plus par rapport à la V2.5 qui était très (trop) orientée Scrum et pouvait apparaître comme un modèle d’organisation rigide et non adaptatif.

Dorénavant, et même si elles ne me semble pas assez mise en avant (autant sur la big picture que dans la description du niveau Team), SAFe préconise d’intégrer des pratiques Kanban au cadre Scrum. C’est ce que l’on nomme couramment « ScrumBan ». C’est à chaque équipe de décider du modèle quelle juge le plus adapté à son fonctionnement et lui apportant le plus de valeur dans l’atteinte de ses objectifs. De ce fait, rien n’empêche, au sein d’un même ART, d’avoir des équipes en Scrum et d’autres en ScrumBan, ce qui a d’ailleurs été le cas sur le programme faisant l’objet de ce REX, ou j’ai intégré un modèle ScrumBan au sein des teams que j’accompagnais, mais nous verrons cela en détail dans un prochain article de cette série.

 La couche Program

Il s’agit la de la couche de « Pilotage/Management » (oula le vilain mot ! ;)) d’un programme, via la notion de « Agile Release Train ». Un « Agile Release Train » va simplement regrouper l’ensemble des Teams intervenant sur le même programme ou les mêmes composants logiciels.  C’est à ce niveau que la phase de priorisation des features intervient, basé sur une vision et une roadmap, ainsi que le suivi des indicateurs de performances ou encore la définition des règles d’architecture, de DevOps et d’UX.

Un Agile Release Train porte généralement sur un périmètre de 5 à 12 équipes, représentant de 50 à 125 personnes, réparties au sein d’équipes Scrum pluridisciplinaires, alignées sur les mêmes cadences et partageant une vision et un objectif commun.

Apports de la V3.0

Shared

Aux déjà nombreux rôles de la V2.5, la V3.0 intègre le rôle de Shared, qui regroupe l’ensemble des acteurs pouvant apporter une plus value à un Release Train, sans faire partie intégrante de celui-ci. Un peu comme les Stakeholders en Scrum.

Prioriser par le WSJF

Déjà existante dans la V2.5, mais non représentée au niveau de sa Big Picture, la notion de WSJF (Weighted Shortest Job First) fait son apparition. WSJF a été défini par Don Reinersten et a pour objectif la priorisation des features. Le calcul du WSJF est basé sur le rapport entre le Cost Of Delay et l’effort de traitement à réaliser sur la Feature (souvent celui-ci est remplacé par l’estimation de la taille, au sens agile du terme).

La V3.0 insiste sur l’importance d’une revue du WSJF à chaque Release Planning,  associée à la phase de rétrospective (Inspect & Adapt).

ART Metrics

La notion de mesure d’indicateurs au niveau programme est aussi mieux mise en avant sur la Big Picture V3.0.

Bien que SAFe propose la mesure d’un certains nombre de KPI (très orienté Scrum, à mon sens), rien ne vous interdit (bien au contraire) de mettre en place vos propres indicateurs de mesure de la performance de votre Release Train et de votre programme.

Vers une culture produit avec le Product Management

La Big Picture V3.0 apporte un réel plus dans la notion de Management de produit, en traçant un lien entre le Product Management et la vision/roadmap/program Epics. Ce simple lien montre clairement  que ces sujets doivent être portés/pilotés par le Product Manager du programme. C’est un plus vers l’évolution d’une culture produit au sein de l’organisation.

La couche Portfolio

Il s’agit du plus haut niveau du framework, dont l’objectif est d’aligner l’ensemble des programmes sur la stratégie et la vision de l’entreprise. Plusieurs Portfolio peuvent être implémentés dans un grand groupe, chacun portant sa propre vision et pouvant piloter plusieurs Agile Release Train.

SAFe préconise la mise en oeuvre d’un système Kanban, dans la gestion et la priorisation des EPICS business et architectures. Un certains nombre de critiques ont été formulées, par la communauté Kanban, sur le fait que limiter l’encours du processus de gestion d’un portefeuille était assez irréaliste, notamment pour des sujets pouvant s’adresser à des équipes différentes. Personnellement, j’ai tendance à penser qu’un système Kanban peut apporter une plus forte prise en compte par la couche portfolio de la notion de business value des epics et d’arriver à mieux prioriser par la valeur les activités d’une organisation. Cela peut également permettre de mieux définir, visualiser et améliorer le flux de montée en maturité des EPICS.

Apports de la V3.0

Lean Agile Leaders

La V3.0 intègre le rôle de Lean-Agile Leaders, qui vont porter les valeurs et concepts Lean

 SAFe, un framework d’options

SAFe, a un avantage énorme, c’est sa documentation très détaillée et des mises à jour régulières de son modèle. SAFe a également un gros désavantage, … sa documentation très détaillée !!

En effet, bien souvent les organisations sont séduites par la sécurité apportées par un framework comme SAFe, ou tous les rôles et les niveaux de décisions semblent adressés, mais bien souvent elles ont du mal à s’approprier les valeurs agiles et lean portées par ce framework et surtout l’adapter à leur propre contexte, du fait justement d’une documentation ou tout semble décrit à la virgule prêt.

Mon sentiment est que SAFe doit d’abord être vue comme un Framework offrant un certains nombre d’options de mise en oeuvre d’une organisation agile à l’échelle et que comme tout framework informatique doit pouvoir être adapté, modifié, amendé, en fonction du contexte de l’organisation.

« En programmation informatique, un framework ou structure logicielle est un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel (architecture). » (définition Wikipédia).

Pour aller plus loin : Déjà la 4.0

A l’heure ou j’écrivais les dernières lignes de cet article, la version 4.0 de SAFe a fait son apparition, avec notamment un niveau supplémentaire « Value Stream » (entre la couche Portfolio et Program) et Une vision Entreprise. Vous pouvez la retrouver en détail ici.

La V30 reste néanmoins d’actualité et accessible jusqu’en décembre 2016.