Comment réussir sa transformation agile sans les équipes métier ?

Le monde de l’entreprise est en pleine mutation, et ce depuis plusieurs années. Les défis qui attendent les grandes organisations sont multiples et complexes. La société civile évolue, et embarque avec elle une nouvelle génération de collaborateurs qui aspirent à de nouveaux idéaux, pas toujours en phase avec ceux de leurs aînés. Les entreprises doivent donc se “transformer”, afin d’être capable de répondre aux enjeux de demain.

Nous n’aborderons pas ici les différentes raisons qui poussent les organisations à entamer une transformation, mais plutôt au travers d’un exemple concret les moyens d’y parvenir dans un contexte particulier. En effet, j’ai la chance de participer à la mutation d’une grande banque française, adossée au premier groupe bancaire de l’hexagone.

Nous verrons dans cet article comment l’entreprise à décidé d’organiser sa transformation tout en l’appuyant sur une réorganisation de son management interne. Par la suite, les raisons qui l’ont poussées à adresser uniquement la direction informatique et de choisir délibérément de transformer son “métier” par la suite. Enfin, nous verrons quels enseignements tirer de cette approche, les points positifs ainsi que les écueils qui restent à couvrir.

Qu’est-ce qu’une transformation agile ?

Agility is not Scrum

La confusion entre agilité et Scrum est courante, mais il est important de comprendre que l’agilité dépasse de loin ce seul framework. Si Scrum est une méthodologie populaire qui aide les équipes à travailler de manière plus itérative et collaborative, l’agilité en elle-même est avant tout un état d’esprit. 

J’ai beaucoup entendu dans mes expériences précédentes qu’à partir du moment où les équipes de réalisations avaient à leur disposition un board, des post’it et qu’ils se parlaient tous les matins pendant 15 minutes, il étaient agiles.

Mais en effet, l’agilité est loin des outils et des cérémonies. Il s’agit avant tout de créer une culture de flexibilité, d’amélioration continue et de réactivité aux changements du marché et aux besoins des clients. 

L’agilité encourage les équipes à expérimenter, à apprendre de leurs erreurs et à s’adapter rapidement. Pour l’expliquer à des novices, j’aime utiliser l’acronyme KISS (Keep it Simple stupid). Si le “stupid” peut sembler cavalier, il a le mérite de provoquer le lecteur en lui rappelant que parfois, les choses les plus simples sont les plus efficaces.

De son côté, Scrum offre une structure pour mettre ces principes en pratique. Adopter l’agilité signifie intégrer ces valeurs dans chaque aspect de l’organisation, au-delà des processus de développement. 

Scrum est un élément essentiel de l’agilité, et ce pour plusieurs raisons :  

• Il est le framework le plus célèbre, et sans doute le plus utilisé aujourd’hui.
• Il offre un cadre assez contraignant, qui force les équipes qui l’utilisent à modifier leur mindset si elles souhaitent trouver du sens dans les cérémonies agiles qu’il propose.
• Enfin, pour une équipe de développement de produit “classique”, il est sans doute le plus simple à mettre en place dans un premier temps

Mais en effet, si Scrum est agile, on ne peut pas résumer l’agilité à l’utiliser au quotidien. L’agilité est avant tout un état d’esprit où la vraie question qui mérite d’être posée est : Comment j’apporte de la valeur à mon utilisateur final.

Qu’attend-on d’une transformation ?

J’ai toujours tendance à poser cette première question lorsque je rencontre des responsables d’organisation qui souhaitent se transformer.

Qu’attendez vous de cette transformation ? 

Les réponses à cette question varient selon les organisations, mais elles incluent généralement une amélioration de la vitesse et de la qualité de la livraison, une plus grande satisfaction des clients, et une meilleure collaboration interfonctionnelle. Pour une banque, cela peut signifier des cycles de développement plus courts, une capacité accrue à réagir aux régulations changeantes, et une offre de produits plus alignée sur les attentes des clients. 

Il me semble que dans cette démarche, il est important de se concentrer sur le “Why”. Comme l’explique Simon Sinek dans son Talk sur le “Golden Circle”, il est essentiel de partir du “Why” !!

Pourquoi faisons-nous cela ? Quel besoin couvre-t-on ? 

Cette question mérite d’être posée car j’ai trop souvent été le témoin de transformations sans but et où l’unique raison de la transformation était LA transformation. Dans ces cas, on se retrouve avec des équipes à qui on impose une nouvelle organisation, de nouveaux processus et qui finissent par subir cette transformation. Dans la majeur partie des cas, nous nous retrouvons avec des équipes en perte de sens, qui ne comprennent pas le but de la transformation, qui n’y adhèrent donc pas et qui parfois même la sabotent.

Ainsi, les objectifs ne doivent pas se limiter à des gains opérationnels; une véritable transformation vise également à rendre l’organisation plus résiliente, innovante et capable de s’adapter en permanence aux nouveaux défis et opportunités du marché. Ainsi, en quelques mots, “nous rendre tellement adaptables, que les prochaines évolutions structurelles et organisationnelles se feront de manière douce, efficace et sans douleur”. C’est là le pari qui a été fait.

Mais quel framework utiliser ?

L’état de l’art

Le choix du framework agile est prépondérant et dépend souvent de la maturité de l’organisation et de ses objectifs spécifiques. Parmi les frameworks les plus reconnus, on trouve Scrum, Kanban, SAFe (Scaled Agile Framework), LeSS (Large Scale Scrum) ou et ceux inspirés du modèle “Spotify”. Chacun offre des avantages distincts. Scrum est très cadré et plutôt adapté à des équipes de delivery, tandis que Kanban se prête mieux aux environnements nécessitant une gestion continue des flux de travail. SAFe et LeSS sont quant à eux conçus pour les grandes organisations cherchant à appliquer l’agilité à l’échelle.

Il est essentiel d’évaluer ces frameworks non seulement en fonction de leur popularité, mais aussi de leur adéquation aux besoins particuliers de l’organisation.

Et si le chemin était plus intéressant que la destination ?

Comme déjà évoqué précédement, il est essentiel dans le cadre d’une transformation que l’organisation crée un mouvement collectif auprès des collaborateurs, afin qu’ils ne subissent pas cette transformation comme une contrainte, mais plutôt qu’ils l’embrassent et se l’approprient.

La transformation agile n’est pas seulement une destination, mais un voyage continu. Ce processus de transformation offre une occasion unique de réévaluer et d’améliorer les pratiques existantes, de renforcer la culture organisationnelle et de créer des liens plus solides entre les équipes. Au fil du temps, les organisations découvrent souvent que les bénéfices vont au-delà de la simple amélioration des processus de développement. Elles réalisent une meilleure cohésion d’équipe, une plus grande transparence et une culture d’apprentissage et d’innovation permanente. Chaque défi rencontré sur ce chemin est une opportunité d’apprentissage et de croissance.

Ainsi, il a semblé plus pertinent à l’entreprise de proposer une adaptation de différents framework qui seraient plus adaptés aux particularités de son activité. Sachant pertinemment qu’ils n’allaient pas inventer une nouvelle roue, ils ont considéré (à juste titre) que le chemin emprunté était autant intéressant que la destination souhaitée. La transformation ainsi proposée n’a pas été une révolution au sein de la DSI, mais plutôt une évolution dans la manière d’instruire les sujets. Mais comment intégrer une nouvelle approche en termes de conception, de pilotage, de trajectoire sans métier ? “c’est impossible !! “ diront les moins enthousiastes. Et pourtant, c’est ce qui a été réalisé.

Le fait maison

L’équipe chargée de la stratégie de transformation avait un double objectif : Transformer la manière d’appréhender les projets IT, et revoir le modèle managérial de la DSI. Les plus aguerris d’entre nous dirons que c’est souvent une mauvaise idée d’entamer plusieurs évolutions en même temps, et ce pour plusieurs raisons : 

• Il est compliqué de savoir qui porte réellement les évolutions adressées, et donc de mesurer leurs effets concrètement.
• D’autre part, dans le cas où les transformations détériorent profondément le fonctionnement de l’entreprise, on a du mal à en identifier les raisons.
• Enfin, ce choix augmente le risque d’échec et d’incompréhension du framework ainsi proposé aux facilitateurs de cette évolution.

Mais au delà de ces écueils, adopter un framework “maison” propose d’autres avantages : 

• Une appropriation plus profonde des nouveaux processus utilisés.
• Une acculturation, liée au fait que chaque collaborateur a la possibilité de faire valoir son approche, et sa méthode de travail. Ainsi, nous réduisons le risque de disposer d’un framework hors-sol, ou trop éloigné de l’activité concrète de l’entreprise.
• Et enfin, la valeur la plus importante est la compréhension du “WHY”; Pourquoi faisons nous ceci ?
  • Qu’apporte un daily avec des collaborateurs que je vois déjà chaque jour ? 
  • A quoi sert la rétro si cela n’est que de pointer régulièrement les manquements de l’entreprise dans son organisation ? 
  • Comment ne pas ressentir la review comme un “contrôle qualité” de la part de ma direction ? 

Comme en amour, ce qui est important ce sont les preuves

Dans une démarche de transformation agile, il est essentiel de se baser sur des données factuelles, plutôt que sur des sentiments, ou des impressions.
A ce titre, il existe une infinité de métriques susceptibles d’être utilisées par la suite. Mais au delà de la quantité, au delà du type de métrique, il est important de garder en tête le “mantra” suivant : 

Si une métrique ne permet pas de prendre une décision, alors elle ne sert à rien

En d’autres termes, ce que vous mesurez doit vous permettre de prendre une décision éclairée. La métrique n’est pas une fin en soi, c’est un moyen pour aider les équipes à comprendre les faits, afin de les aider à prendre des décisions. Une fois cela posé, reste la question de ce qu’on va mesurer.

KPI / EMB / OKR ? Kesako

Il existe plusieurs outils de mesure qui ont chacun leurs rôles et intérêts. Nous allons tâcher ici de les comparer afin de déterminer lesquels sont les plus judicieux à utiliser dans ce contexte.

EBM (Evidence-Based Management) est un cadre global permettant de mesurer et d’optimiser la valeur créée par une organisation. Ce framework se base sur l’amélioration continue, les données empiriques et l’optimisation de la valeur à long terme.

Il permet de mesurer des domaines de valeur stratégiques, au-delà des performances purement opérationnelles. Ces mesures sont conçues pour aider les organisations à progresser par cycles d’amélioration continue. Ils aident à répondre à des questions fondamentales telles que :

• Quelle valeur apportons-nous actuellement ?
• Quelle valeur pourrions-nous encore réaliser ?
• Pouvons-nous innover efficacement ?
• Pouvons-nous livrer rapidement ?

Les KPI quant à eux sont des des indicateurs précis de performance qui permettent d’évaluer si une équipe, un produit ou une organisation atteint ses objectifs opérationnels ou stratégiques.

Il faut les voir comme des indicateurs isolés, qui donnent un aperçu d’une performance à un moment donné. Mais comme ce sont des mesures statiques, ils suivent des performances en cours, sans nécessairement inciter à une réflexion sur le potentiel futur ou l’amélioration continue.

Enfin, les OKR sont un moyen de fixer des objectifs globaux ambitieux et d’aligner les efforts d’une organisation, équipe ou individu pour les atteindre, en définissant des résultats mesurables. Les “objectifs” représentent une intention qualitative (inspirante, ambitieuse), et les “key results” des résultats mesurables, spécifiques et limités dans le temps, prouvant que l’objectif est atteint.

Critère	EBM	KPI	OKR
Portée	Stratégique et global	Opérationnel et spécifique	Inspirant et aligné sur la vision
Temporalité	Long terme + amélioration continue	Court à moyen terme	Court terme (souvent trimestriel)
Focus	Valeur et progrès	Performances actuelles	Résultats atteignables
Nature	Cadre global avec plusieurs axes	Indicateurs quantitatifs	Qualitatif + quantitatif
Exemple d’usage	Optimiser la stratégie d’innovation	Mesurer l’efficacité d’un processus	Aligner l’organisation sur des objectifs ambitieux

Que faire avec ces indicateurs ? 

Transformer 1.500 personnes n’est pas une tâche aisée, particulièrement dans un contexte compliqué, concurrentiel et extrêmement contraint par les régulations, la sécurité et la disponibilité. Il a donc été admis très tôt dans le processus que cette évolution sera longue et douce.

Et si il est important de savoir où en est cette transformation, il reste essentiel de pouvoir disposer d’une vue globale, des 1.500 collaborateurs de la DSI afin d’avoir une idée du chemin parcouru, et de ce qu’il reste à faire. Dans ce cadre, il a été décidé d’utiliser une échelle de maturité agile, appliquée à l’ensemble des squads et des tribus de l’organisation, afin de disposer d’une vue claire et consolidée de la portée des actions déjà entreprises.

Cette échelle implique donc que pour passer à l’échelon supérieur, il faut avoir réalisé l’échelon précédent. Cela peut se comprendre dans le cadre de l’évolution d’une unique squad, ou même d’une tribu, mais cela est difficilement applicable à une DSI dans son intégralité. En effet, certaines équipes travaillent en mode “support” avec un flux de demande à prendre au fil de l’eau, là où d’autres sont des “bâtisseurs” de solutions, avec des rythmes itératifs.

Certaines équipes disposent d’interlocuteurs identifiés, là où d’autres sont au service de la DSI, ou d’autres squads.

Ainsi, les différents éléments constituants cette échelle de maturité sont tous associés à un enjeu visé, tels que : 

• La coopération
• l’orientation client
• l’échange
• l’écoute

L’idée ici n’est pas de décrire l’intégralité des échelons de cette grille, mais plutôt d’en comprendre le sens, et de quelle manière elle peut aider les équipes à “devenir agiles”. C’est bien là tout l’enjeu de cet indicateur : Aider les équipes à prendre des décisions, pour améliorer leur fonctionnement, et devenir de plus en plus “agiles”.

Les premiers échelons sont dédiés à la communication de l’équipe, tant d’un point de vue interne que d’un point de vue externe: 

• Est ce que les membres de l’équipe se synchronisent régulièrement, et partagent les différents objectifs qu’ils se sont fixés ? 
• Est-elle en mesure de communiquer correctement avec ses parties prenantes ? 

Les échelons suivants abordent les questions liées à l’amélioration continue de l’équipe : 

• Est elle capable d’inspecter son fonctionnement et son organisation ? 
• Dispose-t-elle d’un temps dédié à l’amélioration de ses pratiques ?

Ensuite viennent les questions autour de son produit et des artefacts qui y sont associés : 

• L’équipe dispose-t-elle d’un backlog clair, priorisé et validé avec les parties-prenantes ? 
• A-t-elle une vision claire et consolidée des grands enjeux et évolutions futurs de son produit ? 
• Est elle en mesure de se fixer des objectifs SMART liés à son delivery régulier ?

Enfin, viennent les questions liées aux interdépendances entre les équipes : 

• L’équipe dispose-t-elle des outils et cérémonies lui permettant de se synchroniser avec les autres équipes ? 
• Les dépendances techniques et fonctionnelles sont-elles correctement identifiées et gérées ? 

Répondre à ces questions permet de disposer d’une vision globale de l’état de maturité des équipes, et ainsi évaluer les actions à entreprendre dans le cadre de la transformation initiée.

Rien n’est définitif, sauf le mouvement.

En effet, il est important de garder à l’esprit que ces indicateurs ont une durée de vie limitée. Les équipes évoluent, le contexte évolue, les demandes évoluent. Ce cadre mouvant nous impose de réfléchir régulièrement à la manière dont nous jugeons les actions passées afin d’adapter les dispositifs et les outils de mesure à ces nouveaux contextes.

Ainsi, cette échelle de maturité évolue vers une grille de maturité matricielle et donc moins séquentielle.
Notre choix s’est orienté vers la grille de “l’agile assessment” de SAFe, et ce pour plusieurs raisons : 

• Regroupée en 7 catégories, elle permet d’avoir une vision assez large des forces et axes d’amélioration de l’équipe.
• Chaque catégorie est associée à une dizaine de questions simples demandant une “note” de 1 à 5 permettant d’affiner le niveau de maîtrise de chaque items.
• Enfin, chaque catégorie est associée à un coefficient permettant de disposer de “poids” différents en fonction de l’importance du critère. 

Les catégories couvertes sont larges et nous interrogent sur les points suivants : 

• Le cadrage du produit, et la capacité de l’équipe à concevoir efficacement les solutions répondant aux besoins exprimés et compris.
• La capacité de l’équipe à découper son travail et à construire les solutions de manière itérative et incrémentale.
• Des questions autour de la gestion du flux de travail, de l’organisation et de la capacité de la squad à planifier ses activités.
• Une partie est également dédiée à aux valeurs et principes de l’agilité. Cela permet de mesurer la compréhension du “mindset” agile et éventuellement d’engager des actions de formations / d’acculturation à l’agilité, ses bénéfices et les moyens de la mettre en place.
• Enfin, les dernières catégories nous interrogent sur la capacité des équipes à s’équiper correctement, tant en termes d’outillage de gestion et de suivi des travaux, qu’en termes d’éléments permettant la livraison de valeur, d’intégration continue et de delivery. 

Cette nouvelle grille permettra aux équipes de s’interroger sur la manière dont ils appréhendent leur rôles, et des éléments factuels d’amélioration de leur pratique de l’agilité.

Comment mettre tout ceci à l’échelle ?

La gestion des dépendances

L’un des plus grands défis de la mise à l’échelle, c’est bien la synchronisation des équipes qui interviennent sur des périmètres fonctionnels communs. Mais avant de s’interroger sur les moyens de gérer ces dépendances, il y a une question essentielle :  “Avant de gérer les dépendances, pouvons-nous les casser ? “

Mais comme le dit notre ami et grand chef Sioux “YakaFaukon”, les choses ne sont pas toujours aussi simples.

L’entreprise à donc organisé des rendez-vous trimestriels de synchronisation appelés “Tribu Planning”. Ces moments d’une ½ journée avaient initialement pour but de synchroniser les tribus avec leurs métiers respectifs, afin de proposer une trajectoire pour le prochain trimestre.

Le problème qui est rapidement apparu est que ces moments initialement organisés pour se projeter dans un avenir proche (un trimestre) sont rapidement devenus des moments de restitution des actions réalisées dans le trimestre précédent.

Il est toujours intéressant, voire important de revenir sur les actions réalisées précédemment. Cela permet de travailler la prédictibilité d’une équipe, d’affiner les options (optimistes ou pessimistes) qui avaient été prises lors de l’engagement, et surtout de s’inspirer pour les actions à venir.

Mais il me semble encore plus important de de se projeter dans un futur “proche”, et cela pour plusieurs raisons : 

• Cela positionne l’équipe dans une démarche positive, en partageant avec tous les objectifs de la tribu.
• Cela permet également d’engager les collaborateurs et d’initier une dynamique de “solution focus”.
• Enfin, cela permet également de partager avec le reste de l’organisation, dont le métier les objectifs de la DSI, afin d’être aligné sur les actions à entreprendre dans les mois à venir.

Le problème de la priorisation

Dans toute mise à l’échelle se pose le problème de la priorisation entre les différents métiers. En effet, lorsqu’on parle de “mise à l’échelle”, on cherche bien à traiter la question des dépendances entres équipes, mais surtout des dépendances entre les différentes directions de l’entreprise. Ces directions ont souvent des enjeux, des objectifs et des critères de priorisation différents.

A ce titre, il est important de pouvoir comparer entre eux les projets candidats et les mettre en regard de la capacité à faire des équipes opérationnelles.

l’entreprise a donc chercher à disposer d’un référentiel commun, afin de pouvoir comparer les différents enjeux des directions entre eux.
Utiliser la valeur business a semblé rapidement faire consensus, et porter une partie de la solution au besoin initial de prioriser les projets provenant de structures et de directions différentes. Mais utiliser uniquement la valeur business n’a pas de sens si on ne la lie pas aux coûts des efforts nécessaires pour atteindre les objectifs.

A ce titre, et pour répondre à cet enjeu, il a été proposé d’utiliser une matrice de calcul intégrant plusieurs éléments qu’on va rapidement décrire ici : 

• La valeur pour l’utilisateur, telle que l’impact du projet sur la satisfaction du client, ainsi que sur la simplification et l’efficacité de leurs processus.
• La valeur pour l’entreprise, telles que les PNB, les gains éventuels, la réduction de l’empreinte carbone, la contribution à la modernisation du SI, la gestion réglementaire et la mise en conformité, sans oublier le risque à ne pas faire.
• Enfin, la valeur stratégique, telle que les liens avec les initiatives déjà en cours pour préparer l’avenir de l’entreprise, et l’alignement avec les innovations inhérentes au marché bancaire.

A partir de cette matrice, les équipes seront capables de sortir une valeur business qui associée au coût de l’effort à mettre en place permettra de comparer les projets entre eux, et donc de les prioriser.

Une transformation agile sans métier : mission vraiment impossible ?

L’histoire de cette banque illustre un pari risqué mais instructif : initier une transformation agile en commençant par la DSI, sans inclure immédiatement les métiers. Si ce choix peut sembler contre-intuitif dans un environnement où la valeur apportée au client final est centrale, il reflète une volonté stratégique : poser des bases solides avant de s’étendre à l’ensemble de l’organisation.

Ce parcours démontre que l’agilité ne se résume pas à des frameworks ou des méthodologies, mais qu’elle exige une compréhension fine du contexte, des objectifs clairs et une capacité à adapter les approches au fur et à mesure. La transformation ici décrite repose sur un cadre évolutif, des outils de mesure pertinents et une dynamique de co-construction, qui ont permis à la DSI de progresser à son rythme.

Cependant, cette approche soulève une question fondamentale : peut-on réellement réussir une transformation agile durable sans embarquer les métiers dès le départ ? Les premiers résultats obtenus montrent que c’est possible, mais avec des limites. L’absence initiale des métiers a entraîné des défis supplémentaires dans la synchronisation des priorités, la gestion des dépendances et l’alignement stratégique global.

En définitive, cette transformation nous rappelle que chaque organisation doit composer avec ses propres contraintes et opportunités. Mais elle souligne surtout que la réussite d’une transformation agile repose sur un dialogue constant entre la vision stratégique et les réalités opérationnelles, ainsi que sur la capacité à évoluer ensemble, dans un mouvement collectif.

L’adaptabilité recherchée dans l’organisation de la DSI n’est pas un simple objectif ponctuel ; c’est une capacité à développer de manière pérenne. Cela passe par une réinvention des pratiques de travail, des outils, des interactions humaines et de la gouvernance. Le but ultime est de créer une organisation capable de s’ajuster aux besoins en temps réel, tout en gardant une longueur d’avance sur les évolutions du marché et les attentes des utilisateurs.

Alors, mission impossible ? Peut-être pas. Mais il est clair que pour franchir la prochaine étape, le métier devra être pleinement intégré, afin de transformer les apprentissages en une véritable agilité à l’échelle de l’entreprise.