Mario Esposito — 4- L’importance de l’UX dans un projet agile

Product Design : du Discovery au Delivery, comment concilier UX et agilité ?

Episode 4 avec Mario Esposito : l’importance de l’UX dans un projet agile

Romain Chabbal : Bienvenue dans notre série d’interviews qui visent à explorer les métiers de l’expérience utilisateur et de l’agilité, en creusant notamment l’articulation entre les rôles de Product Owner, de Scrum Master et d’UX Designer.

Nous recevons aujourd’hui Mario Esposito, Coach Agile chez Dynergie, pour nous parler de l’importance de l’UX dans un projet agile.

Bonjour Mario, pourrais-tu te présenter s’il te plait : qui es-tu et que fais-tu ?

Mario Esposito : Bonjour à tous. Je suis Mario Esposito.

Avant dans une autre vie, j’ai été Artiste plasticien, puis Architecte, jusqu’à devenir UX Designer pendant une longue période, ce qui m’a permis de bien comprendre l’importance d’aller bouger les organisations, et c’est donc pour cela qu’aujourd’hui, je suis coach agile.

Un parcours atypique, plusieurs pivotages dans ma vie m’ont porté à comprendre que : c’est la valorisation de l’humain la plus grande des réalisations.

L’UX contribue à définir le “comment” atteindre la vision produit

Romain : Merci pour cette introduction. Alors pourquoi est-ce que l’UX est aussi importante dans un projet agile?

Mario : L’UX, selon moi, c’est indispensable dans un projet agile, même dans un projet tout court.

Dès qu’on commence à créer quelque chose qui doit être en ligne avec les réels besoins de l’utilisateur, on a besoin des UX, on ne peut pas les mettre de côté.

On ne peut pas seulement demander à un expert métier de prendre en charge cette responsabilité, de comprendre quel est le réel besoin des gens pour lesquels il travaille.

Et donc pourquoi l’UX est si importante ? Parce qu’en réalité, une fois que tu as bien défini quelle est la vision du produit que tu veux développer, l’UX te permet de commencer à alimenter un backlog.

Pourquoi ? Parce que c’est une chose de dire où on veut aller, mais c’en est une autre de dire comment on veut y aller.

Et donc l’UX, qu’est ce qu’il fait ?

Il prend en charge toute cette partie recherche en amont, d’aller valider sur le terrain si l’idée géniale à laquelle a pensé le Product Owner, le PM ou le chef de projet — (tu les appelles comme tu veux), si c’est vraiment une bonne idée.

Donc c’est lui qui se charge d’aller rencontrer les utilisateurs, de faire des interviews, de faire des recherches, de valider ce qui est dit par les utilisateurs avec des observations de terrain.

Parce que parfois les utilisateurs, ils essaient d’être extrêmement gentils au moment où tu vas les interviewer, mais ils ne disent pas tout. Et quand après l’UX va sur le terrain pour confirmer les choses qu’il a entendues, il y a souvent des discordances, des surprises, et c’est pour ça que c’est crucial d’avoir des UX dans son projet, pour vraiment bien cerner la problématique.

L’agilité comme moyen pour mieux fonctionner en s’appuyant sur des sponsors internes

Romain : Tu as évoqué d’autres rôles : tu as parlé de PM (Product Manager), de Product Owner. Comment dirais-tu que ces différents rôles s’articulent ensemble pour porter la voix de l’utilisateur?

Mario : Il faut bien différencier quel est le rôle de chacun. Parce que dans les grands groupes, dans ces grosses organisations qu’on a appelé les “organisations dinosaures” dans une conférence que j’ai donné à Agile Grenoble en 2023, les gens sont bien accrochés à leur poste et il y a cette hiérarchie qui parle de tout en haut et qui est habituée à vouloir tout contrôler.

Quand on commence à mettre en place l’agilité, ou quand il y a cette intention de “passer à l’agilité”, il faut déjà bien préciser que l’agilité n’est pas un but, ce n’est pas quelque chose que tu peux atteindre, c’est plutôt un moyen pour mieux fonctionner.

C’est pour ça que ces différents rôles ont une importance capitale à tous les moments d’un projet, pas seulement au moment du Delivery.

Pourquoi ? Parce que si tu veux opérer une vraie transformation organisationnelle, tu dois toucher aussi le haut de la pyramide, parce que c’est eux qui donnent le mandat, la légitimité, la possibilité de pouvoir rencontrer les bonnes personnes, et donc à partir de là, eux, ils deviennent tes sponsors.

Et quand tu as un fort sponsoring, toutes les portes s’ouvrent et toutes les autres catégories commencent à adhérer à ce que dit le leadership.

L’importance de la clarification des rôles

Mario : Mais après, par la suite, c'est à nous, coachs agiles, de bien les embarquer. Et c’est à ce moment-là que commence la partie la plus difficile de l'accompagnement.

Plus l'organisation est grande, plus l'accompagnement va être long.

Pourquoi ? Parce que vous ne pouvez pas dire à quelqu'un qu’il doit changer du jour au lendemain sa façon de penser, de faire, d'agir. C'est impossible.

Nous, ce qu'on va mettre en place, et moi surtout, la partie que j’adore faire, c'est vraiment le lancement d'équipe. C'est cette étape qui permet à tout le monde de trouver sa place, de s’aligner, de parler le même langage.

Je me suis trouvé trop de fois face à des groupes ou à des projets qui échouent.
Pourquoi ? Parce qu'on avait nommé des gens avec certains rôles, et que eux, en toute bonne foi, ils croyaient être devenu un PO, un PM, un Scrum Master ou un UX.

Je vais te donner un exemple pratique de ce que j'ai vécu avec une équipe qui venait se former. On était au moment du lancement du projet, donc il n'y avait pas besoin de beaucoup de gens dans cette équipe. On a nommé un PO qui était côté métier. C'était lui qui devait avoir la vision, délivrer la valeur du produit et faire la priorisation.

Et pour lui permettre de traduire tous ses besoins en langage un peu plus technique, on l'a épaulé avec un “proxy PO”, un terme qui s'utilise beaucoup dans les grands groupes parce que c'est un héritage du chef de projet qui faisait le transition de l’information avec l'équipe de développement de T. M.A qui était complètement délocalisée.

Mais dans le cas de cette organisation-là, c'était nécessaire parce que la tâche demandée au PO était tellement grande et surtout parce que le PO n’était pas sur place. On avait donc besoin de quelqu'un qui permettrait à l'équipe de pouvoir dialoguer de manière plus fluide avec le métier.

Dans cet exemple spécifique, qu'est ce qui s'est passé ? Je me suis retrouvé à être sollicité, parce que j'avais lancé d'autres équipes et que cela avait bien fonctionné: “Mario, viens, ce serait bien de faire avec cette équipe qui se lance la même chose que tu as faite avec l'autre équipe.”

Ils avaient sélectionné une équipe de champions. Des bons profils sur papier, avec beaucoup d'expérience.

Ok, donc j'arrive sur place, avec tout le monde dans la même salle, je fais un atelier en présentiel naturellement, et ce que j'aime faire dès le début, c'est de rappeler les bases, juste pour comprendre si on parle bien de la même chose quand on parle d’agilité.

Et une fois qu'on a fait ce petit rappel, on va rentrer plutôt dans les rôles et les périmètres de chacun.

Un exercice que j'aime beaucoup, c'est la give & take Matrix, qui te permet justement de définir quelles sont les attentes de chaque rôle vis-à-vis des autres rôles, pour définir le périmètre et les responsabilités de chacun.

Et là, la chose incroyable, c’est qu’on a souvent des surprises. Parce que l'interprétation personnelle de son rôle dépend de l'expérience vécue, dans le passé, par la personne sur ce rôle spécifique.

Ce que moi j'appelle PO, ce n'est pas la même chose que ce que tu as vécu sur un projet en tant que PO, parce que tes tâches n'étaient pas vraiment les mêmes, parce que ton contexte n’était pas vraiment le même, ton produit non plus, et par consequence ton engagement n’était pas le même.

Pour moi un PO c'est quelqu'un qui fait partie d'une équipe. Il y est dédié à 100%, et il est capable de rencontrer des utilisateurs en direct. Il les connaît très bien. Par conséquent, il est capable de récolter le besoin, les blocages et l'ambition de ce type d'utilisateur pour pouvoir ensuite délivrer la bonne vision produit à l'équipe et prioriser sur quoi travailler.

Moi je le voyais comme ça.

Mais eux, ils disaient “Mais non, nous on est sur place, mais en réalité on est à 30% ou 40%, on travaille sur 2 autres projets” ou “On n'a pas le temps de faire des déplacements, donc l'équipe, on peut la voir seulement une fois par mois”, et “Quand on est sollicité, vous ne devez pas trop insister parce qu'on n'a pas le temps de répondre tout de suite” etc.

Donc ça c’est la situation dans laquelle on se trouve souvent quand on parle de rôles.

Romain : Ce que je retiens de ce que tu viens de dire, c'est qu'on n'a pas une définition unique d'un rôle et que ce qui est essentiel quand une équipe démarre, finalement, c'est d'être “centré collaborateur”. Donc c'est prendre en compte les membres de l'équipe tels qu'ils sont, avec leur vécu, avec leur propre définition du rôle, pour que tout le monde s'aligne autour d'un vocabulaire commun qui permettra ensuite de mieux coopérer.

Mario : Oui c’est essentiel.

C'est pour ça que c'est indispensable de faire un “kick-off d'équipe”, une réunion d'alignement qui permet à tout le monde de savoir quel est le rôle de chacun, en lien avec le contexte.

Parce qu'on ne peut pas généraliser des rôles. On ne peut pas seulement dire “OK, Mario, on ne peut pas faire la même chose que tu as faite avec l'autre équipe ?” Non, parce que déjà, vous n’avait pas sur le même périmètre. Ce n'est pas la même taille : eux, ils sont 40 et vous êtes 7. Vous travaillez sur quelque chose de plus petit. Eux, ils travaillent sur quelque chose de plus grand. Eux, ils ont un panel d'utilisateurs qui est entre 2000 et 4000. Et vous, vous en avez seulement 200. Donc ce n’est pas le même enjeu, ce n’est pas la même situation.

On ne peut pas prendre une recette de cuisine et l'appliquer à n'importe qui. C'est pour ça qu’on a besoin de refaire à chaque fois ce type d'exercice avec une équipe qui se forme, pour vraiment permettre à tout le monde de bien savoir : OK, qu'est ce que je dois faire ? Avec qui dois-je interagir ? Quelles sont les informations dont tu as besoin ? Comment je dois te les donner ?

Ça, ça permet de bien définir les rôles. Par exemple pour une équipe SCRUM : les classiques PO, Scrum Master, dev, lead dev, devops et UX s’il y en a. Moi je fais toujours en sorte qu’il y ait un UX, c’est la première question que je pose dans un projet.

Ensuite, on peut sortir de l'équipe et identifier qui sont nos sponsors qui vont nous permettre d'aller à la rencontre des utilisateurs.

Designer le workflow de collaboration

R. : Quand tu pratiques ces réunions d’alignement, que chacun peut exprimer la vision qu’il a de son rôle, définir son périmètre et ses responsabilités, est-ce qu’il arrive qu’il y ait des recoupements, des superpositions de périmètres entre différents rôles ?

M. : Ah oui tout le temps [rires].

Et à ce moment-là, ce n’est pas qu’il y a quelqu’un qui tranche, mais on prend conscience, collectivement, que la responsabilité est partagée sur certaines tâches.

Ce sont les participants qui s’en rendent compte par eux-mêmes, quand il y a ces chevauchements de périmètre.

Nous permet de préparer les bases pour les ateliers qui vont suivre. Parce que tout au début, pour notre premier sprint, (je l’appelle “premier sprint” parce que “sprint zéro”, ça n’existe pas, c’est déjà un sprint) : dès que tu forme une équipe, tu commences à faire des sprints. Même s’il n’y a pas d’organisation, le fait de s’organiser, c’est déjà un sprint.

Et donc ce premier sprint, c’est justement pour permettre à chacun de trouver sa place. Et quand on voit, comme tu dis, des moments où deux personnes sont les unes sur les autres et se disent “mais c’est moi qui doit le faire” et “Oui, mais c’est moi aussi qui doit le faire”, nous, on voit tout de suite une opportunité : Ok, ça veut dire que vous avez besoin de travailler ensemble. Pourquoi ? Parce que vous l’avez identifié vous-même, vos périmètres sont strictement liés.

Cela nous amène à définir quel type de cérémonie on doit mettre en place entre ces rôles. À quel moment ? Comment le travail doit-il être organisé ? On essaie de vraiment designer le workflow de comment doit fonctionner l’équipe sur une période donnée. Par exemple, sur un sprint, sur un mois, sur une semaine, on va voir, pour caler les grands rendez-vous de cette équipe.

Donc grâce à ça, ils vont eux-mêmes s’organiser, entre eux, sur la base de leur contexte, de leur pouvoir d’intervention, de leur périmètre. Cela permet de désigner ensemble ce workflow idéal, avec toutes les cérémonies qui vont avec.

La pertinence du duo UX-PO

R. : D’accord, super intéressant. Je voudrais qu’on prenne un exemple concret avec deux rôles que sont le Product Owner et l’UX designer. Tu as dit tout à l’heure que le Product Owner va avoir dans ses responsabilités la qualification du besoin des utilisateurs finaux. Quand on introduit un professionnel de l’UX au sein d’une équipe, il va aussi vouloir endosser cette responsabilité à travers la discovery, la recherche utilisateur.
Dans le guide Scrum on ne fait pas référence au rôle de l’UX : de ton expérience, comment ces deux rôles vont s’articuler ?

M. : La première fois que je me suis confronté à cette situation, c’était à mes débuts dans l’agilité.

Avant j’étais architecte, je l’ai dit, et à un certain moment de ma vie, j’ai pivoté, je suis allé vers le web, donc vers le design d’expérience utilisateur, parce que c’était une évolution fluide, en ligne avec mon parcours professionnel.

Pourquoi ? Parce que quand j’étais artiste, je faisais des choses sur-mesure. Quand je suis devenu architecte, j’ai commencé à travailler d’une manière un peu plus professionnelle. Et quand je suis devenu designer UX, là, je me suis rendu compte que je faisais la même chose : il y a un besoin, on va rencontrer l’utilisateur, on essaie de formaliser ce besoin, de le traduire en quelque chose qui soit testable le plus rapidement possible. Et après on fait des itérations jusqu’à se mettre d’accord sur le résultat final qu’on veut atteindre.

Donc en architecture, c’est la même chose qu’en UX.

Quand j’ai été par la suite débauché par Publicis pour mettre en place un “Service Design”, au début j’étais le seul UX d’une équipe IT de 7 personnes.
C’était moi qui allais rencontrer les utilisateurs pour faire des interviews, pour faire du shadowing, pour voir quelle était la situation sur le terrain, pour savoir quels étaient les grands blocages des utilisateurs, pour matérialiser tout ça avec des maquettes ou wireframes, pour tester, et tout le reste.

Je raconte cette histoire parce qu’il y a les 2 rôles dedans. A un certain moment, quand l’équipe que j’accompagnais a commencé à grossir, de UX-Designer je suis devenu naturellement le PO de l’équipe. Pourquoi ? Parce que je connaissais déjà tout le monde. J’avais accès à la confiance de tous les utilisateurs. Je savais comment les observer et avec le temps, j’avais appris aussi à formaliser leurs besoins.

Donc tout ça dépend de la taille : si on a une petite équipe, souvent l’UX est aussi le PO. C’est 2 rôles sont strictement liés, ils sont complémentaires.

Dès qu’on commence à grossir, on a plus d’enjeux, plus d’utilisateurs, plus de problématiques, et du coup on commence à différencier les deux rôles. Mais le PO et l’UX continuent à travailler main dans la main, parce que l’UX devient presque “l’homme de main” du PO : “Allez, va observer, raconte-moi le monde, qu’est ce qui se passe autour de moi ? Comme ça, en tant que PO, je peux prendre les bonnes décisions”.

Dans Game of Thrones, il y avait le petit oiseau, tu sais, c’était un des conseillers, c’était lui qui était en contact avec le peuple. Dans la culture arabe, il y avait le vizir, celui qui voit les choses, qui voit ce qui se passe en dehors du palais. C’était un conseiller, qui aidait le roi à prendre les bonnes décisions. Donc c’est presque ce rôle-là que va incarner l’UX avec le PO.

Et encore aujourd’hui dans les équipes que j’accompagne, ce binôme PO — UX est celui qui a le plus de rencontres hebdomadaires, le plus de rendez-vous, parce qu’ils travaillent vraiment toujours ensemble.

La communication comme enjeu de passage à l’échelle

Du coup, l’UX comme “les yeux et les oreilles” du Product Owner d’une certaine manière. Tu as parlé justement de passage à l’échelle, des problématiques qui sont posées lorsque les équipes grandissent, lorsque le projet grandit ou lorsque l’organisation est plus grande. Comment est-ce que tu accompagnes cette croissance des équipes ?

Alors quand on parle de croissance d’équipe, il ne faut pas faire l’erreur de se dire :“on a plus d’enjeux donc on va mettre plus de monde”.

Ce qui arrive souvent c’est de se dire “avant on était 5 dans l’équipe et on faisait tourner la boîte, on va recruter 10 personnes pour faire une équipe de 15, et tout ça va tourner plus vite”.

Non, ça risque de faire le contraire. Pourquoi ? Parce que ce qui rentre en jeu à ce moment-là c’est la communication, la multiplication des canaux de communication.

Moins on est, plus l’information passe facilement : on sait mieux ce que font les autres, on a identifié des périmètres spécifiques, la collaboration est directe et rapide.

Si tu ajoutes 10 personnes à l’équipe, qu’est ce qui se passe ? On aura besoin d’avoir des porte-paroles, parce qu’on ne peut pas mettre 15 personnes dans la même salle pour prendre une décision.

J’ai encore rencontré ce cas dernièrement, avec une équipe dans cette situation-là. C’était une ex-équipe de T.M.A. qui du jour au lendemain a dû passer en agile. Il ne savait pas comment faire, il n’était pas du tout accompagné. Le chef de projet est devenu “Scrum Master” du jour au lendemain, mais il n’a rien changé dans sa façon de faire. Dans les réunions, sur les 15 personnes autour de la table, il y en avait 3 qui parlaient et ça ne servait à rien.

Le premier point d’attention quand on passe à l’échelle, c’est de découper. Si on est passé à l’échelle, ça veut dire que notre produit est monté en puissance, il s’est enrichi de plus en plus de fonctionnalités, il répond à plus de besoins, à un plus grand nombre des problématiques des utilisateurs finaux.

Alors pourquoi ne pas catégoriser ces problématiques ?

Je donne un exemple qui est souvent cité, celui de Spotify. Pas pour le modèle d’organisation Spotify, mais plutôt pour le service de diffusion de la musique, un exemple qui fonctionne bien. Au début, Spotify diffusait uniquement de la musique pop. C’était un “mono produit” avec seulement un genre musical. Mais dès que les utilisateurs ont commencé à exprimer leur besoins d’avoir du jazz, du métal, de la K-pop ou d’autres styles musicaux, l’équipe de départ n’était plus suffisante, elle ne pouvait pas gérer un style spécifique et en même temps être pertinente pour d’autres styles.

Et donc qu’est-ce qu’a fait Spotify ? Ils ont justement créé des équipes dédiées. Une équipe pour chacun des styles musicaux. C’est l’idée. Quand tu commences à grandir, à “scaler” un produit, tu dois créer des spécialisations.

Pourquoi ? Parce que déjà les gens sont plus motivés, cela donne plus de sens au produit sur lequel ils travaillent. Mais surtout, cela permet une meilleure collaboration entre les équipes : à un certain moment, on sait ce dont chaque équipe a besoin par rapport à une autre. Par exemple, un système de tag expérimenté pour un style de musique pourra ensuite être réutilisé pour un autre style.

Et plus il y a des dépendances, plus on a besoin d’avoir des équipes transverses. Pour capitaliser, aider, et apporter une expertise de support aux autres équipes.

Cet exemple aide à comprendre que quand on parle de “grandir”, ça ne veut pas dire augmenter le nombre de membres d’une équipe, mais plutôt comment découper le produit que tu veux faire grandir.

La valeur des tests utilisateurs sur maquette

Alors quand une équipe grandit, c’est souvent parce qu’elle crée plus de valeur. Est-ce qu’il t’est déjà arrivé qu’on te demande de démontrer la valeur qu’apportent l’UX à un projet et de quelle manière tu as montré cette valeur?

Là encore j’ai un exemple très pratique : la première fois que j’ai été UX, j’ai dû démontrer la la valeur qu’apportait un UX, simplement avec l’introduction des tests utilisateurs.

Tester avant de faire : c’est la base de l’UX. Tant qu’on n’est pas certain de quelque chose, on continue à tester, à tester, à tester. Une fois qu’on a validé un élément, même si c’est seulement une petite partie de tout ce qu’on a testé, c’est cette petite partie qu’on va mettre dans un MVP, un Minimum Viable Product, pour le livrer aux utilisateurs.

Pour montrer la valeur qu’apporte un UX à une équipe, j’aime rappeler un projet où il y avait des grands chefs qui avaient dit : “on doit absolument faire ça”. Et j’avais dit “non, attention, je ne suis pas très convaincu de ça”, et ils avaient répondu “non, non non, on doit le faire”.

Alors ils ont mobilisé des ressources, ils ont pris du temps, des devs, ils ont commencé à développer leurs affaires dans leur coin. Avant de le mettre en production, j’ai réussi à négocier de faire une demi journée de tests utilisateurs sur ce qu’ils avaient développé.
Et quand on a fait le test, il n’y avait pas un seul utilisateur qui voyait l’utilité de ce qu’on était en train de faire.

Et je n’ai rien eu besoin de dire à ce moment-là : j’ai seulement communiqué le résultat. Et là, le chef, il a compris tout seul : “On a pris 5 devs pendant 30 jours, ils nous ont coûté combien? Ok, on arrête le projet”.

Et tout ça, on aurait pu l’éviter si on avait fait des tests sur des maquettes.

La grande puissance de l’UX, c’est ça : on veut tester quelque chose, on essaie de le désigner le plus rapidement possible, on l’amène à un utilisateur, on observe si ça lui plaît ou pas. S’il dit “non, ça ne me plaît pas trop” : aucun souci, on le jette.

C’est ça un prototype : c’est quelque chose que tu peux jeter, parce il ne t’a pas coûté grand chose..
Et donc pour moi, le meilleur moyen de démontrer la valeur de l’UX dans un projet, c’est le test utilisateur. Parce que tu sais tout de suite si ce que tu fais va être bien ou pas.

Mettre en place un environnement favorable au changement

Super convaincant comme exemple. Alors est-ce que tu as rencontré des obstacles au changement ? Quand tu essaies d’amener ces pratiques, est-ce que tu rencontres des personnes qui sont réticentes à mettre en place ces pratiques, comment tu abordes cette transformation?

Les blocages, tu les as tout le temps. Parce que dès que tu commences à parler de changements, les gens font comme ça [il recule en arrière].

Tu dois imaginer : je travaille dans la même boîte depuis vingt ans, j’ai toujours fait comme ça. Ok, j’ai mon confort, j’ai mon grand bureau, et du jour au lendemain, tu me dis “allez, on casse toutes les barrières, on va travailler en open space”. Et dans ta tête tu te dis : Mais pourquoi dois-je me mélanger aux autres ?

Oui, c’est une sorte de parodie extrême, mais juste pour te faire comprendre que tu ne peux pas imposer le changement. Parce que si tu essaies d’imposer quelque chose, ça ne marchera jamais.

Et donc le grand travail que fait un coach agile, c’est de faire comprendre l’intérêt du changement. Et pour faire comprendre l’intérêt de ce changement, j’utilise beaucoup les Serious Games. Pourquoi ? Parce que le jeu te permet d’expérimenter quelque chose. Et grâce à l’expérimentation, tu vas vivre une expérience. Et quand tu vis une expérience, tu arrives plus facilement à avoir une prise de conscience : il y a quelque chose dans ta tête qui commence à bouger et à ce moment-là, tu dis “ah c’est pas bête cette nouvelle méthode, on pourrait le faire, on peut essayer”.

Et donc la meilleure façon pour faire accepter le changement, c’est de commencer par poser le bon cadre. Et le bon cadre, ça veut dire quoi? Ça veut dire mettre en place une sûreté psychologique, mettre en place un environnement qui est favorable à l’acceptation de l’erreur.

Pourquoi les gens ne veulent pas changer ? Parce qu’ils ne veulent pas se tromper. Parce qu’ils savent ce qui fonctionne aujourd’hui, mais ils ne savent pas si la nouvelle organisation que tu vas proposer va fonctionner ou non. Et donc ils n’ont aucune maîtrise sur ce que tu proposes et c’est ça qui leur fait peur.

Et la peur, c’est une des émotions les plus fortes de blocage de l’être humain, parce qu’on a encore un cerveau reptilien qui est toujours là pour nous alerter des dangers autour de nous. Et quand tu parles de changement, c’est un danger pour le cerveau, parce que ça veut dire sortir de sa zone de confort.

C’est pour cela qu’un changement, il faut le faire vraiment graduellement, il faut le faire accepter par les autres, avec cette prise de conscience, avec le temps, petit à petit, en démontrant au fur et à mesure quelle est la valeur que cela apporte de faire différemment.

L’état d’esprit agile

Merci Mario pour ces conseils. Il y avait un thème qui te tenait à cœur et que tu souhaitais aborder aujourd’hui.

Oui, je voulais parler de l’incompréhension de l’agilité dans un projet. Quelle est la place de l’UX et de l’agiliste?

Pour moi, l’agilité, ce n’est pas quelque chose qui arrive au moment du delivery, qui se réduit à produire du code. Ce n’est pas ce qui te permet d’aller plus vite, d’avoir une vélocité constante de l’équipe.

Pour moi, l’agilité, c’est avant tout un état d’esprit. Et c’est ce que je vis aujourd’hui, vu que je fais partie de pas mal de communautés agiles. Ce que j’adore avec ces communautés, c’est avant tout l’envie de partage, l’envie de se rencontrer, l’envie de grandir ensemble, d’expérimenter et de vraiment valoriser les autres en continu.

Il y a une énergie, une force entre Agiliste.

Comme quand on participe aux Agile Game Alpes et France, c’est quelque chose d’incroyable parce qu’on est vraiment un petit nombre : on est 100 pour l’Agile Game France et 80 pour l’Agile Game Alpes. On passe 2, 3 jours ensemble dans un endroit. Souvent on a un espace à disposition seulement pour nous et pendant 2, 3 jours, on joue, on fait des mini-conférences, on discute beaucoup, on invente des choses et ça nous permet vraiment de nous booster, nous les agilistes, pour le reste de l’année. Parce qu’on repart avec une mallette d’outils bien chargée, avec des choses qu’on va par la suite expérimenter pendant un an avec nos équipes qu’on accompagne.

Et donc on revient l’année d’après avec plein d’expériences qu’on va partager avec les copains. Et c’est la même chose pendant les Agile Tours/Villes. C’est pour ça que souvent, un coach agile est aussi speaker dans les Agile Tours, chose que j’ai commencé à faire l’an dernier.

Alors tout ça, c’est pour te faire comprendre quel est cet état d’esprit duquel je me sens faire partie de l’agilité. Et c’est ce même état d’esprit que je veux transférer aux équipes que j’accompagne.

Faire comprendre que s’ils font appel à Mario, le coach agile, c’est pas pour mettre en place la méthodologie Scrum ou la méthodologie Agile. Quand j’arrive, je suis là pour faire en sorte de mettre en place une collaboration entre les gens, avec l’esprit, les valeurs et les principes du manifeste agile.

Et donc, en réalité, un coach agile. Il n’est pas seulement sur la partie du Delivery, mais il est présent tout au long du processus de formation et d’évolution d’une équipe ou d’une entreprise.

Parce qu’on ne va pas se limiter au terrain. On ne va pas se limiter seulement à l’opérationnel. Nous, on sort de l’opérationnel, on va coacher les managers, on va leur faire comprendre comment ils doivent se comporter, quels moyens ils peuvent donner aux équipes, s’ils veulent vraiment que ces équipes deviennent performantes, quel type d’autonomie on doit leur donner.

Et toutes ces choses là, c’est pas avec la partie Delivery que tu vas le transmettre au management. Et c’est pour ça qu’un coach agile, il est souvent transverse, il n’est pas renfermé dans son équipe, mais il se balade, il rencontre du monde.

Par exemple, aujourd’hui, je suis dans un bâtiment de 9 étages. Quand je suis arrivé la première fois, j’ai eu un choc : les gens, d’un bureau à l’autre, ne se parlaient pas.

Donc qu’est ce que j’ai mis en place? Tous les jours, je faisais tous les étages et je disais bonjour à tout le monde. La première fois que je l’ai fait, les gens se sont dit : “Mais c’est qui lui ?”. La deuxième fois? “Ah encore lui” et la troisième fois “Non mais tu fais quoi toi ?”.

Et c’est ce “qu’est-ce que tu fais toi ?” qui m’a permis de connaître tout le monde. Ce qui s’est mis en place par la suite est extrêmement sympa : je centralise les besoins. J’étais au 9ème étage et il y avait quelqu’un qui avait un problème. Et je pouvais dire : “Je connais quelqu’un qui est au 4ème étage, qui peut résoudre ce problème”. Et la personne me disait alors “oui, d’accord, donne-moi l’email” et moi je répondais “non, donne-moi la main”, et je l’emmenais au 4ème étage pour lui faire rencontrer cet autre collègue.

À partir de cela, je me suis fait connaître, et on a fait la même chose avec les collègues qui sont arrivés par la suite. Maintenant, tout le monde nous connaît dans les 9 étages et c’est comme ça qu’on crée une vraie dynamique : on fait parler les gens [rires].

La force des liens directs

C’est très inspirant ce que tu dis parce qu’au début de l’interview, on a parlé du lien entre l’UX et l’agilité, du lien entre des disciplines, entre des méthodes, entre des états d’esprit. Et finalement, ce que tu dis là, c’est que les liens qui sont les plus précieux, ce sont les liens entre les êtres humains, entre les personnes, et que tout l’enjeu, c’est d’arriver à créer ces liens, à les renforcer et que ça devienne vraiment des liens de coopération au service d’une équipe, au service d’un projet.

Oui, c’est vraiment la base. Les problématiques les plus profondes que j’ai toujours traitées, ce sont des choses qu’on a identifiées pendant les repas, parce que je vais déjeuner avec tout le monde. Quand tu déjeunes, tu vois une autre facette du collaborateur. Ce n’est plus seulement un collaborateur, on devient presque un ami, tu parles d’autre chose. Ça te permet donc de te lier avec cette personne, de comprendre qui elle est en dehors du travail et donc par conséquence d’avoir confiance en l’autre, de savoir quelles sont ses forces, ses faiblesses, ce qu’on partage tous les deux.

À partir de cela, dans la tête des deux personnes qui se parlent, ils se créent des émotions positives qui créent du lien. Cela crée aussi des opportunités, comme “Je sais que tu fais, donc peut être tu peux m’aider à résoudre ça”. Et tout devient plus fluide parce qu’il n’y a plus la barrière de “Je te connais pas, je ne sais pas si tu es capable”. On arrive là encore à casser la peur et à mettre le cadre de sûreté psychologique dont on a besoin pour bien collaborer ensemble.

Oui, ça rappelle un des piliers du manifeste agile qui dit qu’on privilégie les interactions directes et les relations avant les processus et les outils typiquement.

Oui, c’est une des choses les plus importantes.

Les enjeux de l’agilité et UX de demain

Alors on est dans un monde qui évolue, on a des approches qui évoluent. Pour toi, c’est quoi les enjeux du design et de l’agilité de demain ?

L’enjeu de l’agilité, c’est qu’à un moment on arrêtera de parler d’agilité.

Déjà, je le vois aujourd’hui, on parle de moins en moins d’agilité. On fait de l’agilité, mais on ne parle pas d’agilité. Pourquoi ? Parce que malheureusement qu’est ce qui s’est passé ? C’est une histoire que m’a racontée Alexandre Boutin, une référence de l’agilité en France : du jour au lendemain, il y a eu une “hype” derrière le mot agilité, et donc les grandes sociétés ont commencé à demander aux cabinets de consulting de leur envoyer des coach agiles, des Scrum Masters, des PO.

Mais ces grands cabinets, ils ne les avaient pas. Et donc qu’est ce qu’ils ont fait ? Ils ont pris les anciens chefs de projet, lead dev ou autres, ils les ont renommés et ils les ont envoyés en mission. Et ces gens-là, ils ont fait des ravages !

Tellement, qu’avec le temps, il y a eu une énorme démotivation autour de l’agilité. Les gens disaient “Non. Si tu veux mettre en place la chose que j’ai vécue avec l’autre coach qui m’a envoyé telle grosse société, je dis tout de suite non.”

Je me suis déjà retrouvé avec des entreprises qui étaient passées par 4 transformations organisationnelles. Et aucune des quatre n’avait fonctionné. Après ça, c’est difficile de remonter la pente.

Donc pour moi, dans le futur, on ne parlera plus d’agilité, mais d’une méthode pour permettre aux gens de bien travailler ensemble. On verra comment on va l’appeler.

Et pour la partie “expérience utilisateur”, pour moi, c’est quelque chose qui va se professionnaliser de plus en plus, notamment en lien avec la donnée.

Avant, on avait peu de données. Aujourd’hui, on en a de plus en plus, on a des canaux de récolte de données qui arrivent de partout. Je vois vraiment naître une nouvelle figure qui est l’UX de la donnée. Ça veut dire quelqu’un qui est capable d’utiliser cette nouvelle donnée qui n’est pas encore très bien exploitée, et de l’insérer dans tous les processus UX d’aujourd’hui, pour créer des grands systèmes, des grandes cartographies.

Et je sais déjà qu’ils sont en train de réfléchir à ça, parce que je fais partie aussi des communautés UX, et par exemple, une chose que j’ai vu apparaître dernièrement, c’est le puzzle des métiers.

Il y a de plus en plus de “chapitres UX” dans les entreprises, dans lesquels les UX travaillent de manière transverse sur différents projets, parfois très éloignés entre eux. Chacun avec les mêmes étapes pour récolter les informations et pour les formaliser, notamment sous forme de parcours et de personas.

Et qu’est ce qui se passe aujourd’hui ? Vu qu’il y a de plus en plus d’UX dans les entreprises, ils s’attirent entre eux. C’est comme les agilistes : quand quelqu’un passe dans un couloir, je vois tout de suite “lui, il est agile”, tu le sens au nez, et les UX c’est la même chose “lui, c’est un UX” et donc les UX se mettent ensemble.

Et qu’est ce qu’ils font ? Comme les agilistes, ils partagent les informations qu’ils ont, et ils se disent “Ah mais toi tu as travaillé sur ce persona ? Moi j’en ai un qui est strictement lié à ce persona, mais je ne le connaissais pas”. Alors on les met ensemble et c’est comme ça qu’on commence à créer ce puzzle, ce grand système des interactions et des besoins de tous les utilisateurs d’une entreprise, c’est incroyable. Donc là encore, c’est vraiment la gestion d’un volume d’information de plus en plus important.

Le lien avec l’approche Product

Et qu’est ce que tu penses de l’approche Product ? Tu sais, on parle beaucoup de ce rôle de Product Manager, avec cette “approche Product”, qui combine finalement des choses qu’on retrouve dans l’UX et dans l’agilité avec le Discovery, avec le Delivery dont on a parlé tout à l’heure. Est-ce que tu as un mot à dire sur cette approche?

Dans la réalité ils n’ont rien inventé. Ils s’inspirent clairement du Lean Startup, parce que tout part de là. Et l’approche Product, c’est finalement donner le bon nom à une méthodologie.

Parce que si tu regardes, qu’est ce qu’il y a derrière ? Il y a beaucoup d’UX, mais il y a aussi beaucoup de Lean. Et le Lean, ça te permet d’éliminer tout le gâchis qu’on fait dans l’entreprise.

Et il y a beaucoup d’agilité. Pourquoi ? Parce qu’on est toujours là à créer les meilleures conditions possibles, à motiver les gens, à donner du sens, à mettre en place des concepts qui sont issus du Japon comme le Kaizen ou l’Ikigai, qui permettent à tout le monde de s’épanouir dans la chose qu’ils font.

Le Lean Startup, c’est l’approche Product pour moi.

Super intéressant. On pourrait en parler pendant des heures, c’est passionnant de t’écouter. Est-ce que tu veux, pour conclure, faire passer un message à celles et ceux qui nous lisent ?

Prenez des UX, vous allez vraiment réussir vos projets !

L’UX ce n’est pas quelqu’un qui fait des maquettes, c’est quelqu’un qui comprend quels sont les besoins des utilisateurs.

J’adhère à 100%. Merci Mario pour nos échanges et ton retour d’expérience !

Note : tous les dessins sont de Mario.

Envie de prolonger les échanges ?

→ Contactez Mario Esposito : LinkedIn

→ Contactez Romain Chabbal : LinkedIn | Calendly | Site uxShadow