Design et agilité : comment concevoir différemment

L’agilité, comme une évidence

Méthodes agiles vs cycle en V

Au cours des dernières années, les méthodes agiles se sont imposées comme des facteurs clés de succès des projets numériques. Remplaçant les approches traditionnelles dites “en V”, dans lesquelles le cahier des charges faisait office de seule vérité, et où la fabrication se faisait en tunnel, elles ont su apporter une vision nouvelle du développement informatique et insuffler un nouvel état d’esprit valorisant les relations humaines et le sens de l’adaptation.

Centrées sur l’utilisateur, les valeurs agiles érigent la transparence, l’amélioration continue et le développement itératif comme des piliers immuables de produits réussis. De nombreuses méthodes se sont construites sur ces valeurs, dont certaines très célèbres, comme scrum par exemple.

Scrum, rituels et rétrospectives…

Cette dernière prône un découpage des besoins utilisateurs en blocs fonctionnels (user stories), formant une liste de tâches priorisées par valeur d’affaire (le backlog produit). La complexité de ce backlog est estimée par les équipes, permettant ainsi de construire un plan de livraison. Le projet est rythmé ensuite par des sprints de développement durant habituellement 1 ou 2 semaines. 

Ces sprints sont entamés par un rituel d’estimation et de planning durant lequel l’équipe s’engage à développer un certain nombre d’user stories, puis se soldent par une démonstration de ce qui a été fabriqué et d’une rétrospective durant laquelle chacun a l’occasion d’exprimer ce qui s’est à son sens bien ou mal passé. 

Dans les méthodes agiles, cette rétrospective est essentielle puisqu’elle permet de dénouer rapidement les points de frustration et met en place une amélioration continue des processus, et donc, in fine, du produit livré.

Le design, le parent pauvre de l’agilité

Alors que les valeurs agiles semblent construites sur-mesure pour les designers, on constate pourtant encore souvent que la phase de design se fait en dehors du projet, créant un silo entre la conception et la fabrication.

Les raisons de cette séparation sont nombreuses, et sont à mon sens, pour la plupart, à chercher sur trois plans : historique, psychologique et organisationnel.

Le poids du design « physique » vs un produit digital

Historiquement, être designer de produit consiste à tout anticiper à l’avance. Il paraît en effet bien difficile de faire évoluer un produit “physique” une fois que les chaînes de fabrication sont lancées. Ainsi, les designers jouent un rôle clé dans le processus de fabrication : une énorme part de la responsabilité repose sur leurs épaules, et l’échec ou la réussite d’un produit leur sera souvent très fortement imputée.

Ainsi s’est créé le mythe du “hero designer”, cette personne un peu géniale, travaillant la plupart du temps seule, capable d’anticiper toutes les étapes de la chaîne de valeur et sachant comprendre aussi bien les attentes des clients que les contraintes de fabrication. 

Le stress, premier ennemi d’un projet numérique

Une autre raison de ce “silotage” est à chercher sur un plan plus psychologique et intangible. Le démarrage d’un projet numérique est toujours porteur d’enthousiasme mais également de stress, notamment pour les donneurs d’ordre. Serons-nous capable de livrer dans les temps et au prix souhaité le périmètre initialement défini ?

À ces questions “opérationnelles”, génératrices de tensions, viennent s’ajouter les questions inhérentes à toute phase de conception : quelles sont les attentes des utilisateurs, quels sont leurs freins, leurs objectifs ? Gérer de front toutes ces interrogations peut rapidement devenir très compliqué pour les équipes, et il peut être tentant de se rassurer en commençant rapidement les développements. 

Dans ce contexte, la phase de design n’est vue que comme un “mal nécessaire” qu’il faut accélérer au maximum afin d’avoir tout le matériel pour lancer la fabrication. Le designer travaille alors seul, avec la mission de faire valider au plus vite les différents composants ou écrans, laissant bien peu de place au fait de répondre aux attentes des utilisateurs finaux.

Le design est le reflet des organisations

La dernière raison que je vois à cette séparation entre design et fabrication vient de silos existant dans les autres équipes, qu’elles soient chez le client ou en interne. En effet, il existe encore de nombreux cas dans lesquels chaque partie d’un projet est à la charge d’une équipe spécifique.

Il m’est arrivé de voir par exemple des cas dans lesquels le marketing était en charge de la spécification fonctionnelle, la communication en charge de la conception et validation des interfaces, puis l’équipe digitale en charge du suivi du développement du projet… le tout avec une Direction faisant la pluie et le beau temps, et capable d’intervenir à tout moment bien évidemment !

Le design peut alors devenir la “chasse gardée” d’une équipe, qui voit là l’occasion d’imposer sa patte sur le projet. En miroir, les équipes en charge du développement peuvent se désintéresser complètement de la conception, puisqu’elles en ont été exclues. Les designers se retrouvent alors pris dans une guerre d’égos et de positions, qu’il est bien difficile de faire évoluer.

Inutile de préciser que dans ces conditions, les attentes des utilisateurs finaux sont là aussi reléguées au dernier plan, chaque service rejetant la faute d’un éventuel échec sur l’autre.

Anatomie d’un produit raté

Même si ce sont des cas extrêmes, j’ai vu ce genre de situations se produire de nombreuses fois, y compris dans des contextes dits “agiles”.

Les résultats de ces phases de design en silo sont très largement insatisfaisants, et ce pour plusieurs raisons : incapacité à répondre à des besoins réels, frustrations pour les équipes, et incapacité à construire une “intelligence” produit. Nous allons détailler ces différents points dans les paragraphes suivants.

Et l’expérience utilisateur dans tout ça ?

Essayons de décrire un projet “classique”, comme nous en voyons trop souvent. 

Tout commence par une phase de recherche, plus ou moins longue, plus ou moins bien faite. Il peut s’agir d’études de marché, de quelques interviews internes ou externes, de présentations mises bout à bout. Ces éléments très partiels construisent un premier tableau, qui, s’il a le mérite d’exister, ne peut pas servir de seule fondation au produit.

Suite à cette phase très en amont, une longue et douloureuse étape de rédaction de cahier des charges (ou d’expression de besoin) s’ensuit. C’est souvent un processus qui demande beaucoup d’énergie, et de nombreuses hypothèses non vérifiées vont peupler ces documents, puis devenir sans que l’on sache trop comment des spécifications incontournables.

Une phase de design va alors commencer, qui va essayer de répondre aux attentes du cahier des charges, et jongler entre toutes les parties prenantes du projet. Cette phase se soldera avec plus ou moins de retard par des validations parfois arrachées aux décideurs parce qu’il faut bien commencer le développement.

Le développement pourra alors débuter, qui fera évoluer le périmètre au gré des semaines, le tout sans la possibilité de repasser par une phase de conception même si le besoin se fait sentir.

Le produit sera enfin mis en ligne, après que plusieurs mois (voire années) se soient écoulés depuis la première idée. Et dans bien des cas, le produit final tombe complètement à côté des attentes des utilisateurs.

En effet, même si les attentes de ces derniers ont été prises en compte, il existe un tel délai entre la conception et la livraison finale du produit qu’il y a de fortes chances que les utilisateurs aient pu changer, que le marché ait pu évoluer ou que des concurrents aient pu émerger. Et qu’en conséquence, le produit livré soit déjà voué à l’échec.

Des équipes frustrées

Une autre conséquence fâcheuse de cette séparation entre conception et fabrication concerne les équipes elles-mêmes. 

Bien souvent, les designers, développeurs, product owners, chefs de projets, scrum masters, etc., sont les victimes d’organisations défaillantes. Et dans un contexte agile, dans lequel la transparence, la capacité d’évolution et la focalisation sur la valeur sont des valeurs clé, il est difficile d’accepter que de tels murs existent entre des métiers qui ont tout à gagner dans le fait de collaborer.

Cela a pour conséquence de créer des frustrations fortes entre les personnes, ces dernières se cristallisant sur une prétendue incompréhension du métier de l’autre. Les designers ont l’impression que les équipes de développement vont dégrader leur travail et les développeurs sont persuadés que les designers sont des créatifs hors sol incapables de concevoir des éléments fabricables.

Ces frustrations se traduisent rapidement par un manque (voire une absence) de communication, et, au final, par une approche détachée de la recherche de valeur. Les designers conçoivent des composants et des écrans à la chaîne sans se poser la question de leur pertinence, les développeurs reçoivent ces derniers comme des demandes décontextualisées, les scrum masters sont focalisés sur les dates de livraison, et la qualité finale du produit est fortement altérée. 

J’ai eu l’occasion à plusieurs reprises de travailler dans des contextes comme celui-ci, et je sais d’expérience qu’il est très long et difficile de défaire ces défiances entre les différents métiers. C’est pourtant nécessaire, car ces dernières risquent de se répercuter durablement sur tous les projets à venir.

Une carte sans boussole

Comme nous l’avons vu plus haut, la latence entre les premiers éléments d’expression d’un besoin et la mise en ligne de la version 1 du produit induit un décalage entre les attentes des utilisateurs et les fonctionnalités proposées par la solution.

Ces décalages, en eux mêmes, sont absolument normaux dans la vie d’un produit. Le numérique nous a habitué à des usages et des attentes qui évoluent très vite, et il est désormais habituel que les certitudes d’hier fassent demain partie de listes d’erreurs à ne pas commettre.

Cependant, sans une méthode adaptée, permettant de mesurer et rattraper ces décalages, ces derniers deviennent de vrais points bloquants mettant en danger la performance économique du produit.

Or, afin de mettre en place ces outils, il faut développer au sein de l’équipe ce qui est parfois appelé le “QI d’un produit”. Cette intelligence collective est nécessaire afin que toutes les personnes impliquées dans la vie de la solution puissent apporter leurs meilleures idées et hypothèses sur les évolutions à mener.

Développer cette intelligence n’est possible que dans le cadre d’équipes pluri fonctionnelles, où tout le monde se fait confiance et où les objectifs et la vision sont communs. On l’aura compris, dans le cadre de projets où la conception se fait à part, il est impossible de partager cette compréhension globale, et donc, de développer ce “QI produit”, ce qui condamnera inévitablement l’équipe à tâtonner en espérant tomber juste un jour ou l’autre.

Il est temps de changer de façon de faire

Il est particulièrement frustrant de voir dans un même projet la mise en place de méthodes agiles et une approche archaïque de la conception. Et même s’il s’avère que mixer agilité et design n’est pas aussi évident qu’il n’y paraît, de nombreuses méthodes existent qui permettent de faire bouger les lignes, étape par étape.

Car s’il y a une approche qu’il faut garder en tête lorsque l’on essaie de faire changer les méthodes, c’est bien celle des petits pas. Vouloir modifier en profondeur des habitudes de manière trop brusque est très souvent un facteur d’échec.

C’est pourquoi cet article vous propose d’aborder le problème de manière évolutive, en piochant les idées qui s’adaptent le mieux à votre contexte. De même, il n’est pas question d’appliquer à la lettre une méthode miracle : c’est l’expérience et le terrain qui feront votre façon de faire idéale. L’idée finale étant de construire de vraies équipes pluridisciplinaires, partageant la même vision, le même objectif et sachant faire évoluer le produit dans les meilleures directions.

Partager la vision : le point de départ

Cela peut paraître évident, et pourtant c’est trop rarement le cas : une équipe efficace doit partager les mêmes informations, les mêmes objectifs et construire une vision commune et comprise par tous.

Il peut être tentant de limiter des connaissances ou informations à certaines personnes, parce que l’on estime qu’elles ne sont pas intéressantes pour tous, mais c’est à mon sens une erreur qu’il faut éviter de commettre. J’ai souvent eu l’occasion, lors d’ateliers de vision, de voir des idées brillantes ou des points de vues complètement inédits émerger de la part de jeunes développeurs par exemple.

Au-delà de cet exemple, j’ai toujours eu des feedbacks extrêmement positifs de la part de tous les participants à ces ateliers, qui étaient ravis soit d’avoir pu  mieux comprendre la vision, soit d’avoir pu la partager plus largement.

Il est à noter que ce type d’ateliers doivent être faits avec le “bon” état d’esprit. J’ai également souvent vu des directions penser créer un moment de partage et de co-construction de vision, alors que l’essentiel du discours était purement vertical, et qu’il ne laissait aucune place à la discussion ou à l’échange.

Alors comment animer un atelier de vision qui fonctionne ? Nous avons l’habitude de le découper en plusieurs parties, inspirées du design sprint. La première étape consiste à définir un objectif très long terme (à plus d’un an) et lister les impacts positifs que cet objectif aura sur le marché, l’entreprise, le produit, etc. Nous avons l’habitude de dire que c’est le moment où on met le chapeau “optimiste”, durant lequel tous les rêves sont possibles. Il est d’ailleurs assez surprenant de voir beaucoup d’équipes se censurer, et ne pas oser imaginer des répercussions trop positives : c’est un des rôles de l’animateur de les pousser à aller plus loin.

Une fois cette vision “blue sky” posée, il est temps de changer de chapeau et d’enfiler celui du pessimiste, ou du moins d’imaginer toutes les “bonnes” raisons qui pourraient faire que cet objectif ne soit pas atteint. C’est le moment où chacun peut exprimer ses craintes, qu’elles soient liées au produit lui même, mais également à l’organisation, au marché, aux compétences…

Afin de dépasser ces craintes et d’en faire des outils de réflexion “positifs”, nous avons coutume de les formaliser en questions du type : “Serons-nous capables de…”

Même si cela peut paraître peu naturel au départ, cette méthode devient vite très puissante et permet d’exorciser les craintes de chacun, ces dernières étant entendues, comprises et prises en compte par l’ensemble des membres de l’équipe. 

Là aussi, il est important de ne censurer aucune crainte. Le produit en lui-même ne résoudra peut être pas une inquiétude, mais il ne faut surtout pas la passer sous silence : c’est la meilleure façon de “sortir” quelqu’un d’un projet et c’est souvent un point qui deviendra bloquant un jour.

Concrètement, voici comment peut se passer cette étape d’objectifs / craintes :

• L’objectif pourrait être : “Nous voulons être les leaders de la vente en ligne de jeux de société”
• Les craintes pouvant se mettre en travers de cet objectif pourraient alors être les suivantes :
  • Gamme de produits : “Serons-nous capables d’avoir des produits qui attirent les clients ?”
  • Marché : “Serons-nous capables de nous démarquer de nos concurrents”
  • UX : “Serons-nous capables de proposer une expérience de recherche et d’achat optimale ?”
  • Positionnement de la marque : “Serons-nous capables de faire la preuve de notre pertinence ?”
  • Organisation : “Serons-nous capables de créer assez de contenus originaux pour nous démarquer ?”
  • Etc.

De nombreux éléments de crainte ne sont pas liés directement au produit. En fait, la plupart seront périphériques, mais si vous voulez intégrer toute l’équipe dans une démarche de compréhension du produit et créer une intelligence commune, il faudra faire en sorte de construire cette vision globale de l’environnement.

Construire une équipe dès le démarrage d’un projet et permettre à chacun de partager sa vision et ses craintes n’est pas si compliqué que cela, ne prend pas beaucoup de temps (l’atelier dont nous parlons plus haut peut s’animer en moins de deux heures) mais permet de créer de l’enthousiasme et faire émerger des discussions extrêmement positives pour la suite du projet.

Construire des hypothèses et accepter l’échec

Ce qui est intéressant lorsque l’on crée des équipes pluridisciplinaires, c’est que l’attente et l’exigence de ces dernières par rapport au produit devient de plus en plus forte. Il est alors très difficile de revenir sur une méthode “à l’ancienne” pour le reste du projet, chaque personne se sentant très investie dans celui-ci.

Une fois que le terrain a été créé par des ateliers de vision, il est temps d’aller plus loin et commencer à bâtir une culture de l’hypothèse et du test de ces dernières. Ainsi, l’équipe devient responsable des choix et des directions prises par le produit de manière collaborative. Les questions soulevées par la conception deviennent l’affaire de tous et ne sont plus limitées qu’aux seuls designers ou product owners.

La méthode Lean UX propose un framework intéressant pour encadrer cette approche par l’hypothèse, qui propose notamment un changement d’état d’esprit important, afin de pouvoir avancer efficacement par la suite : le droit donné à l’équipe de se tromper.

Cela peut paraître anodin, et de nombreux top managers diront que ce droit est inscrit au fronton de leur entreprise : je peux d’expérience vous dire que c’est faux, ou du moins pas compris par les équipes. J’ai en tête plusieurs cas d’entreprises ayant porté des projets voués à l’échec durant des mois (voire des années) simplement parce que personne n’avait senti qu’il avait le droit de dire qu’il s’était trompé, ou du moins que les hypothèses étaient fausses. 

De nombreuses entreprises fonctionnent encore sur le modèle du décisionnaire qui imagine et porte une vision, et qui est payé pour que cette décision soit la bonne. Ce type de fonctionnement rend alors quasiment impossible le pivot ou l’acceptation que l’hypothèse n’était pas juste: ce serait remettre en cause la compétence de la personne qui l’a formulée, et personne n’est prêt à supporter ce rôle (même s’il peut faire économiser des sommes très importantes à l’entreprise).

C’est cette très mauvaise habitude que propose de casser Lean UX, en donnant le droit collectif à l’équipe de formuler des hypothèses et de se tromper. On pourrait même dire que Lean UX donne l’obligation aux équipes de se tromper et d’accepter rapidement de pivoter, car cela prouve que ces dernières sont en train de construire une intelligence du produit, et qu’elles ont une approche centrée sur la valeur et l’utilisateur final.

Concrètement, comment cela se passe t-il ? Lean UX propose le canevas suivant : “Nous pensons que l’utilisateur ne peut pas réaliser cette action, à cause de cette situation ce qui provoque la conséquence négative suivante. Nous pensons que nous pouvons effectuer ce changement ce qui, nous l’espérons aura cette conséquence.

Si l’on applique cette façon de formuler des hypothèses à notre cas précédent (devenir le leader dans la vente de jeux de société), nous pourrions avoir ce genre d’hypothèse formulée : 

Nous pensons que l’utilisateur a du mal à choisir un produit du fait du nombre de nouvelles sorties, ce qui peut créer chez lui l’abandon de l’acte d’achat. Nous pensons que nous pouvons créer un moteur de recommandations, ce qui, nous l’espérons, lui permettra de choisir des produits plus facilement.

L’équipe va alors formuler plusieurs hypothèses soit sur le même thème (pour le même problème, une autre personne peut proposer une autre solution), soit sur des thèmes différents, puis voter pour décider quelles suppositions doivent être testées.

Ce qui est intéressant dans cette façon de formuler des hypothèses, c’est que l’on accepte de ne pas savoir avec certitude le problème à résoudre, les raisons de ce problème et la solution à lui apporter. En tant qu’équipe nous faisons nos meilleures suppositions, mais tant que celles-ci ne sont pas validées ou invalidées elles ne restent que des suppositions.

Cette approche peut inquiéter par les questions et incertitudes qu’elle apporte ; c’est pourtant exactement ce qui fait qu’elle fonctionne. Parce que l’on accepte totalement le fait d’être dans un environnement instable et incertain, on se doit de valider ou d’invalider au plus vite les hypothèses afin de ne garder que celles qui correspondent à une réalité.

En effet, l’incertitude est un danger lorsque l’on essaie de se convaincre que les hypothèses sont une réalité. Chaque fois que l’on croit savoir ce que pense nos clients ou utilisateurs, le terrain nous rappelle durement que nous ne savions finalement pas grand chose…

Ainsi, en créant une équipe qui accepte et célèbre le fait de ne pas savoir, on crée avant tout une équipe qui a soif d’apprendre et de devenir de plus en plus intelligente. Le fait que les hypothèses soient partagées et testées tous ensemble permet également d’éliminer les discussions du type “moi j’aurais fait comme ça”, et crée un état d’esprit collectif très fort. De plus, le fait que ce soit l’équipe qui décide des hypothèses à tester permet de ne pas responsabiliser individuellement des personnes : c’est l’équipe dans son ensemble qui se trompe et qui progresse.

Développer une culture de prototype web, mobile, ecommerce ou IoT

Le corollaire de l’approche par l’hypothèse doit être la capacité de l’équipe à produire rapidement des éléments testables permettant d’obtenir du feedback de la part des utilisateurs. Dans ce cadre, la vitesse d’exécution est un des éléments fondamentaux du succès de la démarche. 

J’ai pu m’apercevoir que la définition d’un prototype pouvait fortement varier d’une personne à l’autre, nous allons donc essayer de proposer une vision qui correspond à l’approche de conception en équipe pluridisciplinaire.

Un prototype est une version jetable d’un produit, permettant de tester rapidement et efficacement la “surface” de celui-ci, c’est à dire l’interface que verra l’utilisateur final. Afin de s’assurer de son efficacité, il doit, d’après moi, avoir les qualités suivante :

• Il doit avoir l’air “vrai” : l’utilisateur, lors du test, ne doit pas avoir à se poser de questions inutiles. Ainsi, les contenus doivent ressembler à ce qu’ils seront à la fin (pas de lorem ipsum et de photos loufoques sur vos prototypes par pitié !), les interactions doivent apparaître naturelles, les enchaînements d’écran aussi.
• Il doit être une façade : l’ambition d’un prototype n’est en aucune façon d’être un livrable final, quasiment prêt à être mis en production. Un prototype n’est que l’illusion d’un produit fini, mais n’en a aucun aspect (contenus non dynamiques, le cas échéant code “quick and dirty”, etc.).
• Il ne doit pas être fabriqué avec les méthodes habituelles : en corollaire au point précédent, un prototype ne doit pas être fabriqué avec les outils utilisés ensuite pour construire le produit. Ces outils, qu’ils servent au design ou au code sont adaptés pour produire des éléments “finis”, pas des solutions jetables. Ainsi, il ne faut pas hésiter à utiliser des outils beaucoup plus basse qualité, permettant d’arriver à des résultats rapidement.
• Il doit se focaliser sur ce que l’on souhaite apprendre : il peut être tentant de couvrir tous les aspects d’un produit dans son prototype. Après tout, si on veut qu’il l’air vrai, il faut que les liens fonctionnent. Le risque de cette approche est de perdre beaucoup de temps à produire des éléments à faible valeur ajoutée. Il vaut mieux alors se concentrer sur les éléments clé, et s’assurer que l’on peut facilement mesurer l’efficacité de ces derniers.
• Ils doivent être accompagnés d’une grille d’interview : si vous voulez pouvoir utiliser efficacement les résultats d’un prototype, il faut absolument accompagner leur découverte par les utilisateurs. Ne laissez pas ce dernier vous donner un feedback “libre”, vous ne pourrez pas utiliser celui-ci de manière optimale. Préférez un guide d’entretien bien structuré, permettant de répondre aux questions que vous vous posez.

Il n’y a pas de nombre limite de prototypes à produire : tant que vous vous posez des questions, vous avez intérêt à les tester auprès des utilisateurs. Ce qu’il est important de garder en tête en revanche, c’est que comme pour la formulation des hypothèses, toute l’équipe est en charge de la production et du suivi de ces prototypes. Apprendre par le test est la meilleure chose que l’on puisse apporter à une équipe pluridisciplinaire.

L’implémentation rapide et efficace d’un produit digital

Bien sûr, bâtir et tester des prototypes ne suffit pas, et il faut ensuite être capable d’implémenter les fonctionnalités validées par les utilisateurs. Lorsque l’on parle de design thinking, la phase d’implémentation est souvent celle qui est laissée de côté, au profit de phases a priori plus attirantes et novatrices, comme l’idéation par exemple. Pour en savoir plus sur l’approche Design Thinking, je vous invite à lire l’article « Comment le Design Thinking peut booster vos projets digitaux ». 

Pourtant tous les théoriciens du design thinking s’accordent à dire la même chose : sans implémentation, toute conception n’est qu’une vague intention. Tant que le « vrai » produit n’a pas été mis dans les mains des utilisateurs, l’apprentissage n’est jamais complet. C’est pourquoi l’équipe doit être ensuite capable de délivrer rapidement des éléments afin d’incrémenter le produit de nouvelles fonctionnalités.

Dans ce contexte les méthodes agiles fonctionnent très bien, mais comme nous l’avons vu plus haut, séparer les équipes en charge de la conception et celles en charge de la fabrication ne produit pas de résultats satisfaisants. Il faut donc inventer de nouvelles façons de travailler ensemble, afin de prolonger l’intelligence collective construite.

Un des premiers points à résoudre est l’intégration des designers au sein des sprints de développement. Ainsi, il est capital que ces derniers participent pleinement à tous les rituels (sprint planning, affinage, rétrospectives…) afin de pouvoir donner leur point de vue sur certaines fonctionnalités ou à l’inverse recueillir des avis différents.

Une fois les designers intégrés au cycle de production, la méthode la plus « simple » à mettre en place pour que ces derniers puissent produire est de les faire travailler avec un ou deux sprints de décalage par rapport à l’équipe de développement. Ainsi, une fois construites les fondations de la conception du produit (notamment via les prototypes), les designers vont, pendant leurs sprints, produire et valider les composants nécessaires pour alimenter les sprints de développement.

Cette méthode est intéressante car elle permet de se focaliser sur les éléments nécessaires et qu’elle permet d’accélérer les validations, ces dernières étant plus circonscrites que dans le cas d’une conception complète à valider en amont.

De même, cette méthode permet de reporter au sprint suivant la conception de composants qui demanderaient plus de temps pour être validés. Enfin, elle offre une capacité primordiale dans un projet agile : celle de pouvoir « changer d’avis » si le marché le demande, et pouvoir produire des composants de qualité répondant aux attentes.

Cependant, même si cette méthode fonctionne et qu’elle fait ses preuves, elle a le défaut de recréer une distance entre équipes de designers et développeurs. En effet, même si ces derniers se rapprochent, ils travaillent en décalage et les interactions entre eux sont réduites.

Une autre approche, plus complexe à mettre en place, consiste à créer un développement à double voie. Le fonctionnement est le suivant : l’équipe dans son ensemble est responsable d’une voie de « recherche » et d’une voie de « fabrication », et elle alterne des moments de validation d’hypothèses et des phases d’implémentation. 

Cette approche est idéale pour conserver et faire grandir l’intelligence collective, mais elle est beaucoup plus complexe à mettre en place et est plutôt adaptée à des contextes de fabrication et d’évolution de produits sur le long terme.

A vous de jouer !

Alors, prêts à construire une équipe pluridisciplinaire, capable de relever les défis d’innovation d’aujourd’hui et demain ?

S’il faut retenir un point de cet article, c’est de toujours privilégier l’approche des petits pas, et ne pas sous-estimer les écarts culturels qu’il peut exister dans une entreprise dès que l’on touche à la transformation digitale. Lorsque l’on s’intéresse de près aux méthodes agiles, lean UX, design thinking, etc., il peut être tentant de vouloir imposer ces dernières à des organisations qui n’y sont pas encore prêtes.

Ainsi, mon conseil est de prendre le temps, s’assurer que tout le monde est bien “embarqué” dans la méthode et que chacun en comprend les bénéfices. J’ai l’habitude de commencer par des “coups d’éclat” : des ateliers très concrets, des retours d’expérience, etc. Essayez également de trouver des alliés dans cette démarche. Ils n’ont pas besoin d’être rompus à ces méthodes, mais tentez de repérer les personnes qui partagent le même point de vue sur le fait de travailler en équipe, de partager en transparence les objectifs, etc. Ces personnes sont souvent un relais nécessaire et évitent de se sentir trop seul lorsque l’on essaie de faire changer les choses.

Enfin, même si cet article propose un canevas pour créer ces équipes pluridisciplinaires, de nombreuses méthodes existent et la boîte à outil est quasiment infinie. N’essayez pas coûte que coûte d’appliquer une approche qui ne correspond pas à votre environnement. Essayez, adaptez, inventez… L’essentiel est d’arriver à faire évoluer les situations de manière positive, la façon d’y arriver est très secondaire !