6 mois de SAFe (c), ce que j'en retiens ?

Un ami : "Sami, tu es fou !! Tu vas bosser dans une transformation SAFe(c), toi l'agiliste !! Mais tu as lu l'article de Ken Schwaber ? Tu as vu la gueule du truc ?"

Moi : "Comme le dis Dave Thomas "Agile is not what you do, Agile is how you do it". Je pense qu'on peut utiliser un outil comme SAFe(c) et faire de l'Agile avec ... Je tente ma chance et on verra."

Non, je ne vais pas cracher sur SAFe(c) comme certains l'ont fait. Non, je ne fais pas un rejet en bloc de l'approche proposée. En me basant sur une expérience de 6 mois de SAFe(c), je vous propose mon analyse de la chose.

Qu'est ce que SAFe (c) ?

SAFe(c) est l'un des framework Agile à grande échelle, avec LeSS, Nexus, DAD, Spotify model, etc. L'objectif de ces frameworks est de proposer un cadre agile à des groupes plus grands qu'une équipe (un ensemble d'équipes, une entreprise). Ces cadres se basent sur la brique de base "Scrum" avec des approches et philosophies différentes.

Différenciants de SAFe(c)

1. A la différence des autres, SAFe(c) à l'ambition (forte) d'attaquer l'organisation globale de l'entreprise autour des équipes Scrum. A tort ou à raison, il propose une approche qui permet à toute l'entreprise de travailler dans un mode Lean/Agile. Un des grands objectifs affichés de SAFe(c), c'est l'alignement de l'entreprise. Il propose donc une approche qui permet à l'entreprise de s'assurer que les équipes travaillent sur ce qui compte, de haut en bas, et qu'il n'y ait pas de dispersion des efforts fournis.
2. SAFe(c) propose aussi une approche bien structurée et claire sur comment une entreprise devrait s'organiser autour des équipes agiles. Pour une entreprise non agile, le chemin de déploiement semble clair et précis.

Qu'est ce qui fait le succès de SAFe(c) ?

Un petit comparatif Google Trends entre les recherches "LeSS agile" et "SAFe Agile" sur les quatre dernières années montre bien une tendance de plus en plus forte d'adoption de SAFe(c) comparé aux autres frameworks plus ou moins connus. Pour moi, deux raisons essentielles font la popularité de SAFe(c) :

1/ SAFe(c) est rassurant (vu qu'il est safe):

Là, les créateurs de SAFe(c) ont mieux cerné les utilisateurs potentiels, leurs besoins et comment bien leur vendre le produit : ceux qui font les choix des cadres Agiles à adopter sont rarement des agilistes mais plutôt des commanditaires au mieux en cours d'adoption de l'agilité. Leur enjeu est souvent de prendre le moins de risques possible.

Dans un monde pas encore Agile, le moyen de rassurer consiste à fournir un plan bien détaillé et bien étudié (du moins en apparence). SAFe leur fournit un plan qui répond à beaucoup de questionnements et d'incertitudes dans l'entreprise (que deviennent mes managers, quelle est la roadmap de déploiement, comment je mesure mon succès, comment je gère les dépendances, comment je gère les budgets...). SAFe(c) permet entre autres de préserver les rôles et la hiérarchie déjà en place et donc une mise en confiance de cette population. Bien sûr, la réalité est plus complexe : moins le plan est Agile, plus il a de chances d'échouer...

2/ SAFe (c) ne traite pas que d'agilité

En fait, je ne suis pas sûr que l'agilité y soit bien prise en compte. De mon point de vue, SAFe est surtout un framework d'alignement et de prédictibilité. Il permet à l'entreprise de travailler sur les mêmes objectifs, avec la même vision.  Ceci est fait via les différentes couches proposées, avec leurs différents backlogs. Ces différentes couches sont essentiellement liées grâce aux éléments de leurs backlogs respectifs (Epic, Feature, US).

SAFe permet aussi d'avoir une meilleure prédictibilité au niveau de la production. Les équipes font un grand planning en commun tous les deux mois, s'engagent dessus. A la fin de cette itération, on mesure la production des équipes et on évalue leur prédictibilité. Cette prédictibilité permettrait de créer plus de confiance et d’honnêteté sur les engagements dans l'entreprise.

Alignement et prédictibilité ... mais à quel prix ?

Les risques d'un déploiement SAFe

• En déployant SAFe(c), les entreprises peuvent passer à côté de certaines recommandations fortes pour une entreprise en quête d'Agilité :
  • Construire autant que possible des équipes indépendantes qui peuvent gérer leur backlog, développement et livraison de manière autonome.
  • Simplifier l'entreprise et sa structure afin d'avoir une meilleure collaboration et alléger le poids de la hiérarchie. Ceci permet entre autres de libérer l’esprit d'initiative et l'autonomie des équipes (un bon article à lire de l'organisation hiérarchique à une structure plus plate).
• L'approche SAFe(c) vis-à-vis de l'innovation est très légère : SAFe(c) propose une itération de "Innovation and Planning" (appelée IP) à la fin de chaque incrément (tous les 2 à 3 mois). Prétendre que deux semaines "d'Innovation and Planning" sont suffisantes est juste faux. En pratique, c'est juste un buffer pour finir ce qui a été déjà planifié et non terminé pendant les sprints précédents. L'innovation est plutôt une culture d'entreprise et une démarche continue qui se reflète sur l'ensemble du fonctionnement de l'entreprise.

• SAFe propose un alignement autour des intentions stratégiques qui sont déclinées en Epics, Capabilities et Features (voir schémas au dessus). Il ne reste à l'équipe Scrum qu'à exécuter ce qui "tombe" dans le backlog du train. On est loin du Product Owner proche de ses clients, qui connaît son produit et adapte son backlog pour être toujours en phase avec les attentes. Cette approche de passage de relai entre toutes les couches de l'entreprise induit que les équipes s'éloignent du contexte et engendre une perte d'information considérable entre l'intention première et l’exécution finale. Le risque est limité grâce aux démos et revues, mais il est là.
• Beaucoup trop d'artefacts et d'outils! SAFe tente de régler tous les problèmes en même temps. En déployant SAFe on est tenté de prendre le tout sans ce soucier de l'objectif initial de l'entreprise. Et ceci résulte en beaucoup d'artefacts et d'outils qui peuvent vous être inutiles et nuisibles. Ces artefacts "inutiles" peuvent résulter en un retour sur investissement pauvre et un désengagement de vos équipes quand ils ne voient pas l’intérêt de ce qu'ils font.

Qu'est ce que je retiens de SAFe(c) ?

• Certains aspects du PI planning :

  • Un alignement sur la vision de l'entreprise, la roadmap pour atteindre les objectifs business. Que les managers prennent le temps et fassent l'effort de bien structurer leur vision et de la partager avec tout le monde est génial ! Ça donne beaucoup plus de visibilité, de contexte et de sens à ce que les gens font, élément très fort pour la motivation des troupes.
  • La collaboration de toute la structure du train (BO, PM, architectes, équipes) autour de la construction d'un plan pour les deux mois à venir avec un engagement commun sur les objectifs à atteindre et des discussions très riches.
  • L'identification des dépendances entre équipes et avec le monde extérieur. L'identification des risques et leur partage avec la globalité du train. Ceci constitue un très bon partage des responsabilités et permet aux managers de trouver des éléments concrets pour supporter et aider les équipes.

• L'Inspect & Adapt :

  • Les PI démos : Il est intéressant d'avoir une fois tous les deux mois une "grande démo" avec un grand public et dans laquelle on montre ce qui a été fait sur les dernières itérations. J'ai essayé dans le passé d'inviter du monde pour les sprint démos, mais la fréquence trop forte multipliée par le nombre d'équipes fait que ça devient rapidement trop complexe à gérer. L'idée içi, c'est de démontrer la résultante du travail de toutes les équipes en collaboration. Cette cérémonie renforce l'idée qu'on travaille pour des objectifs communs en collaboration.

• La rétrospective niveau train qui permet de tacler des problèmes à un niveau plus haut que celui des équipes et qui contribuent à une amélioration continue de l'écosystème dans sa globalité incluant les couches programme et portefeuille.

• La vision lean de l'entreprise :

  • Le lean budgetting peut aussi être interessant dans certains contexte (budget time & materials sur des cadences de deux/trois mois). Ca permet d'avoir une certaine stabilité au niveau des équipes et des objectifs à atteindre sur une certaine période. C'est surtout utile pour les entreprises qui ont de forts bloquages au niveau gestion de portefeuil.
  • la priorisation et la limitation de WIP au niveau Program et au dessus. SAFe propose d'utiliser l'outil Kanban pour la gestion du Program. Un des principes de cette approche, c'est de limiter le nombre d'élements sur lesquels on travaille pour avoir un meilleur focus. D'autre part, la construction de ce backlog priorisé oblige les managers à avoir un alignement global et à résoudre les conflits d’intérêt en amont.

Pour finir...

Personnellement, j'ai eu beaucoup de mal avec SAFe(c). Je m'attendais à travailler avec des équipes auto-organisées qui co-construisent une meilleure manière de faire, et je me suis retrouvé avec un framework assez lourd et limitant en terme d'autonomie. La culture entreprise n'a pas aidé non plus, car au dessus de SAFe(c) l'entreprise a rajouté sa couche de "recommandations" obligatoires avec des quotas pour la maintenance, des métriques à utiliser, une "corporate DoD" (Definition of Done, du "Terminé" commune à l'entreprise) difficile à atteindre. J'ai mis du temps à comprendre que l'entreprise cherchait plus l'alignement et la livraison continue qu'une vraie agilité dans le sens de l'"Agile Manifesto".

Je précise quand même qu'il y a beaucoup d'utilité dans SAFe et c'est la manière dont vous allez l'utiliser qui peut faire la différence. La bonne démarche serait selon moi de :

1. vous fixer vos objectifs d'entreprise avec potentiellement une roadmap.
2. voir dans SAFe ce qui vous permet d'atteindre ces objectifs.
3. déployer le framework de manière itérative, incrémentale. Cela permettra à l'organisation de comprendre, digérer, et adhérer aux démarches. Et ça vous permettra de juger de ce qui pertinent avec les retours que vous avez.
4. mesurer votre avancement. Ces mesures ne doivent en aucun cas être focalisées sur le framework lui-même (quels rituels, combien de personnes, etc.). Ce qui est à mesurer, ce sont vos objectifs d'entreprise !

Post Original : https://cultureetagilite.wordpress.com/2018/01/24/6-mois-de-safe-c-ce-que-jen-pense/