Le résultat est net et sans appel : face à un des meilleurs effectifs du monde, les « bleues » n’ont pas réussi à renverser le rapport de force. Il est vrai qu’à l’inverse de leurs homologues masculins, il manquait probablement un peu de profondeur d’effectif pour espérer être championnes du monde. Mais concentrons-nous sur le sujet évoqué plus haut : quel type de management a mis en place Corinne Diacre ?
Bâtir un groupe plus qu’une somme d’individualités
Commençons par le commencement : la constitution du groupe. Comme nombre de ses homologues, Corinne Diacre s’est attachée à bâtir le meilleur groupe possible pour une aventure de vie commune qui dure plusieurs semaines. Elle n’a d’ailleurs pas hésité à écarter une individualité talentueuse (Katoto), meilleure buteuse du championnat français, mais qui selon elle se promenait de façon dilettante à l’entrainement. On peut avoir un avis sur ce choix, mais force est de reconnaitre que la vie du groupe avait une importance primordiale pour Diacre.
Transmettre, animer et faire grandir les individualités
Corinne Diacre est une grande championne, capitaine de l’équipe de France de football pendant plusieurs années, elle est la première figure à se faire un nom dans un monde du football tourné vers les performances athlétiques des hommes. Son expérience de joueuse de haut niveau et ses compétences lui ont permis d’embrasser une carrière d’entraineure avec succès. Première entraineure à prendre en charge une équipe professionnelle à Clermont (techniquement deuxième mais sa prédécesseur a jeté l’éponge au bout de quelques jours), elle obtient des résultats plus que satisfaisants. C’est donc tout naturellement qu’elle est appelée à la tête des bleues il y a 2 ans. Le propre d’un leader étant de transmettre, l’expérience de Corinne Diacre permet d’aborder cette coupe du monde à domicile avec calme et sérénité, alors que l’on sait qu’une telle compétition à domicile amène beaucoup de pression. La séléctionneure s’appuie sur un schéma tactique assez classique en 4-2-3-1 qui n’évolue pas beaucoup au fil des matchs. Elle s’appuie surtout sur les qualités individuelles de ses joueuses : Gaetane Thiney a les clés du jeu au milieu de terrain, Eugénie Le Sommer doit provoquer devant, tout comme Kadidiatou Diany, Amandine Henry récupère des ballons et oriente le jeu, Wendy Renard impose sa vista en défense et monte mettre sa tête sur les coups de pieds arrêtés.
L’animation autour de ce plan de jeu fonctionne bien. On s’appuie sur les points forts de chacune et le résultat du premier match est probant : 4-0 contre la République de Corée.
L’échec
Les matchs s’enchainent avec des victoires et les bleues se qualifient en 1/4 de finale après un match très compliqué contre les brésiliennes. Ce match a déjà montré les limites de cette équipe qui seront encore visibles lors de cette élimination contre les Etats-Unis : le groupe a du mal à franchir des paliers au fur et à mesure que la compétition s’intensifie. L’équipe de France est éliminée contre une équipe qui semble plus mature, plus capable de s’adapter aux situations, plus à l’aise.
Les raisons de l’échec sont-elles à chercher dans le style de management ?
Plusieurs articles de presse ont remonté des informations sur le style de management de Corinne Diacre, sa potentielle froideur, son détachement, son manque de flexibilité. Certains parlent même de management par la terreur. S’il est compliqué de se faire une idée, on peut tout de même interpréter certains signaux. Lorsque l’on regarde les matchs des bleues, on voit peu de folie, peu de prise d’initiative, peu de discussion sur le terrain à propos des faiblesses et points forts sur l’adversaire, le plan de jeu. Bref, aucun signe que cette équipe est prête à dépasser les codes, à sortir de son cadre, de sa zone de confort.
Corinne Diacre est décrite comme quelqu’un qui « donne de la liberté à l’intérieur d’un cadre ». Le problème est que parfois le cadre est trop resserré. La force d’un grand leader est de réussir à embarquer un groupe autour d’un objectif commun qui les transcende. Nul doute que toutes ces joueuses désiraient plus que tout gagner cette coupe du monde à domicile. Mais pour y parvenir, la force du collectif est nécessaire et la capacité à se dépasser indispensable. Tout porte à croire que le style de management de Corinne Diacre a amené chaque joueuse à remplir son rôle, avec toute leur énergie et leur motivation. Ce qu’elle n’a pas réussi à faire c’est de construire un groupe qui a le désir de se transcender. La confiance transmise par le leader (la coach de cette équipe) n’a pas été suffisamment dirigée vers ce rêve absolu, cette vision.
Si tu veux construire un bateau, ne rassemble pas tes hommes et femmes pour leur donner des ordres, pour expliquer chaque détail, pour leur dire où trouver chaque chose… Si tu veux construire un bateau, fais naître dans le cœur de tes hommes et femmes le désir de la mer.
A. de Saint Exupéry
Give Control and Create Leaders
David Marquet
Il faut changer la manière de manager
La force d’un leader réside dans sa capacité à mettre en avant les forces de son groupe, leur donner de la confiance et de la liberté, libérer les énergies et les initiatives, et accompagner les leaders émergents. On parle d’ailleurs maintenant plus facilement de leadership que de management. Un management trop directif, ou trop basé sur la peur, l’effort individuel, est de moins en moins adapté à notre monde et de moins en moins rencontré dans les grandes réussites, qu’elles soient sportives ou en entreprise. Si vous êtes manager, n’hésitez pas à prendre du recul par rapport à ces situations au quotidien, tirez-en des enseignements et lancez des expérimentations dans vos équipes. Si vous n’êtes pas manager, faites la même chose et parlez-en avec votre manager à la machine à café. On a tous un rôle à jouer dans la transformation de la posture managériale.
AG2R LA MONDIALE est un acteur majeur de la Protection Sociale. Au sein de la Direction de l’Organisation et des Systèmes d’information, une équipe travaillant en mode agile (Scrum) reçoit de très nombreuses demandes d’évolution du produit en cours de développement. Ces demandes viennent de différents sites en France et arrivent en ordre dispersé. Pour mieux satisfaire ses clients internes, AG2R LA MONDIALE a ressenti le besoin de se faire accompagner pour rendre le processus complet d’évolution du produit plus agile et efficient, tant d’un point de vue qualification et priorisation de la demande, que d’un point de vue structuration du delivery par rapport à la valeur apportée.
Solution
Définition des rôles et responsabilités à l’aide d’une matrice Give & Take ayant pour objectif un alignement des attentes respectives et une plus grande efficacité collective
Facilitation à la mise en place de pratiques agiles (Scrum et Safe)
Priorisation par la valeur métier des besoins des parties prenantes et gestion de l’en-cours afin d’éviter l’étranglement de l’équipe de développement
Travail de redéfinition du backlog avec une réorientation de l’expression des besoins sous un angle plus fonctionnel que technique
Formation des rôles piliers de Product Owner et de Scrum master aux subtilités de leurs métiers
Facilitation des rétrospectives dans une démarche effective d‘amélioration continue et à l‘aide de formats variés pour motiver et encourager l‘équipe
Mise en place d‘ateliers de synchronisation entre les parties prenantes et l‘équipe de développement dans un but de clarification et de compréhension des besoins.
Bénéfices
Une meilleure fluidité des demandes et de leurs réalisations (réduction du time-to-market)
Diminution de la frustration des parties prenantes en attente des livraisons
Meilleur ROI des fonctionnalités produites
Revalorisation de l’utilisation du produit développé par l‘équipe
Les autres success stories qui peuvent vous intéresser
Concurrence, (r)évolution technologique, transition écologique, cybersécurité : autant de facteurs de changements fréquents dans les priorités stratégiques et les besoins adressés aux DSI. Dès lors, celles-ci doivent être capables de s’adapter en permanence à ces changements, et aussi d’anticiper ceux auxquels ses parties prenantes feront face dans le futur. L’agilité est une piste sérieuse pour réussir ces challenges, sans être forcément une réponse unique à tous les problèmes.
Au fond les entreprises ne cherchent pas à être agiles par plaisir, mais pour améliorer leur niveau de performance.
Chez Rhapsodies Conseil, notre équipe vous accompagne à maximiser les chances de réussite de vos transformations en :
établissant avec vous dès le départ des critères de réussite factuels et mesurables
bâtissant une approche adaptée à votre contexte
s’inspirant des framework mais pas en les déployant sans réfléchir
intégrant les équipes dés le début dans la co-construction
les menant de manière agile : avec une approche itérative rythmée par des saisons de 4 à 6 semaines
vous faisant bénéficier de l’intelligence collective de l’ensemble de notre équipe de consultants, coach agiles et/ou coachs professionnels
Notre accompagnement sur-mesure, issu de l’intelligence collective de l’ensemble de nos consultants coachs, est basé sur plusieurs convictions : il n’y a pas de modèle d’agilité qui fonctionne pour tout le monde, il doit être adapté à votre contexte, co-construit avec vous et ceci de manière agile.
C’est de prime abord le constat qu’on ferait. Tout commençait si bien (autrement dit « comme les années précédentes ») avant un chamboulement inédit. Cette pandémie a bousculé notre quotidien du jour au lendemain et par la même occasion nos habitudes.
Maintenant que le confinement est derrière nous, dressons un portrait des pratiques d’organisation qui ont émergé.
Le télétravail pour tous et tous pour le télétravail ?
Le COVID-19 est incontestablement le Chief Digital Officer de la décennie. Avec une généralisation du télétravail effective du (quasi) jour au lendemain pour des centaines de milliers de personnes : l’impact a été énorme et brutal.
Cette (r)évolution du télétravail a suscité un réel engouement au démarrage par l’effet nouveauté qu’il apportait.
Engouement à tempérer car nous n’étions pas tous égaux :
Certains ont bien vécu la transition (coucou la maison de campagne et au revoir les 2h de RER quotidien)
D’autres beaucoup moins (bonjour les enfants à gérer ou l’appartement de 15m2 sous les toits de Paris)
Il n’empêche que l’avancée vers le télétravail a fait un bond en avant de plusieurs années. Au final, il s’est fait sans trop de casse – même pour des métiers dits « critiques ». Et cette transition s’est faite naturellement dans la majorité des cas.
Dans le monde de demain, le télétravail sera bien plus démocratisé et toléré même si une présence minimale (variant d’une entreprise à l’autre) sera attendue. Un changement qui remet en cause la taille des locaux (donc leur prix), leur utilisation mais également la nature des relations entre collègues.
Vers la fin des déplacements ?
Le télétravail a vu l’explosion de la visio. Pour illustration, à l’heure où j’écris ces lignes, Zoom (solution de visio) est valorisée à hauteur de $82Mds en croissance de 425% depuis le début de l’année. Impressionnant.
Les solutions de visio sont dorénavant matures et nombreuses (Zoom, Meet, Teams, Slack, WhereBy, …) avec une latence permettant des conversations (quasi) fluides : merci la fibre. Et de nombreuses solutions permettent de mener des ateliers de travail à distance avec efficacité (Klaxoon, Miro, …).
L’enseignement à en tirer : finalement tous ces déplacements d’hier – et fatigue et donc, par rebond, productivité – valaient-ils vraiment le coup/coût ? Certes, le contact humain « en vrai » sera toujours à préférer mais de là à traverser l’Europe sur 1 jour pour un rendez-vous de 2h avec un client ?
Ma conviction : les moments entre collègues seront demain des moments précieux et de partage. Ils seront plus rares, mais également plus qualitatifs. On y perdra forcément une part de spontanéité au change (les fameuses discussions informelles où les décisions se prennent).
Les rituels d’équipes sont également à repenser afin de répondre aux nouveaux enjeux causés par la distance. Et les outils de collaboration centralisant l’information et le savoir (Wiki, Confluence, Notion, Monday, …) vont avoir un rôle central dans l’efficacité et l’autonomie des collaborateurs.
Quelle frontière pro/perso dorénavant ?
Déjà mise à mal ces dernières années avec l’avènement des smartphones (notifications permanentes), l’émergence des messageries instantanées (Slack, Teams, …) et l’explosion du nombre de mails : la frontière pro/perso a de nouveau été chamboulée lorsque votre pièce de vie est devenue votre (nouvelle) pièce de travail.
Comment faire la transition du perso au pro en début de journée ? Et du pro au perso en fin de journée ?
Cette frontière pro/perso, devenue si perméable, induit une pression constante et il faut une certaine discipline pour segmenter ses journées. Je vous recommande de mettre en place des routines. Le cerveau adore ça, c’est rassurant et cela vous remet en zone de confort.
Du coup, respectez une routine qui vous permettra de switcher d’un état à l’autre (du perso au pro – et inversement). Et voici quelques exemples me concernant :
Le matin : prendre un petit déjeuner en écoutant un podcast avant de commencer la journée de travail
Le midi : lire et traiter tous les mails reçus pendant 10-15 min avant d’aller préparer à déjeuner
Le soir : terminer par une action dite légère pour soi (ex : lecture d’un article) avant de terminer sa journée de travail
Au passage, si le sujet des “habitudes” vous intéresse je vous recommande l’excellent Atomic Habits de James Clear. Et bien sûr pendant les vacances (et plus généralement en dehors du temps de travail) : coupez vraiment.
Un rythme de travail qui augmente et ralentit en même temps ?
C’est là tout le paradoxe de cette période COVID-19 : en décroissance économique le rythme (et la pression) augmentent mais les résultats financiers déclinent (pour la majorité des entreprises). On travaille plus mais on gagne moins. Frustrant. On avance dans un sens pour faire demi-tour la semaine d’après. Frustrant aussi.
Pour illustrer sur ce genre d’expérimentations je peux vous parler de la mise en place de webinaires qui foisonnaient en début de confinement avant de disparaître aussi vite (ou presque).
Au final on accélère pour mieux freiner ? Pas vraiment, c’est plus subtil que cela.
Ces expérimentations font partie du cycle d’innovation. Leur apparition est juste accélérée à cause de la récession – le chiffre d’affaire est en deçà des prévisions pour – de nombreuses entreprises : il faut trouver d’autres relais de croissance et donc faire des choses différentes pour avoir des résultats différents. Innover donc.
Si bien que les semaines sont des alternances de temps forts (beaucoup de pression et de stress) et de temps faibles (moments calmes propices à la réflexion et l’idéation). Sachant que l’un nourrit l’autre et inversement.
Ce phénomène existait déjà avant, il était juste moins visible et souvent implicite. En effet, le télétravail (“seul” devant son ordinateur) a considérablement réduit les perturbations (on parie que vous prenez beaucoup moins de pauses qu’avant ?) et favorisé l’émergence de ces temps faibles qui favorisent … l’innovation (ou a minima la réflexion).
Par rapport à la pression (des chiffres bien souvent) il faut relativiser et s’adapter. Pour reprendre la loi de Pareto : quels sont les 20% de travail qui vont amener les 80% de résultats ? Cette période est une formidable opportunité pour repenser ses méthodes et pratiques de travail et remettre en cause certaines fondations devenues obsolètes (ex : cette communication quotidienne que j’envoie à tout le monde – et que personne ne lit – est-elle vraiment indispensable ?). Ralentir pour mieux accélérer demain. Voyez cela comme un temps d’investissement.
2020 : l’électrochoc ?
Les changements liés à cette pandémie sont énormes. Ils remettent sur le devant de la scène une notion de sens et de contribution à un écosystème global dépassant l’entreprise (est-ce que vous faites un bullshit job ?). Ils touchent également tous les niveaux de l’entreprise : son organisation, ses équipes et surtout les individus qui la compose. Et bien sûr les interactions (complexes) entre tous ces éléments.
La période de décroissance que nous traversons est l’occasion de remettre ces sujets à plat : comment faire mieux dans un monde qui a été bouleversé en quelques semaines tout en contribuant à l’écosystème ?
Avant de repartir je vous invite à réfléchir à ces questions
Si vous avez une baguette magique : que changeriez vous immédiatement dans l’organisation de votre travail ?
À la prochaine crise, à quoi pourrait-on voir que vous avez changé ?
qu’un membre de votre CODIR claque la porte en pleine réunion ?
que la salle de réunion se transforme en ring de catch inter-services ?
que, faute d’accord sur une décision importante, les échanges se concluent par : « Bon, ben, on en reparle au prochain CoDir… » ?
que personne ne s’écoute et chacun reste campé sur ses positions en mode « bête et borné », et au final aucune décision n’est prise : c’est le codir stérile ?
que, lassée des règlements de compte à O.K. Corral, la dernière recrue prometteuse fraîchement entrée dans le CoDir décide de ne pas rester ?
que personne ne s’exprime par excès de cordialité et chacun n’en fait qu’à sa tête en sortie de CODIR ?
Quel que soit le scénario, il y a toujours une solution pour sortir de l’impasse et rendre votre CoDir plus efficace
Scénario n°1 « le dialogue de sourds » ou « le faux accord »
C’est top ! Ce matin, une décision a enfin été prise concernant la stratégie commerciale à adopter pour notre antenne Cherbourgeoise. Ce soir, c’est l’occasion pour Pierre, Paul et Jacques de la partager avec les autres membres du CoDir.
Pierre se lance :
« Nous avons donc convenu d’adopter cette stratégie… »
Il est rapidement interrompu par Paul :
« Mais, non, ce n’est pas du tout ce qu’on s’est dit ce matin ! Je ne suis pas d’accord sur cette partie et tu le sais très bien… »
« Bien sûr que si, c’est exactement le plan qu’on a validé ensemble. Tu as dit que tu étais ok pour bouger sur ce point. »
« Mais non enfin, ce n’est pas du tout ce que j’avais acté »
Et Jacques n’a pas l’air en phase non plus :
« Ce n’est pas ce que j’avais compris non plus, mais je ne suis pas tout à fait en ligne avec Paul pour autant… »
Pierre s’entête :
« Selon moi, il n’y a pas d’autre solution valable… »
Et Jacques enchaîne :
« Mais si enfin alors ! Ma solution, celle dont je vous ai parlé ce matin ! Bon, ça suffit, j’en ai assez, finissez ce CoDir sans moi ! »
Excédé, Paul quitte la réunion en claquant la porte.
Autant dire que le CoDir n’est toujours pas plus avancé sur la stratégie à adopter.
Que s’est-il passé ?
Le matin, personne ne s’est réellement écouté, aucune clarification n’a été effectuée.
Chacun est resté campé sur sa position, sans essayer de comprendre celle de ses interlocuteurs.
L’un d’eux a dû finir par lâcher un « ok » de principe sans réel accord ni engagement mutuel
#CoDirInutile #PerteDeTemps #Démotivation
Comment faire différemment la prochaine fois ?
Écouter l’autre et admettre que son idée aussi peut être excellente
Demander quels sont les inconvénients pour les autres d’opter pour votre proposition
Clarifier précisément la décision finale et l’acter
Proposer la mise en place de l’animation déléguée, impliquant la co-responsabilité de tous les participants (distribution des missions (et des redevabilités associés) au service de la performance des réunions, et des processus de prise de décision)
Appliquer : le « Core Protocole Decider » pour acter une décision commune
#MissionsDéléguées #OsezDire #SainesDiscussions
Scénario n°2 « oui, mais alors non ! » ou le syndrome de la boucle infinie
Cela fait déjà 10 mn que vous entendez Rémi, un des membres du CoDir ergoter au sujet de la mise en place d’une nouvelle offre dans votre entreprise, pour laquelle il n’est pas du tout à l’aise :
« Il y a un truc qui me gêne dans ce processus…, …Ce n’est pas normal de faire comme ça…, …Moi, ça me dérange tout ça…, …En l’état, ça ne me va pas… »
Lassé, vous n’en pouvez plus d’entendre ces justifications alambiquées sans aucune proposition de solution et vous sentez que votre CoDir est en train de se noyer dans un cercle vicieux sur ce sujet.
Rémi est en boucle et les autres semblent frustrés, alors vous lâchez :
« Ok, super, alors on fait quoi là ? Ne pensez-vous pas que nous sommes en train de perdre du temps ? Et que nous avons d’autres sujets prioritaires à traiter ? … »
Et là, c’est le drame… L’attaque frontale pour un dénouement banal ?.. : aucune décision n’a été prise et vous récupérez un collaborateur frustré qui vous plombera le prochain CoDir.
Que s’est-il passé ?
Rémi était parasité par un sujet qui l’empêchait d’avancer
Vous n’avez pas pris le temps et le recul pour comprendre quel est le besoin de Rémi et lui donner les clés lui permettant de sortir de sa spirale négative
Au fur et à mesure de la réunion, Rémi emploie une stratégie négative pour satisfaire son besoin psychologique
Et voilà, c’est reparti, encore une fois, les 2 fondateurs de votre boîte sont partis en live en s’invectivant sur des sujets qui n’ont rien à voir avec la stratégie d’entreprise.
Ils se donnent en spectacle devant l’ensemble du CoDir en s’attaquant sur tous les fronts, mêlant vision professionnelle et sujets personnels :
« Je ne comprends pas pourquoi tu t’obstines à aller contre cette stratégie de développement. Tu as vraiment une vision passéiste, je te parle de l’avenir là ! »
« Moi, je ne prétends pas savoir lire dans une boule de cristal et je ne parierai pas l’avenir de notre boîte sur un coup de poker »
« Super ! Pendant ce temps-là, nos concurrents, eux, investissent dans l’innovation et nos meilleurs talents ne vont pas tarder à les rejoindre »
« Non mais si tu passais un peu moins de temps sur ton bateau à Cherbourg et un peu plus au bureau, tu comprendrais que ce n’est pas si simple ! »
« De toute façon, ça ne m’étonne pas, tu n’es qu’un gros radin avec des oursins dans les poches, je me demande encore pourquoi je t’ai choisi comme parrain pour ma fille »
« Ah, ben c’est sûr que toi, question générosité, tu te poses là, avec tes restos hors de prix pour tes soi-disant clients à potentiel et la distribution annuelle de primes à profusion pour tes petits chouchous »
« Donner pour recevoir, ça te dit quelque chose… »
Ce CoDir tourne au pugilat entre co-dirigeants, bloquant ainsi toutes les prises de décisions importantes et mettant en péril le futur de l’entreprise.
Que s’est-il passé ?
Les deux protagonistes incarnent des postures négatives induisant une situation toxique (jeu psychologique et switch de rôles dans le triangle dramatique)
Aucune décision n’est prise, le chaos règne et un taux de turn over élevé s’annonce
Le CODIR peut se transformer en tribune de supporters où chacun peut avoir le sentiment de choisir un camp au lieu de prendre part à une décision
Alors, pour éviter que votre CoDir se tape dessus, voici quelques conseils à mettre en pratique :
11 tips pour un CODIR efficace :
Préparer les sujets en amont du CoDir (diffusion, lecture, remarques sur support partagé).
Partager systématiquement l’agenda. En début de CoDir, tout le monde est aligné sur l’ordre du jour et les objectifs fixés pour chaque sujet.
Commencer par un icebreaker. Par exemple : les 3 batteries (mentale, émotionnelle et physique) permettant à chacun de prendre conscience de son niveau d’énergie, anticiper les potentiels débordements et adapter son État du Moi aux personnes et aux situations.
Timeboxer les sujets. Si l’objectif n’est pas atteint au bout du temps imparti pour un sujet, vous pouvez décider collectivement d’accorder plus de temps au sujet (arbitrage vs autre sujet) ou de stopper les échanges et définir ensemble la façon dont s’organise le bouclage du sujet.
Pour chaque sujet, annoncer clairement l’objectif / ce qu’on attend du CODIR (partage d’information, recueil de feedbacks, plan d’action à définir, décision à prendre…).
Apporter une nouvelle idée au groupe lors dechaque intervention. Ne pas parler pour se faire plaisir. Ne pas répéter ce que d’autres ont déjà dit.
Adopter collectivement une approche constructive et bienveillante. On a le droit de ne pas être d’accord, mais on doit systématiquement avoir une proposition à faire. Il faut savoir accepter les critiques, sans rentrer dans une logique de justification.
Respecter les décisions prises et les mettre en œuvre.
Mesurer la performance du CoDir à la fin de chaque séance, dans une logique d’amélioration continue (notation de l’efficacité par chacun de ses membres et travail en sous groupe sur le petit pas à faire pour obtenir un point de plus).
Attribuer des rôles tournants à chaque session par l’animation déléguée.
Former les membres de votre CoDir à différentes techniques comme la Process Communication, Manager agile et plus globalement à l’analyse transactionnelle pour développer leur intelligence relationnelle.
Il faut que je vous avoue que lorsqu’on me demande sur quelle certification agile je peux former les gens, j’ai parfois un peu honte de dire que je peux le faire sur SAFe avec la Scaled Agile Academy.
Aussi, je m’empresse le plus souvent d’ajouter que je suis aussi formateur licencié Management 3.0. Comme pour me dédouaner.
Cette opposition de genres peut surprendre. Encore plus lorsqu’on connaît également mon penchant pour les organisations plates (pour ne pas dire entreprises libérées) et les interventions et articles que j’ai pu faire à ce sujet.
Pour autant, je ne vois pas cela comme une schizophrénie. Et oui, j’ose le dire, j’aime bien SAFe !
Alors pourquoi SAFe est-il un framework qui crée autant de débats ? Pourquoi est-ce que cela peut sembler honteux d’utiliser SAFe ? Autrement dit, SAFe est-il vraiment agile ?
Je vous propose de décrypter tout cela à travers 9 affirmations. 9 arguments massue trop souvent utilisés pour jeter SAFe en pâture dans la fosse aux lions. 9 critiques à la véracité insuffisamment questionnée.
Non, je ne vous ferai pas le coup des “10 affirmations sur SAFe, la 10éme va vous étonner…” mais restez quand même avec moi jusqu’à la fin ;).
Pour commencer, je reviendrais sur l’une des sentences les plus souvent prononcées à son encontre : “SAFe est trop complexe”.
C’est une affirmation que je peux totalement comprendre. Pour qui a un jour regardé le poster SAFe, cela peut même sembler une évidence, tant on peut se trouver perdu à son premier regard.
Pourtant ce défaut de complexité, au-delà du fait qu’il n’est surtout qu’apparent et s’éclaire grandement quand on appréhende pleinement la logique du framework, est l’une des véritables qualités de SAFe.
Si le framework est compliqué, c’est qu’il imbrique beaucoup de sources de connaissances différentes. Il s’attache à faire le lien entre elles ; ce qui n’est jamais chose facile.
En y regardant de plus près, c’est cependant une manière (mais pas la seule) de construire une véritable approche systémique. Réunir autant de savoirs différents, c’est s’attacher à ce que l’ensemble des aspects de l’équation soient pris en compte. Et de ce point de vue, je pense que c’est le framework qui permet la meilleure vision d’ensemble. On y retrouve du lean startup, du design thinking et de l’UX, du Scrum, du Kanban, du DEVOPS (dont le continuous delivery), du Beyond Budgeting et de la gestion de portefeuille, du Management 3.0, du Lean etc.
On a donc une vision qui n’oublie ni les personnes, ni les pratiques, ni la stratégie, ni le client, ni les environnements, ni le management et ni même la culture !
Donc oui, SAFe peut être complexe (au sens des systèmes complexes), mais c’est une complexité nécessaire. Je citerais d’ailleurs à ce sujet Max Boisot qui dit:
La complexité d’un système doit être en adéquation avec la complexité de l’environnement dans lequel il se trouve.
Max Boisot
The Interaction of Complexity and Management
Cela dit, SAFe ne cherche aucunement à être complet sur l’un ou l’autre de ces composants. Il propose des outils dont il nous laisse en partie le soin d’approfondir le contenu.
Il n’y a par exemple pas d’explication détaillée du Gemba, qui fait partie des éléments inhérents à une approche Kanban. Bien que s’appuyant sur Kanban (et plus largement le Lean), SAFe considère que c’est à nous d’en maîtriser les concepts.
Sur ce sujet, SAFe n’impose d’ailleurs aucune méthode. Pour preuve, même si Kanban est devenu aujourd’hui un pilier important, il était autrefois cantonné à la seule gestion de portefeuille. Jusqu’à la V4 du framework en effet, seul Scrum était utilisé comme moyen de piloter une équipe agile.
SAFe est ainsi un framework qui, en son coeur, encourage la sélection des pratiques et outils. Ce qui nous permet alors de nous adapter à l’environnement auquel nous sommes confrontés. Ce faisant, nous pouvons sélectionner le juste niveau de complexité dont nous avons besoin !
2. SAFe n’a rien inventé (sous-entendu “donc c’est pas bien !”)
[br]Autre objection que l’on entend trop souvent, SAFe n’aurait innové en rien ! C’est tout d’abord un faux reproche. Il est parfois plus utile de relier des savoirs que d’en créer de nouveaux. Je rappellerais d’ailleurs cette citation de Bernard de Chartres reprise par Pascal ou même Newton en leur temps :
Nous sommes comme des nains assis sur des épaules de géants. Si nous voyons plus de choses et plus lointaines qu’eux, ce n’est pas à cause de la perspicacité de notre vue, ni de notre grandeur, c’est parce que nous sommes élevés par eux.
Bernard de Chartres
Metalogicon – Livre III
Pour autant, SAFe est un framework qui a lui aussi apporté sa pierre à l’édifice de l’agilité. L’intégration des savoirs agiles et la proposition d’une représentation cohérente à l’échelle de l’entreprise n’est déjà en soi pas un mince exploit. Quand bien même cela aurait été la seule contribution de SAFe, cela aurait eu de la valeur. Mais SAFe va plus loin. Au-delà de cette mise en cohérence, il amène également ses propres nouveautés.
J’en citerai simplement deux: le PI Planning et l’intégration des architectes au coeur de l’agilité.
Le PI Planning est certainement le plus emblématique des apports de SAFe. Qui aurait pu penser que réunir jusqu’à 125 personnes pendant deux jours était une bonne idée ? Pour autant, cet événement est loin d’être la foire à laquelle on pourrait s’attendre. En vivre un est même bien souvent déterminant pour convaincre une entreprise de s’engager dans SAFe. Et ce quand bien même le PI planning peut justement être l’un des éléments qui auraient tendance à faire peur !
Ce sont d’ailleurs généralement ces mêmes détracteurs du PI planning qui viennent ensuite en faire l’apologie. Ils sont enthousiastes face à l’énergie libérée et l’efficacité avec laquelle les problèmes sont gérés. Ils sont surpris de la transparence et de la vision apportées, heureux de l’engagement suscité.
L’intégration des architectes dans SAFe, même si elle est moins souvent mise en avant est également très intéressante. D’abord elle permet de casser un tabou ! Celui d’une agilité qui ne pourrait pas avoir de vision à moyen terme ou de planification.
En effet, les architectes ont longtemps été les laissés pour compte de l’agilité. Le fait de chercher à obtenir des équipes auto-organisées, autonomes et ayant toutes les compétences pour réaliser le produit a pu être vu comme une critique de leur rôle.
Il faut dire qu’ils avaient fini par être perçus comme un élément de rigidité des organisations. En codifiant les méthodes, outils et langages à utiliser ils venaient entraver les besoins d’adaptation des équipes agiles. La guerre était déclarée.
Pourtant l’autonomie sans vision partagée est la meilleure recette du chaos. Sans celle-ci, il est impossible de créer l’alignement et chacun part dans sa propre direction.
SAFe en intégrant le rôle d’architecte aux différents étages du framework, redonne ce rôle de porteur de sens. Les architectes ne sont plus là pour établir une vision figée de l’organisation, mais une vision évolutive.
Ils viennent donc en soutien des équipes en permettant l’alignement de celles-ci avec des approches dont ils garantissent la cohérence. Ils s’assurent également que si les choix sont ouverts en début de réalisation, ils finissent par se stabiliser avec le temps. Ils permettent ainsi d’éviter l’oscillation permanente qui frappe parfois certaines équipes agiles, incapables de converger vers une solution.
3. SAFe est un framework de command and control
L’idée que SAFe serait en fait une approche de command and control, est peut-être la dernière grande critique que l’on entend régulièrement professée à son égard.
Cette notion d’une approche dictatoriale est sans doute accentuée par le célèbre poster de SAFe. Cette représentation détaillée peut en effet donner l’impression d’un framework très orienté processus. Visuellement, la représentation des différents étages de coordination en se rapprochant des structures pyramidales des sociétés, peut laisser penser à une forme de hiérarchie. Une idée bien ancrée dans l’esprit de certains.
Je soupçonne néanmoins la Scaled Agile Academy de maintenir volontairement une certaine ambiguïté sur le sujet. À travers son poster et sa représentation à étages, SAFe laisse penser à une continuité du fonctionnement hiérarchique de l’Ancien Monde. Un choix qui explique le succès commercial de SAFe. Cette représentation de l’agilité, proche des méthodes traditionnelles, et de nos anciennes croyances, est en effet bien plus rassurante aux yeux des dirigeants.
Malheureusement, cette vision d’un SAFe qui ne nécessiterait pas de changer notre compréhension du monde, mais d’adopter simplement de nouveaux processus est également une des raisons principales d’échec de son implémentation.
SAFe, comme tout framework agile, nécessite savoir-faire et savoir-être. Ce dernier étant essentiel ! N’appliquer bêtement que les processus (le savoir-faire), ne peut donc qu’engendrer un échec.
SAFe nous prévient pourtant dès le départ. Il n’est pas une recette prévue pour une application dans sa globalité. Il doit être adapté. Au-delà même des sous-ensembles directement proposés que sont l’Essential SAFe, le Large Solution SAFe, le Portfolio SAFe ou le Full SAFe. C’est une adaptation qui demande une véritable conscience (au sens de savoir-être) des principes et valeurs de l’agilité.
Pour ma part, il m’arrive assez fréquemment de mettre en place chez mes clients une couche de gestion de portefeuille inspirée du Portfolio SAFe. Alors même que les projets/produits ne nécessitent pas de mécanismes d’agilité à l’échelle. Elle apporte en effet un bénéfice réel à l’organisation par les mécanismes de priorisation des projets/produits qu’elle propose.
SAFe est donc un framework qui, peut-être plus que d’autres, peut facilement être dévoyé et implémenté de manière coercitive. On perd ainsi tout bénéfice d’agilité.
Pour autant, il ne m’a jamais empêché de discuter avec certains clients d’organisations plates alors que nous faisions une implémentation de SAFe. Dans le fond, il n’y a rien d’incompatible à ce qu’une entreprise Opale utilise ce framework.
Si l’on peut certes reprocher l’ambiguïté, SAFe n’en reste pas moins un framework agile. Ce n’est pas SAFe qui est anti-agile, mais ce que nous en faisons qui le transforme en outil de command and control.
4. Les métriques dans SAFe sont un retour vers l’utopie de la prédictibilité
Autre critique que l’on entend surtout parmi les agilistes, SAFe propose une approche des métriques qui peut sembler un peu utopique. Dans un monde complexe (et donc volatile du fait des mécanismes d’émergence), SAFe donne l’impression de chercher à tout prédire. C’est une partie que j’ai personnellement mis un certain temps à maîtriser.
En fait, SAFe ne cherche pas à obtenir un chiffre précis, juste et absolu. Son approche des métriques est un moyen d’éclairer la prise de décision. Autrement dit, c’est un moyen de vérifier nos hypothèses, de détecter les changements éventuels et de s’y adapter le mieux possible.
Prenons pour exemple la mesure de prédictibilité du train, qui se base sur le pourcentage de business value atteinte. Cette mesure n’est pas tant effectuée pour suivre l’avancement de nos engagements que pour déterminer à quel point notre environnement est changeant. On ne cherche pas à savoir si l’on va tenir nos objectifs, mais à ajuster notre manière de piloter en fonction du degré d’incertitude de l’environnement dans lequel on se trouve.
Si parfois l’expérience montre une certaine fiabilité dans l’atteinte de nos engagements, tant mieux ! C’est que nous sommes dans un environnement relativement stable. Nous pouvons alors poursuivre une certaine stratégie d’efficience.
Si au contraire la prédictibilité du train est faible, c’est que notre environnement est extrêmement incertain. Dans ce cas, il ne convient pas de rechercher l’efficience. C’est tout l’inverse. Il faut alors s’attacher à développer nos capacités d’adaptation. Cela veut dire se préserver un maximum d’options, le plus tardivement possible (on pourrait aussi travailler à accroître la stabilité de notre environnement. Tout un challenge !).
Le fait que SAFe repose sur un paradigme de changement se retrouve à la fois dans son fort focus sur la création de valeur et dans la manière dont il la définit.
Dans un contexte où nous ne maîtrisons pas l’évolution de nos écosystèmes, il est en effet essentiel de s’assurer d’investir de manière à ne jamais regretter nos choix. Même si nos prévisions étaient déjouées.
C’est pourquoi SAFe, tout comme l’agilité de manière générale, cherche à travailler en permanence sur les éléments dont nous estimons pouvoir dégager le plus de valeur. Le travail est même découpé d’une manière qui nous permette d’en retirer le maximum de bénéfice, quel que soit le moment où nous devrons procéder à des ajustements.
Autrement dit, face au changement, il s’agit d’être dans une situation où force est de constater que nous n’aurions pas pu mieux nous organiser. Nous n’aurions pas pu créer plus de valeur. Nous n’aurions pas pu mieux limiter nos pertes. À moins évidemment d’avoir eu connaissance du changement à l’avance, mais ce serait là un biais de lecture a posteriori…
Comme je le disais, cette incertitude se retrouve jusque dans la façon dont SAFe définit la valeur. C’est en effet le seul framework à parler d’hypothèses de bénéfices et non de bénéfice tout court.
Il met ainsi en lumière le raccourci trop souvent commis entre la valeur escomptée d’un projet/produit et sa valeur réelle après rencontre avec le marché.
En ajoutant cette notion d’hypothèse, SAFe met en exergue la nécessité de piloter le bénéfice escompté. Dès la réalisation de l’epic hypothesis statement, le framework recommande la définition d’indicateurs de pilotage de la valeur (les leading indicators).
Par la suite, ces KPIs permettront de vérifier la justesse de nos suppositions et de mieux détecter les éventuelles adaptations nécessaires (dans nos priorités comme dans notre stratégie). C’est une approche typiquement Lean Startup dans l’esprit (et une belle utilisation de l’innovation accounting) !
De tout cela on retiendra surtout que SAFe ne cherche pas tant la prédictibilité ou la mesure exacte que l’obtention d’informations suffisantes pour prendre des décisions et les piloter.
5. C’est vraiment compliqué d’évaluer la valeur dans SAFe
Au rang des critiques portées à l’encontre de SAFe, on entend encore celui de la manière dont la valeur y est évaluée. Ce n’est pas sans lien avec les reproches faits au regard de l’apparente précision des métriques et leur illusion de prédictibilité.
Sur ce point, il est essentiel de bien comprendre que lorsque SAFe tâche d’évaluer la valeur d’un élément (notamment avec un WSJF), il n’essaie pas de le faire de manière absolue, mais de manière comparative. En ce sens, il est tout aussi facile de mesurer un WSJF dans un contexte logiciel que de production.
Le Cost of Delay effectif de l’élément A reste certes inconnu, mais sa comparaison avec l’élément B reste relativement facile à réaliser et facilite la décision de prioriser l’un par rapport à l’autre.
En cela nous sommes proches de l’esprit de How to measure anything (de Douglas Hubbard) : il ne s’agit pas d’avoir un chiffre précis, mais bien d’avoir un encadrement de celui-ci par un intervalle de confiance suffisant. Toutes choses étant égales par ailleurs et tous nos biais de mesures et erreurs étant d’une magnitude similaire, nous pouvons ainsi prendre des décisions justes sur la base d’évaluations pareillement fausses.
À ce sujet, j’aime bien évaluer la valeur en m’appuyant sur des mécanismes d’intelligence collective (diversité, décentralisation et indépendance/autonomie suivant James Surrowiecki, l’auteur de La Sagesse des foules).
Pour cela il suffit le plus souvent d’avoir un groupe de personnes suffisamment diversifié et d’utiliser des techniques adaptées de la magic estimation (qui permettent de comparer au plus vite un grand nombre de critères entre eux).
C’est parfois étonnamment rapide. J’ai ainsi pu évaluer le WSJF de près de 80 projets et les prioriser en moins d’une journée avec une dizaine de membres d’un COMEX !
Personnellement, j’apprécie également le côté global de la manière dont SAFe aborde l’évaluation de la valeur. Elle prend en compte aussi bien la user business value (incluant la valeur de satisfaction client) que la valeur liée au coût de ne pas faire (la fameuse Time Criticality) ou la valeur indirecte (réduction de risque et développement d’opportunités futures).
En cela, le framework est plus riche qu’un simple Scrum. Il ne se contente pas de la seule valeur business mais rend explicites d’autres types de valeurs. En retour l’attention constante pour la satisfaction client peut cependant paraître moins évidente.
Ainsi, même si SAFe nous incite à évaluer la valeur sur plusieurs axes, le fait de le faire de manière comparative ne rend pas les choses plus compliquées qu’avec une autre méthode.
6. SAFe, contrairement à LeSS ou au modèle Spotify n’est pas adapté à une démarche produit
On a tendance à penser qu’un framework adapté pour des projets à 125 personnes et plus n’est pas pertinent pour l’adoption d’une démarche produit. C’est là encore une critique que j’ai pu entendre surtout en comparaison avec LeSS ou le modèle Spotify.
On précisera d’abord, comme nous le rappelle Séverin, qu’il n’y a pas de modèle Spotify. Il ne s’agit que d’un retour d’expérience. Une expérimentation dont le bénéfice, même chez Spotify, est aujourd’hui remis en question. Il n’y a rien de magique. Spotify n’a finalement rien fait de plus que de créer une organisation spécifique à son contexte. Si le mot feature teams peut sembler sexy, il ne s’agit pour autant pas d’autre chose que d’une équipe pluridisciplinaire.
Ceci étant posé, SAFe est bien lui aussi un framework construit pour fonctionner dans une démarche produit. C’est sans doute moins visible que dans le framework LeSS, car SAFe se veut plus versatile. Il cherche à la fois à pouvoir définir le fonctionnement d’une organisation complète et à permettre la cohabitation de différentes démarches (y compris donc du cycle en V avec de l’agilité).
La vision produit de SAFe est essentiellement portée par la manière de financer les values stream et l’approche capacitaire qui en découle. À travers cela, SAFe promeut la stabilité des équipes dans le temps.
Il facilite également le suivi des produits tout au long de leur cycle de vie en n’externalisant pas la gestion du run. Dans cette logique, SAFe introduit Kanban comme méthode de gestion au niveau équipe lors de la parution de sa V4. Il permet ainsi un meilleur pilotage d’activités de build et de run simultanées, courantes lorsqu’on travaille sur un produit.
Au niveau équipe, SAFe met également en avant la constitution d’équipes organisées en feature teams avec toutes les compétences (quand c’est possible) pour développer et maintenir l’intégralité du produit.
Cela fait d’ailleurs relativement sourire de voir SAFe opposé au retour d’expérience de Spotify dans la mesure où les équipes pluridisciplinaires sont bien présentes dans le framework (de mémoire au moins depuis la V3 et avec les communautés de pratiques et d’intérêt dès la V4).
Il serait donc temps d’arrêter de déifier le modèle Spotify et de le prendre pour le retour d’expérience qu’il est.
L’organisation en feature teams, l’utilisation de Kanban ou la promotion d’équipes pérennes sont autant d’éléments de SAFe adaptés à une approche produit.
7. SAFe n’est que pour les grosses entreprises
Si l’on arrive à faire face à tous ces arguments anti-SAFe, il en reste encore un qui tient à l’idée que SAFe ne serait de toute façon adapté qu’à de grandes organisations.
Ce n’est pas totalement faux. À moins de 50 personnes sur un projet, SAFe a effectivement peu d’intérêt. Dans ce cas, le surcoût de pilotage nécessaire surpasse le plus souvent les bénéfices obtenus.
De manière générale d’ailleurs, la première règle de l’agilité à l’échelle devrait être de ne pas faire d’agilité à l’échelle !
Trop souvent, on cherche en effet à mettre en place des mécanismes d’agilité à l’échelle pour compenser un manque de rigueur dans l’optimisation du système.
Affronter les problèmes en face est difficile. Changer une culture peut sembler un véritable travail d’Hercule. Rechercher les causes racines d’un problème est bien plus délicat que de trouver un coupable. Aussi, pour ne pas remettre en questions nos habitudes, on s’efforce trop souvent de compenser en ajoutant plus de monde sur le projet ou en essayant d’appliquer le dernier framework à la mode.
Plutôt que de prendre le risque d’adopter une véritable démarche d’amélioration continue et de régler les problèmes qui nous font face, nous choisissons de grandir dans une fuite en avant. Nous cherchons à avoir toujours plus de ressources en espérant que cela va miraculeusement tout résoudre!
Si je me souviens bien, Alistair Cockburn rapportait d’ailleurs cette anecdote : sur un projet, il avait déterminé qu’avec les bonnes personnes, il était réalisable avec 6 développeurs. Comme il ne les avait pas, il lui en fallait 50 !
Cela étant, il y a bien sûr des situations où il est indispensable de faire grandir les projets. C’est là une des forces de SAFe qui propose un système facilement scalable.
J’ai déjà dit qu’il m’arrivait de n’avoir recours qu’à la partie Portfolio du framework, mais il est aussi possible de n’utiliser que l’une ou l’autre des couches. Si vous le souhaitez, vous pouvez parfaitement vous contenter de ne mettre en place qu’un seul train. Non seulement rien ne vous force à tout déployer, mais il sera par ailleurs très facile d’ajouter de nouveaux éléments ultérieurement.
La règle devrait être de ne mettre en place que le strict minimum de processus que vous pensez nécessaire et ceci fait d’en retirer encore ! De manière surprenante, vous vous rendrez compte que même ces éléments que vous pensiez indispensables et que vous venez de supprimer n’ont rien d’obligatoire.
Ainsi, nul besoin d’être un grand groupe du CAC 40 pour utiliser SAFe, le plus important c’est d’adapter et de ne pas vouloir systématiquement utiliser tous les étages de la fusée !
8. Pour faire de l’agilité à l’échelle, il vaut mieux construire son propre framework
À en croire certains SAFe ne serait finalement pas un bon framework d’agilité à l’échelle, car chaque entreprise étant unique il n’est pas possible d’avoir une solution pertinente pour tous. Il vaudrait donc mieux concevoir son propre framework.
C’est d’ailleurs la tendance dans tous les grands groupes. J’ai pu participer à la création de quelques-uns et en observer d’autres. Je dois avouer que cela m’a laissé perplexe…
Certes, on peut se féliciter de voir que même les grands groupes, pourtant peu connus pour leur rapidité à s’adapter, ont fait leur ce principe d’adaptation de l’agilité au contexte. Cependant, je ne peux que constater que tous ces frameworks maison, ne sont en fin de compte que de pâles copies de SAFe. J’ai même pu observer l’intervention de grands noms du conseil qui en créant ces modèles, ne faisaient rien d’autre que recopier SAFe. Parfois, et c’est un comble, ils y ajoutaient même des erreurs !
Il en résulte que toutes ces tentatives de développement d’une solution maison aboutissent souvent à des coûts importants, des délais à rallonge et un framework déjà obsolète au jour de son lancement ! Il n’y a rien de surprenant à cela.
En effet, vouloir dès le début se construire une approche spécifique, c’est le faire au plus mauvais moment. Celui où nous ne maîtrisons ni l’agilité, ni ses conséquences sur notre organisation.
Bien sûr, il y a de nombreux frameworks d’agilité à l’échelle. Mon propos n’est pas de dire que SAFe est le meilleur d’entre eux. Je dirais surtout que c’est probablement le moins pire !
Ce qui est essentiel n’est pas d’en faire une implémentation rigide, mais de le prendre comme point de départ.
C’est un moyen de se construire une expérience de l’agilité à l’échelle au sein de notre organisation et de notre contexte.
Cela n’est en aucun cas un objectif ou une destination !
Alors que nos connaissances sur la nature de notre environnement, nos particularités culturelles et les attentes de nos clients progressent, nous pouvons alors commencer à élaborer nos adaptations en connaissance de cause. Il sera alors temps de concevoir une approche dans un esprit de continuous organization. C’est-à-dire, une entreprise capable de se réinventer et de s’améliorer en permanence.
Ainsi utiliser SAFe comme point de départ est un raccourci intéressant. Cela nous évite de devoir directement construire une approche spécifique, à un moment où notre compréhension des mécanismes est largement insuffisante. Créer son propre modèle quand on n’en a pas la maturité est une perte de temps. Tout comme faire de SAFe une vérité absolue à suivre à la lettre serait une erreur grossière
9. SAFe n’est pas de l’agilité à l’échelle
Quant à la dernière objection à faire à SAFe, c’est à moi d’intervenir et de la soumettre à votre réflexion. Si l’on en revient au coeur du problème qui est la manière de faire de l’agilité à l’échelle, je crois que SAFe, LeSS, DAD et autres Nexus sont tous foncièrement biaisés.
Face aux problématiques d’échelle, tous ces frameworks proposent de gérer la complexité liée à l’augmentation du nombre d’échanges (facteur d’émergence) par ajout de processus (ou mécanismes de coordination).
Ceux-ci peuvent être plus ou moins lourds, ils n’en restent pour autant pas autre chose qu’une forme de procédure. C’est à dire quelque chose par essence figée et qui ne peut être adaptée à toutes les situations.
Multiplier ainsi les processus reviendrait donc à réduire notre capacité d’adaptation.
Sur ce sujet d’ailleurs, il est intéressant de voir combien, dans le domaine militaire, les forces spéciales laissent une grande place à l’autonomie.
Certes, elles sont entraînées à réagir de manière quasi automatique à un grand nombre de situations. N’oublions pas qu’elles interviennent à des moments laissant souvent peu de place à la réflexion. Dans ces contextes, l’automatisme peut faire la différence entre la vie et la mort.
Si nous cherchons réellement à être agile à l’échelle, nous devons donc fuir les règles préétablies.
Dès lors, il s’agit bien de diminuer le nombre de processus pour accroître notre capacité d’adaptation. En effet, plus nous serons nombreux, plus nous multiplierons les interfaces avec nos environnements et plus nous serons fréquemment confrontés au changement. Avec la taille, la nécessité de développer notre faculté d’adaptation gagne en criticité.
Si l’on devait proposer une définition de l’agilité à l’échelle, on pourrait l’écrire ainsi : Être agile à l’échelle, c’est savoir accroître les capacités d’adaptation, de résilience ou d’innovation de l’organisation plus rapidement que sa taille n’augmente.
Sur ce sujet SAFe, tout comme l’ensemble des frameworks d’agilité à l’échelle, de par leurs ajouts de processus au fur et à mesure que l’organisation grandit, ne sont donc pas réellement adaptés…
Mais alors… l’agilité à l’échelle est une utopie ?
Bien sûr que non ! Mais le changement pour y parvenir est loin d’être évident !
Si l’on accepte que l’agilité à l’échelle c’est l’adaptabilité à l’extrême, il existe bel et bien une approche en ce sens.
Si l’on regarde les principes de construction des organisations plates, tels que présentés par Frédéric Laloux dans son livre Reinventing Organizations, on s’aperçoit en effet que c’est précisément cette philosophie qui est à l’oeuvre.
L’entreprise libérée n’est à ce titre ni plus ni moins qu’une société dont la capacité d’adaptation a été poussée à l’extrême. Laisser chacun libre d’entreprendre les actions qui lui semblent les plus justes pour l’entreprise c’est permettre d’agir au plus près du changement. C’est comme de mettre le volume de l’agilité à 11 !
Plus l’entreprise est apte à laisser de l’autonomie à ses collaborateurs, plus elle gagne en agilité.
C’est un chemin qui, s’il peut être séduisant, comporte ses propres embûches !
À commencer par la difficulté à proposer une vision transcendantale, véritable lien de l’organisation qui permette à chacun d’avancer indépendamment dans la même direction.
Sur ce sujet, vous pouvez d’ailleurs tout de suite oublier les visions du type: faire un milliard de chiffre d’affaires ou être le premier sur son marché.
Une vision ne vaut que si elle est partagée et bénéficie à tous. Tant que la poursuite de votre vision ne se traduit pas dans les actes de chacun au sein de l’organisation, vous n’avez pas encore trouvé le bon message.
Ce genre de transformation représente une véritable révolution culturelle et une route ardue.
Vous serez confrontés aux difficultés de la transparence, de l’acceptation des erreurs et de la valorisation de l’apprentissage et de l’expérimentation.
Vous affronterez la perte de repères de l’abandon des statuts et le challenge de la redéfinition des plans de carrière.
Vous devrez construire une entreprise apprenante qui permette le développement de chacun et se réinvente en permanence.
Aller dans cette direction, c’est accepter d’avancer sur un chemin peu emprunté où il vous faudra découvrir vos propres leçons.
De fait, même si un tel mode d’organisation serait finalement une réponse plus pertinente aux problématiques d’échelle dans un monde complexe, le challenge est indéniable.
Il est ainsi souvent plus aisé d’apporter une réponse s’appuyant sur un framework d’agilité à l’échelle que de s’engager sur ce chemin. Quand bien même l’agilité à l’échelle porte ses propres limites.
Il n’y a aucune honte à cela et vous pouvez vous réconcilier avec SAFe.
Et si d’aventure votre coeur d’agiliste vous poussait vers davantage, n’ayez aucun regret.
Comme je l’ai dit et le répète : avec le bon accompagnement, l’un n’est pas nécessairement incompatible avec l’autre.
Si SAFe n’est pas la destination, c’est peut-être néanmoins l’un des meilleurs premiers pas…
Un voyage de mille lieues commence toujours par un premier pas.
