Pour ou contre l’usage du Scaled Agile Framework (SAFe)?

L’approche agile: une gestion de projet itérative

Les limites des modèles linéaires

Traditionnellement, la plupart des projets de SI étaient gérés avec le modèle en cascade ou le cycle en V.

C’était (c’est …) un modèle linéaire qui conduit à la livraison du logiciel à la toute fin du projet, après avoir traversé successivement les étapes d’analyse des besoins, de conception fonctionnelle et technique, de développement, et enfin de test.

Le problème avec ce type de modèle de gestion de projet est que la réalisation et la livraison du logiciel cible prend beaucoup de temps, car chaque étape ne peut commencer qu’une fois la précédente terminée et validée. De plus, tant que le logiciel est en cours de développement, il n’y a pas de retour terrain de la part des utilisateurs. Et malheureusement, cet effet tunnel révèle souvent très tardivement, voire après la mise en production, l’écart entre le logiciel développé et les besoins métier réels de l’organisation.

L’approche agile: l’adaptation en temps réel

En raison des limites de ce modèle de gestion, les entreprises ont donc commencé à utiliser de plus en plus fréquemment une approche agile. L’approche agile est une manière de développer le logiciel cible en le créant de manière incrémentale depuis le début, c’est-à-dire brique par brique et non d’un seul tenant comme c’est le cas des méthodes traditionnelles.

Dans la configuration agile, on n’attend pas de terminer une phase pour débuter la suivante. Tout d’abord, le délai du projet est fixé. Puis, une fois la date de livraison définie, le logiciel est décomposé en briques plus petites, qui sont priorisées, puis développées et livrées sur des cycles courts de généralement 2 semaines.

L’agilité a de nombreux avantages pour le client, dont notamment :

• La livraison de fonctionnalités ayant une haute valeur ajoutée
• La focalisation sur la satisfaction du client
• La suppression de l’effet tunnel grâce aux livraisons fréquentes

>> Lire aussi : Marre des pseudo-projets agiles !

Les limites des approches agiles du type SCRUM

Au fur et à mesure de son utilisation, les Organisations se sont rendu compte que les approches agiles fonctionnaient bien lorsque l’équipe projet était relativement petite, c’est-à-dire comprise entre 7 et 10 personnes.

Au-delà, et particulièrement pour les gros projets composés de multiples équipes agiles, l’efficacité et la performance tendait à chuter.

En effet, les gros projets ont de nombreux défis supplémentaires auxquels ils doivent faire face :

• Une planification sur un temps beaucoup plus long
• Le manque de formation du Top Management aux pratiques agiles
• Pas de coordination entre les différentes Scrum Teams, qui ne sont pas non plus connectées autour d’un objectif commun
• Nécessité de faire preuve d’un esprit d’innovation
• Existence de multiples sources d’exigences provenant de nombreuses équipes Scrum
• Manque de visibilité des dépendances et interconnexions entre les périmètres des équipes Scrum, ce qui génère des problèmes et obstacles non prévus
• Difficulté pour piloter et gérer de manière agile un très grand nombre de personnes devant travailler ensemble
• Ou encore, de trop nombreuses sources de besoins métier

L’émergence de modèle d’agilité à grande échelle

Il fallait donc inventer un modèle agile qui puisse être appliqué à plus grande échelle.

Un certain nombre de cadres méthodologiques a donc vu le jour, comme ceux-ci :

• Scaled Agile Framework (SAFe)
• Large-Scale Scrum (LeSS)
• Disciplined Agile Delivery (DAD)
• Nexus
• Spotify Model
• Scrum at Scale

Au jour où j’écris cet article, le modèle qui s’est le plus répandu dans les organisations est le Scaled Agile Framework (SAFe).

>> Lire aussi : 😱 Business Analysts : faut-il avoir peur du grand méchant SAFe ?

Le Scaled Agile Framework (SAFe)

Créé par Dean Leffingwell, c’est un cadre méthodologique de développement à l’échelle de l’Organisation. Il combine les principes déjà connu en Lean management et en agile, dont il utilise les socles de connaissances que sont le développement logiciel agile, le développement de produit « lean » et la pensée systémique.

Les 4 valeurs de SAFe

Ses valeurs fondamentales sont :

• Alignement : SAFe exige que les entreprises mettent en place des cadences de planification et de réflexion à tous niveaux organisationnels, et qu’elles soient en phase avec la vision stratégique et les objectifs opérationnels de l’organisation.
• Qualité intégrée : chaque « morceau » du produit final doit respecter les standards de qualité du produit dans son ensemble.
• Transparence : SAFe encourage les comportements qui renforcent la confiance, notamment entre le « métier » et les équipes de développement
• Exécution du programme : il s’agit de soutenir toutes les autres valeurs de SAFe, pour sécuriser la livraison d’un service de qualité, des logiciels fonctionnels et l’apport d’une valeur métier.
• Direction : SAFe exige en outre un comportement de leadership Lean/Agile, car seuls les dirigeants peuvent transformer le système et créer l’environnement nécessaire pour inclure toutes les valeurs fondamentales.

Les 9 principes SAFe

SAFe se fonde en outre sur 9 principes clés, destinés à améliorer l’entreprise dans son ensemble et de dépasser les silos organisationnels :

• Adopter une vision économique
• Appliquer une pensée systémique
• Accepter le changement et préparer ses alternatives
• Construire la solution logicielle de manière incrémentale, à l’aide de cycles d’apprentissage rapides et intégrés
• Baser les jalons sur une évaluation objective des systèmes de travail
• Visualiser et limiter le travail en cours, réduire les tailles des lots, et gérer la longueur de la file d’attente
• Faire appliquer la cadence, synchroniser la planification transverse
• Susciter la motivation et libérer le potentiel des équipes
• Décentraliser la prise de décision

Les 4 niveaux d’application du cadre méthodologique SAFe

Il y a 4 niveaux d’application de SAFe dans l’Organisation : Team, Program, Value Stream et Portfolio.

Chacun d’entre eux implique une taille d’équipe, une planification, des objectifs, rôles, activités et artefacts spécifiques, et veillent à appliquer les valeurs et principes SAFe.

Je ne m’étendrai pas davantage sur ce qu’est SAFe, car il y a déjà de nombreuses sources d’information sur internet, donc le site officiel du Scaled Agile Framework qui est très complet.

>> Lire aussi: Design Thinking, Lean Startup et Agile : quelle est la différence ?

Avantages et inconvénients de SAFe

La question qu’on peut se poser arrive tout naturellement, lorsqu’on prend un peu de recul sur les nombreuses méthodes de gestion de projet qui n’ont cessé de naître puis d’être remplacées par de nouvelles : peut-on affirmer cette fois-ci que, ça y est, on a trouvé le Sésame pour résoudre tous les problèmes de développement logiciel?

Les avantages du Scaled Agile Framework

Il existe en effet de nombreux avantage à mettre en pratique SAFe, les plus reconnus étant les suivants :

• Aide des équipes cross-fonctionnelles à collaborer efficacement
• Convient parfaitement aux entreprises qui sont déjà organisées de manière agile ou qui souhaitent mettre en place cette organisation
• Permet de déployer au niveau de l’Entreprise des approches agiles qui mettent la valeur apportée aux utilisateurs
• Met l’accent sur les gens plus que sur la technologie — c’est d’ailleurs l’une des raisons qui a rendu SAFe si rapidement populaire. Il y avait en effet une véritable attente de placer la confiance entre le « métier » et les équipes techniques au cœur du développement logiciel, plutôt que de systématiquement les opposer.

Les inconvénients du Scaled Agile Framework

Mais évidemment, la baguette magique n’existe pas encore.

• Premier inconvénient : SAFe se base trop sur une approche « top – down ». Cette approche Top-Down est initiée par une vision stratégique au niveau du Top Level Management, qui est ensuite décomposée en objectifs opérationnels et sous-objectifs et transmise à la base opérationnelle.

  Or l’application de SAFe est strictement encadrée par des règles qui laissent peu de place à la personnalisation au niveau des entités opérationnelles de l’Organisation. Et ceci, quand bien même il y aurait de nombreuses disparités entre Business Units, ce qui est fréquent dans les grandes structures (pour lesquelles le framework SAFe a pourtant initialement été pensé).

• Ensuite, les différentes couches SAFe dédiées aux activités d’administration et de coordination des « trains SAFe » (ART, soit Agile Release Train) les font finalement ressembler à une organisation projet traditionnelle de type cascade. Les méthodologies comme SCRUM donnent davantage de liberté aux équipes de développement pour identifier et résoudre les problèmes qui se présentent en cours de route, en raison de la cadence des sprints et des dépendances par exemple. Le cadre strict des trains SAFe limite la flexibilité que l’on a dans SCRUM, et contribue à ralentir le processus de développement global.
• Enfin, autre inconvénient, SAFe met en avant la « big picture », la photo globale / la vision, ce qui conduit souvent à allonger les cycles de panification et à créer des rôles plus figés à l’intérieur des cycles de développement. Cela va à l’encontre de l’objectif de livraison en cycles courts (les sprints) pour réduire le Time-To-Market.

>> Lire aussi : Pourquoi 83% des projets échouent-ils?

Il appartient donc aux Organisations qui choisissent d’implémenter le Scaled Agile Framework d’identifier et d’éliminer les risques associés aux inconvénients cités ci-dessus, afin de tirer le maximum de profit de cette approche.

Sources : Scaled Agile Framework, Atlassian, edureka!