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 : « Bah oui je sais bien, mais comme le dis Dave Thomas « Agile is not what you do, Agile is how you do it« . Je pense qu’on peut détourner 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 vais essayer de donner 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 des cadres agiles sur des groupes plus grand qu’une équipe (un ensemble d’équipes, une entreprise, etc.). L’ensemble de ces cadres se basent sur la brique de base « Scrum » avec plusieurs approches et plusieurs philosophies différentes.

Différenciateur de SAFe(c)

  1. A la différence des autres cadres Agile, 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. Dans cet objectif il propose 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 au niveau des efforts fournis.
  2. SAFe(c) est aussi le seul à proposer une approche bien structurée et claire sur comment une entreprise devrait s’organiser autour des équipes agiles. Sa différentiation fait que pour une entreprise non agile, le chemin de déploiement est clair et précis.

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

Edit Post ‹ Culture Agile — WordPress.com - Google Chrome

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):

Et là pour le coup, 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, ne sont pas des agilistes mais bien souvent des commanditaires. Ces commanditaires sont souvent des personnes qui sont au mieux en cours d’adoption de l’agilité. Ils ont des enjeux et impacts qui sont assez forts et donc veulent prendre le moins de risque possible.

Dans un vieux monde pas encore Agile, le moyen de rassurer  c’est de 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 du type (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 etc.). SAFe(c) permet entre autres de préserver les rôles et la hierarchie déjà en place et permet donc une mise en confiance de cette population. Bien évidemment la réalité est bien plus complexe … et plus le plan est rigide plus il échouera …

Scaled Agile Framework – SAFe for Lean Enterprises - Google Chrome

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

D’ailleurs je ne suis pas sur 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 calcule leur prédictibilité. Cette prédictibilité permet 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) on passe a coté de certaines recommandation forte pour une entreprise Agile :
    • Construire autant que possible des équipes indépendantes qui peuvent gérer leur backlog, développement et livraison de manière autonome.
    • Entreprise plate, avec une simplification de l’entreprise et de 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 lorganisation hierarchique a une structure plus plate)
  • L’approche SAFe(c) vis à vis de l’innovation est très légère. Prétendre que deux semaines « d’Innovation and Planning iteration » sont suffisantes est juste faux. D’ailleurs par la pratique c’est juste un buffer pour finir ce qui a été déjà planifié et non fini pendant les sprints. 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.
  • Un alignement autour des intentions stratégiques qui sont déclinées en Epics, Capabilities et Features. Il ne reste à l’équipe Scrum que d’exécuter ce qui « tombe » dans le backlog du train. On est loin du Product owner qui est proche de ses clients, qui connait son produit et qui adapte son backlog pour être toujours en phase avec les attentes clients. Cette approche de passage de relai entre toutes les couches de l’entreprise fait 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! 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 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 font l’effort de bien structurer leur vision et de la partager avec tout le monde est génial! Ça donne beaucoup plus de visibilité à la contextualisation de ce que font les équipes et ça donne du 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 à venirs 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 retrospective 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 program et portefeuil.
  • 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 bloquage au niveau gestion de portefeuil.
    • la priorisation et la limitation de WIP au niveau Program. La construction de ce backlog priorisé oblige les managers à avoir un alignement global et à résoudre les conflits d’intérêt en amont. La limitation de WIP permet aux équipes d’avoir un focus fort et d’éviter l’effet bourrage papier.

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 difficile à atteindre etc. J’ai mis du temps à comprendre que l’entreprise cherche plus l’alignement et la livraison continue qu’une vraie agilité dans le sens du « 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 de :

  1. vous fixer vos objectifs d’entreprise avec potentiellement une roadmap.
  2. Voir qu’est ce qu’il y a dans SAFe qui vous permette d’atteindre ces objectifs.
  3. Déployez le framework de manière itérative, incrémentales. Ca permettra à l’organisation de comprendre digérer, et adhérer aux demarches d’une part. Et ça vous permettra de jugez de ce qui pertinent avec les retours que vous avez.
  4. Mesurez 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 c’est vos objectifs d’entreprise !

Publicités

Un commentaire

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s