Un monde peut sembler séparer les intentions « soft-power » du Manifeste Agile et le marketing hégémonique qui a fait de Scaled Agile et de sa méthodologie SAFe le « modèle à l’échelle le plus usité au monde », et ce d’autant que si le premier s’adresse plutôt aux équipes, l’autre se tourne résolument vers les comités de direction.
Praticien de l’agilité depuis quelques années, observant SAFe dans un environnement qui avance vers l’agilité, j’ai eu l’occasion de passer la certification SPC (SAFe Program Consultant) et je souhaite vous partager mes réflexions sur le sujet.
Au démarrage, ça ne part pas trop bien …
Inutile de le nier ; SAFe se conçoit comme une « boîte à outils de formation» qui base son modèle économique sur le déploiement par la formation de son système sur l’ensemble de l’organisation. Dans une mécanique semblable à celle des certifications classiques (Prince, CMMI, 6 sigma, ITIL, etc.), elle a pour approche de former toute l’organisation à son mode de réflexion, en s’appuyant sur le modalité classique du changement : le sens de l’urgence, une transformation radicale « en une semaine », etc…
Cette propension hégémonique apporte une sécurité (ou un sentiment de sécurité) aux donneurs d’ordre des transformations et une promesse d’une efficacité « éprouvée » par d’autres grands donneurs d’ordre. Nobody ever got fired buying IBM.
Mais, à priori rien de très agile dans tout ça !
Pourtant, vite, quelques bonnes surprises !
Ma première (bonne) surprise a été de voir que mes comparses de formation SPC (SAFe Program Consultant) étaient tous (et toutes pour 10% de la promotion) des praticiens de modèles d’agilité à une échelle qui dépasse celle de l'équipe. Et également que les deux formateurs anglais étaient des experts aguerris de SAFe avec plusieurs dizaines de programmes déployés dans de nombreux pays d’Europe.
Deuxième bonne surprise : si la formation fait souvent référence au canevas SAFe, conçu comme une carte heuristique cliquable qui permet de concentrer une large quantité d’information et de concepts sur un schéma (ici), il faut également reconnaitre qu’elle s’appuie très largement sur les fondamentaux du Manifeste Agile et sur les apports de fond du Lean Management (Toyota).
Et les concepts Lean-Agile ne sont pas là pour faire « jolis » ; ils sont au coeur des dispositifs et des promesses d’atteinte de résultats. Comme le rabâchent les différentes formations : sans le socle lean-agile, SAFe ne fonctionnera pas !
Troisième bonne surprise : SAFe prend en compte dans les grands projets, ce qu’on peut appeler « l’étage supérieur » de la prise de décision et ce de manière sensée et applicable ; par le jeu de l’analyse des « courants de valeurs » (value streams) qui viennent répondre aux besoins des clients, les donneurs d’ordre (stakeholders), peuvent facilement prioriser les fonctionalités (features) qui peuvent être amalgamés en solutions de haut niveau (capabilities). Ce système de priorisation par et pour les stakeholders, en utilisant comme métrique de décision la création de valeur pour l’utilisateur final, s’applique aussi bien au niveau des équipes, que de celui d’un programme, ou plus largement de l’organisation.
La priorisation (budgétaire) est en effet l’enjeu clé de la distribution des ressources, avec dans le monde classique, un top-management qui « exige » des études précises prédictives exactes [donc fausses dans 80% des cas] pour prendre des décisions qui constitueront une road-map stricte [et intenable], garantie de créer frustration et défiance pendant toute la durée [glissante] du projet.
L’agilité de SAFe repose donc sur la possibilité de porter des positions à long terme avec des décisions qui sont renouvelées fréquemment pour s’adapter aux évolutions du marché. Et ça, c’est plutôt agile !
SAFe offre un mix entre de l’organisation et de l’auto-organisation des équipes en limitant dans le temps les impacts de décision et donc en permettant de s’adapter en continue grâce aux apprentissages réalisés dans les itérations.
Bien sûr, comme tout framework ou outil il peut être utilisé avec un degré plus ou moins marqué d’agilité, voire être dévoyé par son utilisation limitée à l’usage de mots-clés qui servent de paravent. On réuni 6 équipes pendant une demi-journée ? Et hop ! Voilà un PI ! On fait une priorisation (mais pilotée par les enjeux politiques de stakeholders qui ne se parlent pas) ? Et hop ! Voilà un backlog. On ne suit pas la démarche SAFe ? « Et bien... c’est ça, être agile : c’est d’adapter les règles ! » (Soupirs...)
Il y a donc un risque avéré dans SAFe ; celui de rajouter une couche organisationnelle inutile à celles qui peuvent déjà être présentes. Les managers deviennent des PO, mais continuent à se comporter comme des managers ; les PM restent des directeurs de projets, etc.
Ce qui revient à n’en appliquer que les critères non contraignants plutôt que d’utiliser les critères contraignants pour « inciter » (permission/protection) l’organisation à pivoter du pilotage par les budgets vers le pilotage par la valeur. Et donc de rater ce qui est l'injonction à mon avis majeure de SAFe : « Stop chasing the money, chase the value ».
Une des difficultés du modèle réside chez nous dans la nécessaire formation de tous les acteurs. En ce sens, SAFe arrive d’outre-atlantique avec des modes de déploiement qui y sont culturellement applicables (tout le monde doit être formé avant de rentrer dans les fameux « trains »). Tandis que dans l’Hexagone, les choses ne se passent pas toujours de cette façon. La formation ? Mais on n’a pas le temps ; on est déjà tellement débordés!
SAFe est un outil dont on peut bien ou mal se servir (cf. l’analogie du marteau) et n’est certainement pas l’unique façon de promouvoir le déploiement du mindset lean-agile dans une organisation. Pour autant, je pense que ce serait une erreur de le ranger d'office dans la liste des modèles qui empêcheraient le déploiement des valeurs agiles.
Son principal avantage est aussi son principal problème ; parce qu’il parle un langage intelligible par les grandes organisations, il peut être facilement tordu en un système pyramidal qui reproduit les difficultés organisationnelles plutôt que d’aider à les résoudre. Pour autant, en introduisant les questions d’itération, de priorisation, de valeur délivrée, il pose aussi petit à petit les éléments culturels qui vont aider les organisations à se renouveler.
Oui, SAFe peut donner l’illusion d’une alternative à un process classique et être utilisé comme tel. Mais la frustration qu’il produit alors peut aider à rendre visibles les irritants de fond. Et voila déjà un point de départ à un chemin… dont la suite se poursuivra (ou pas) dans la mise en application de comportements agiles : transparence, humilité, inspection, courage, focus... Et on ne touche plus des questions de framework, mais à celles des valeurs permises et déployées dans l’organisation.
SAFe ? A l’image des autres « frameworks », il n'est utile que s’il rend possible l’expérimentation et le déploiement de nouvelles régulations qui vont conduire à des dynamiques d’entreprises renouvelées. Il me semble donc que sa bonne utilisation soit celle d’un cadre d’apprenance... ce qui suppose à minima que les enjeux de fond de cette apprenance soient compris et partagés auprès des acteurs!
Ce qui ne va pas tant de soi quand on constate l'actuel manque de fond et de sens des transformations dites agiles. La formation et la posture des coach agiles participent à ce débat... Un sujet qui fera sans doute l'objet d'un prochain billet, en poursuite de la réflexion entamée sur ce sujet par Christophe Keromen dans ce bel article et en résonance, entre autres, à l'ouvrage de référence sur le coaching de Reine-Marie Halbout "Savoir être coach".
* définition perso de l'agile = une démarche globale d’entreprise destinée à des environnements complexes, orientée vers la création de valeur pour le client par l’émergence de pratiques d'équipes pluri-disciplinaires et auto-organisées, dans des visées itératives, adaptatives et incrémentales.