SAFe a été créé par Dean Leffingwell en 2011 afin d’accompagner les entreprises dans le déploiement de l’agilité à l’échelle, à travers un framework structuré. L’agilité à l’échelle consiste à encadrer par une méthode la multiplication en volume des principes Agiles, ceux de SCRUM notamment.
Pour développer ce framework, son auteur s’est appuyé sur l’ensemble des bonnes pratiques issues du lean, de la culture Agile et des REX des transformations d’entreprises.
Premier contact, première impression
La documentation de SAFe est riche, librement mise à disposition à travers le site web du Framework. Pour faciliter la navigation et la découverte de ce modèle, tout est accessible via une carte. Cette carte représente l’ensemble du système mais révèle aussi toute la complexité de SAFe.
Il est très agréable de disposer d’une carte pour contenir l’ensemble du framework. Cependant ce premier contact me laisse une impression mitigée car l’objectif mis en avant par son auteur est louable mais lorsque je regarde la carte, ma première pensée est “Des processus et des outils plus que les individus et leurs interactions”. De plus on n’a pas une carte, mais trois, en fonction de la couverture de SAFe que l’on souhaite appliquer.
“9 principes pour préserver le modèle”
Conscient de la complexité d’une mise à l’échelle de l’agilité, de la multitude de contextes auxquels les acteurs de la transformation sont confrontés au quotidien, l’auteur a défini des principes qui servent de barrières.
Ces principes sont des gardiens du modèle dans le cas où les pratiques recommandées par SAFe ne peuvent pas être appliquées. Ces barrières définissent les latitudes dans lesquelles nous pouvons adapter le framework.
Ces 9 principes sont:
Adopter une vision économique
Appliquer la pensée systémique
Assumer la variabilité, préserver les options
Construire progressivement avec des cycles d’apprentissage rapides et intégrés
Poser des Jalons permettant de tester et aligner régulièrement le système de travail
Visualiser et limiter les Work in Progress, réduire les tailles de lots et gérer les longueurs de file d’attente
Appliquer une cadence et se synchroniser avec la planification inter-domaine
Déverrouiller la motivation intrinsèque des collaborateurs
Décentraliser la prise de décision
A leur lecture, rien de révolutionnaire, ni de choquant, que du bon sens au final, non ?
“4 valeurs pour orienter les comportements”
En plus de ces 9 principes, le créateur de SAFe pose 4 valeurs pour orienter les comportements des acteurs :
L’alignement : Repose sur des objectifs métiers de niveau entreprise afin que l’ensemble des équipes agiles puissent faire face aux évolutions rapides du marché, comme par exemple l’émergence d’un concurrent. L’alignement ne peut pas reposer sur l’opinion combinée des équipes agiles. Cet alignement se fait du niveau stratégique jusqu’au niveau des équipes qui exécutent le contenu des programmes.
La qualité : Elle ne peut pas être décidée à rebours, elle doit être intégrée dès le départ afin d’éviter des retards. Cette qualité intégrée se décline autour de 4 axes : Software, Hardware, Système d’intégration, Conformité.
La transparence
L’exécution du programme
“1 mindset pour les gouverner”
Pour gouverner ce modèle, il est nécessaire d’avoir un certain mindset (état d’esprit) qui est lui aussi défini par l’auteur. Ce mindset est formé de deux ensembles.
Le premier ensemble s’inspire de la Maison du Lean créée et définie par Toyota, baptisé ici : SAFe House Lean. Elle se compose des éléments suivants :
Un toit qui définit l’objectif : fournir la valeur client maximale dans les délais les plus courts possibles tout en offrant la meilleure qualité possible aux clients et à la société dans son ensemble
4 piliers qui soutiennent l’objectif :
Pilier 1 : Respect de la culture et des personnes
Pilier 2 (Flux) : Établissement d’un flux de travail continu qui prend en charge une création de valeur continue, basée sur un retour d’informations et des ajustements
constants. Un flux continu permet une livraison de valeur plus rapide, des pratiques de qualité intégrée efficaces, une amélioration constante et une gouvernance fondée sur des preuves
Pilier 3 (Innovation): Encourager la rencontre avec des utilisateurs pour vous nourrir de leurs problèmes afin d’innover
Pilier 4 (Amélioration continue) : Encourager l’apprentissage et la croissance grâce à une réflexion continue et à des améliorations des processus
Des fondations qui s’appuient sur le leadership
Le deuxième ensemble n’est autre que le manifeste Agile.
“4 niveaux pour structurer”
En complément de ce cadre déjà conséquent, l’auteur a organisé des pratiques recommandées à travers des niveaux dont nous pouvons faire le parallèle avec les strates de l’entreprise.
L’objectif de ces niveaux : permettre d’aligner l’ensemble des forces selon les stratégies d’investissement prises à la tête de l’entreprise.
Cet alignement s’effectue par le lien fait grâce aux livrables et aux événements de chaque niveau qui permettent la circulation dans les deux sens : Bottom up et Top Down. A chaque niveau, un objectif, des rôles, des évènements et des livrables sont définis.
Ces niveaux sont :
Le niveau « Portfolio » que nous pouvons rattacher à la strate « Top Management » de l’entreprise. C’est le lieu où l’on met en cohérence la vision de l’entreprise, avec
les stratégies d’investissement pour enfin définir des Portefeuilles qui contiennent des Epics de niveau Business [NDR : !!!]
Le niveau « Program » que nous pouvons rattacher à la strate « Middle Management » de l’entreprise. C’est le lieu où les EPiCs de niveau Business sont découpés pour
donner naissance à un ou plusieurs Programme(s) de développement. C’est le coeur du Système de SAFe, là où la valeur se crée de façon itérative par l’intermédiaire de l’ Agile
Release Train (ART).
Le niveau « Team » que nous pouvons rattacher à la strate « Opérationnelle » de l’entreprise. C’est le lieu où les équipes agiles alimentent l’ART par leur développement.
Le niveau « Large Solution » est une extension du niveau « Program » dont l’objectif est d’organiser la synchronisation de plusieurs ART.
Chacun de ces niveaux possède son propre objectif dans la fusée SAFe mais avec une articulation identique pour tous : un objectif défini, incluant des rôles, des évènements, des livrables.
“12 Evènements pour l’animer”
Le maintien de l’alignement avec les objectifs stratégiques définis au niveau du portfolio se fait grâce à de nombreux événements répartis par niveau. Chacun a bien évidemment un objectif précis.
Niveau Team
Iteration Planning : Moment où l’Agile Team détermine les objectifs, le nombre de stories et d’enabler de la prochaine itération. La CapEx de l’équipe détermine le nombre de stories de l’itération.
Iteration Review : Inspection et démo de l’incrément à la fin de l’itération, les feedbacks reçus alimentent le Team Backlog.
Iteration Execution : Moment où l’Agile Team développe l’incrément avec une synchro quotidienne de 15 min.
Iteration Retrospective : Se passe en fin d’itération, moment où l’Agile Team examine ses pratiques et cherche des voies d’améliorations
Backlog Refinement : Organisé 1 à 2 fois dans l’itération pour affiner, réviser et estimer les stories, enablers présentes dans le team backlog
Innovation and Planning Iteration : Sert de tampon d’estimation pour la réalisation des PI Objectives et fournit du temps consacré à l’innovation, à la formation continue, PI Planning et Inspect and Adapt events
Niveau Program
PI Planning : Événement de planification, d’une durée de 2 jours, réunissant l’ensemble des acteurs intervenant dans l’ART
System Demo : Présenter l’ensemble des fonctionnalités développées dans la dernière itération par toutes les Agile Teams de l’ART
Inspect & Adapt : Phase d’amélioration continue qui s’appuie sur les feedbacks obtenus lors du System Demo
Niveau Solution Program
Pre- et Post-PI Planning : Phase de préparation et de suivi des résulats de l’ART
Solution Demo : Présenter l’ensemble des fonctionnalités développées par tous les ART qui composent la solution
Inspect & Adapt : Phase d’amélioration continue qui s’appuie sur les feedbacks obtenus lors du Solution Demo
Niveau Portfolio : Aucun
“1 Practice pour souder”
Il y a un élément important qui se situe dans le niveau program mais qui n’est pas décrit comme un événement lui-même. Il s’agit de l’Agile Release Train ou ART. C’est le coeur du niveau program, celui qui soude tous les évènements des niveaux program et team.
Un ART:
regroupe plusieurs équipes travaillant sur une même Itération de PI Planning
cadence la livraison de valeur de l’ensemble des teams qui le composent
délivre la valeur sur le rythme d’itération le plus faible. C’est à dire si une team travaille sur des sprints de 2 semaines et qu’une autre travaille sur des sprints de 3 semaines, le rythme le plus faible est 3 semaines
“13 rôles pour le contrôler”
Pour donner vie et contrôler ce framework, il faut des rôles à incarner. Il y en a 13 définis, répartis sur les différents niveaux de SAFe.
Niveau Team
Agile Team : 5 à 11 personnes (Dev team, PO, et SM) ayant la capacité et l’autorité pour définir, construire et tester une story ou un enabler de la solution dans une itération.
Dev Team : Équipe interfonctionnelle composée de développeurs, de testeurs et autres spécialistes
Product Owner : Responsable de la définition des Stories et de la priorisation du Team Backlog. Est le seul à pouvoir décréter “Done” une Story
Scrum Master : Servant leader et coach, il aide à éliminer les obstacles, facilite les évènements d’équipe
Niveau Program
System Architect / Engineer : Petite équipe interdisciplinaire qui définit l’architecture globale du système, aide à définir les besoins non fonctionnels (NFR), détermine
les principaux éléments et sous-systèmes et aide à concevoir les interfaces et les collaborations entre eux.
Product Management : Représentent la voix interne du client, travaillent avec les clients et les Product Owners pour comprendre et communiquer leurs besoins, définir les caractéristiques du système et participer à la validation. Ils sont responsables du Program Backlog.
Release Train Engineer : Scrum Master pour L’ART. Facilite l’optimisation du flux de valeur à travers le Program en utilisant divers mécanismes, tel que KanBan program, Inspect & Adapt, PI Planning
Business Owner : Stakeholders responsables techniquement et commercialement de l’adéquation au marché et du ROI de la solution développée par un ART
Niveau Solution Program
Customer : Acheteur ultime de la solution. Il intervient comme stakeholder lors du PI Planning
Solution Architect/Engineering : Petite équipe qui définit une vision technique et architecturale commune pour la solution en cours de développement
Solution Management : Voix interne du client qui travaille avec lui pour comprendre les besoins, créer la vision et la feuille de route de la solution, définir les exigences et guider le travail à travers Kanban Solution
Solution Train Engineer : Servant Leader et coach qui facilite et guide le travail de l’ensemble des ART qui composent la solution
Supplier : Organisation interne ou externe qui développe et fournit des composants, des sous systèmes ou services
Niveau Portfolio
Lean Portfolio Management : Groupe de personnes qui organisent et pilotent les portefeuilles d’investissement
Epics Owners : Responsables de coordonner les Epics PortFolia à travers le system Portfolio Kanban
Enterprise Architect : Personne qui aide à fournir l’orientation technique stratégique
“20 artifacts à délivrer”
Un cadre, des niveaux, des events, des rôles mais on délivre quoi ? Une vingtaine d’artefacts sont définis, décrits et répartis eux aussi par niveau
Niveau Team
Story : Véhicule transportant les exigences du client. Utilisé par les équipes pour produire de la valeur au sein d’une itération
Enabler stories : Initiative technique et architecture nécessaires pour réaliser les stories
Iteration goals : Résumé de haut niveau des objectifs commerciaux et techniques que l’équipe agile accepte d’accomplir dans une itération
Team Backlog : Contient les stories et enablers. La majorité est identifiée lors du PI Planning et Backlog refinement
Team PI Objectives : Résumé des objectifs métiers et techniques spécifiques qu’une Agile team souhaite atteindre dans une itération
Niveau Program
Features : Fonctionnalité dont un stakeholder a besoin. Elle contient les hypothèses de bénéfices et les critères d’acceptance. Elle est dimensionnée pour tenir dans un ART
Program Epics : Premier découpage des Business Epics afin qu’elles rentrent sur un seul ART
Program Backlog : Zone d’attente pour les fonctionnalités à vernir. On compte un program backlog par ART
Program Kanban : Gestion du flux des features pour assurer un pipeline de livraison continue
PI Objectives : Résumé des objectifs métiers et techniques spécifiques qu’un ART souhaite atteindre dans le prochain IP
Architectural Runway : Contient le code, les composants et l’infrastructure technique nécessaires pour mettre en œuvre les fonctionnalités
Niveau Large Solution
Capabilities : Ensemble de “haut niveau” qui donnera naissance à des Features et des Enablers qui alimenteront ensuite chacun des ART
Solution Epics : Premier découpage des Business Epics afin qu’elles rentrent sur plusieurs ART
Nonfunctionnal Requirements (NFRs) : Définit les exigences autour de la sécurité, de la fiabilité, de la robustesse, de la performance, etc…
Solution Backlog : Zone d’attente des Capabilities avant leur split pour incorporation dans un ou plusieurs ART
Solution Kanban : Gestion du flux des capabilities pour assurer un pipeline de livraisons continues
Niveau Portfolio
Business Epics : Nouvelle idée business
Enabler Epics : Initiative technique et architecture nécessaires pour réaliser les Business EPICS
Strategic themes : Items qui permettent de faire le lien entre la stratégie d’entreprise et les portefeuilles
Portfolio backlog : Zone d’attente contenant les Business EPICs et Enabler Epics avant leur découpage en Solution Program ou Program
Conclusion
Au vu de la taille exceptionnelle de la documentation, on peut s’interroger sur la priorité donnée à l’efficacité de la méthode. Ma longue lecture d’une bonne partie de la documentation disponible et dont vous avez un résumé au dessus ne m’a pas enlevé l’impression que j’avais à la découverte de la carte de la méthode : “Des processus et des outils plus que les individus et leurs interactions”.
Cette impression subsiste pour plusieurs raisons :
Il y a tellement d’éléments définis pour atteindre l’objectif de l’agilité à l’échelle que cela donne l’impression :
qu’il n’y a aucune latitude pour s’adapter au contexte et à la culture de l’entreprise dans laquelle on souhaite l’implémenter
que l’auto-organisation n’est pas la bienvenue même si elle est maintes fois citée dans le framework
La méthode crée un éloignement entre les clients et les créateurs de valeurs (l'Agile Team) : les product Owners ne semblent pas avoir un accès direct aux clients, ils passent
par les program owners et les EPics Owners :
Les clefs de l’agilité et du DevOps sont donc perdues.
Les clefs du Fast Fail sont aussi perdues : l’agilité a pour vocation d’aider au Fast Fail, puisque rien ne se passe jamais vraiment comme cela devrait. Or avec ses différents
niveaux de délégation, SAFe va freiner le côté fast du Fast Fail, du fait de l’augmentation du temps de traversée des couches entre le développeur et le porteur de l’Epic
concernée. Restera le fail qui sera la responsabilité de l’équipe de développement.
Le time to market pour délivrer reste lent car il faut s’aligner sur la team la plus lente pour livrer un incrément. Or dans une ère numérique où il est important de délivrer vite de la valeur cela peut déranger : on aurait préféré d’autres moyens pour minimiser le time to market, comme par exemple un apprentissage par coaching ou partage de bonnes pratiques, un outillage pour s’en tenir strictement à un maximum de 2 semaines de sprints, etc.
Cette lecture m’a donné l’impression d’un greenwashing des organisations existantes avec la quantité de rôles définis : on prend les organisations existantes dans les grandes
entreprises, celles-là mêmes qui avaient échoué à mener leurs grands projets et s’étaient senties dépossédées de leur rôle avec l’apparition de l’agilité et du management 3.0, on
les tague “SAFe” et hop! elles sont agiles, elles sont à l’échelle, elles sont légitimes.
Au cours de mon expérience professionnelle, j’ai rencontré beaucoup de défauts de la mise à l’échelle, ils sont liés par exemple :
à l’éloignement des acteurs : SAFe n’en tient pas compte
à la gestion de différents environnements entre équipes (backlogs, source repositories, PIC) : SAFe suppose que tout est déjà harmonisé
à la mise en place de Scrum multipliée par autant de Feature Teams : SAFe considère que c’est maîtrisé et vient rajouter un nombre conséquent de rôles et outils qui va complexifier la mise en place, sans nous dire comment choisir si on ne veut implémenter qu’un extrait de la méthode
au cadencement des sprints : SAFe s’aligne sur le moins véloce
au respect du time to market pour délivrer le produit : en plus du point précédent, SAFe met les fonctionnalités dans des trains, en supposant que l’assemblage, via la méthode Kanban, sera satisfaisant
à la recherche de réduction de la complexité : dans un grand nombre de situations que j’ai pu rencontrer, la mise à l’échelle ne devait être qu’un remède, pas une fin en soi. La méthode devrait commencer par cette indication “si vous avez tout tenté pour éviter la mise à l’échelle, nous vous proposons ces quelques pratiques à considérer comme un mal nécessaire”.
Pour finir, comme l’indique le Chaos Report de Standish Group et par mon expérience, les projets les plus vastes sont
ceux qui aboutissent le moins, mais au vu des mots clés qui composent la méthode (Scrum, Lean, Kanban, Scale, Epic, …), vous aurez la garantie d’avoir mis toutes les chances de votre côté grâce à SAFe. Votre management (2.0) ne vous reprochera rien, tout était prévu. Mais est-ce que tout s’est passé comme prévu ?
NDA : Lorsque je me suis plongé dans la gargantuesque documentation de SAFe pour écrire cet article, j’avais déjà un a priori négatif sur ce Framework. J’ai cependant essayé de
retranscrire ici ma compréhension du modèle en tentant de rester impartial.
Safe Map (source : https://www.scaledagileframework.com)