Safe Map (source:https://www.scaledagileframework.com/#)

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:

  1. Adopter une vision économique
  2. Appliquer la pensée systémique
  3. Assumer la variabilité, préserver les options
  4. Construire progressivement avec des cycles d’apprentissage rapides et intégrés
  5. Poser des Jalons permettant de tester et aligner régulièrement le système de travail
  6. Visualiser et limiter les Work in Progress, réduire les tailles de lots et gérer les longueurs de file d’attente
  7. Appliquer une cadence et se synchroniser avec la planification inter-domaine
  8. Déverrouiller la motivation intrinsèque des collaborateurs
  9. 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:

  1. 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.
  2. 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é.
  3. La transparence
  4. 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’appuie sur le leadership

Le deuxième ensemble qui 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 Programmes 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 : Organiser 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 stakeholders 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 personne 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 20 aine d’artefacts sont définis, décrits et répartis eux aussi par niveau

Niveau Team

  • Story : Véhicule transportant les exigences du client. Utiliser par les équipes pour produire de la valeur au sein d’une itération
  • Enabler stories : Initiative technique et architecture nécessaire 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 technique spécifiques qu’une Agile team souhaite atteindre dans une itération

Niveau Program

  • Features : Fonctionnalité dont un stakeholder à 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écessaire 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 même 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 tagge “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 choisir d’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 appriori négatif sur ce Framework. J’ai cependant essayé de retranscrire ici ma compréhension du modèle en tentant de rester impartial.