Articles

Vis ma vie de Scrum Master : les enseignements à tirer d’une expérience sur le terrain

En 2019, j’ai eu la chance d’être SCRUM Master et coach agile pour repenser le parcours web de recrutement de volontaires pour des études cliniques menées par un acteur de la cosmétique. J’aimerais partager avec vous les clés de la réussite de ce projet mais également certains enseignements que j’ai tirés de cette expérience. 

 

La phase de cadrage du projet : un incontournable 

Avant le commencement du projet, la phase de cadrage a permis aux 7 participantsdont le client qui était néophyte, de mieux comprendre l’agilité et surtout de cadrer le budget et les délais. 

En amont des sprints prévusont été menés : 

  • Une formation de 2 jours à l’agilité pour l’ensemble des intervenants. Elle a permis au Product Owneraux membres de la DSI et aux utilisateurs clés de comprendre l’état d’esprit agile et le mode de collaboration que nous allions mettre en place avec le rôle de chacun. 
  • Plusieurs jours d’ateliers de vision, personas et story mapping afin d’aligner tout le monde sur les objectifs du produit et de commencer à construire le Backlog Produit. A ces ateliers étaient présents la Product Owner, la Proxy Product Owner, les utilisateurs clés, l’interlocutrice DSI, un UX designer et un développeur. La présence de ces deux derniers leur a permis de capter beaucoup d’informations, de construire une UX Map (ou carte d’expérienceet d’échanger sur des questions ou problématiques techniques qui pouvaient déjà se présenter. 

 

Le Sprint 0 ou la préparation du projet : l’étape primordiale 

L’agilité nécessite de faire une bonne préparation, ou sprint 0, en amont des sprints. Au-delà de la liste des actions à mener, ce sprint a révélé certains points positifs qui ont par la suite permis de mener à bien ce projet. 

 

Réalisation de plusieurs POC

Le projet comprenaiplusieurs points techniques à risque : 

  • Serveur HDS (Hébergement de données de santé) : les données de santé étant des données sensibles, nous avons dû travailler avec des serveurs ayant des contraintes particulières (accès limités, encryptage des données, séparation des données, etc.) 
  • Connexion de notre application à l’agenda Outlook de notre société avec un besoin fort d’écriture dans les agendas demandés par les métiers 
  • Refaire tout le site vitrine de notre client 

Pour essayer de limiter les risques, et surtout ne pas s’engager sans savoir vraiment de quoi il retournaitnous avons réalisé des POC pour les deux premiers points. Ces POC nous ont permis : 

  • De faire en amont le code source de base pour le projet 
  • De vérifier le fonctionnement avec la DSI 
  • De monter en compétence pour l’équipe de développement 

Pour le site vitrine, il se trouve que le site corporate du client venait d’être entièrement refait par SQLI. Nous avons donc étudié le fait de réutiliser son socle technique et de l’adapter à nos besoins : cette opération permis de gagner du temps et du budget pour la partie « application » du projet. 

 

Mise en place des environnement

La gestion des environnements techniques est toujours très consommatrice de temps et d’argent, aussi bien à la mise en place qu’à la maintenance sur le long cours. Nous avons donc décidé de monter en premier un environnement de développement et d’intégration entièrement opérationnel et disponible dès le premier sprint, ce qui nous a offert une visibilité sur le déploiement des suivants. 

 

Réalisation d’une première user story

L’importance de la première US (user story) à faire pendant le sprint 0 s’est confirmée pour ce projet. A partir d’une US très simplenous nous sommes rendu compte de certains problèmes de déploiement que nous avions sur nos environnements (droits d’accès aux serveurs et packaging du produit notamment). Sans cette première US, nous n’aurions jamais pu livrer une seule US en sprint 1 ; n’hésitez pas à la faire ! 

 

Une organisation d’équipe dans l’esprit de SCRUM

L’équipe a su trouver une organisation dans l’esprit de SCRUM. Elle était composée comme suit (avec le temps alloué au projet pour chacun car cela a joué un rôle crucial dans la réussite du projet) : 

  • Un Product Owner (PO) côté client avec 25% de son temps alloué au projet 
  • Un Proxy Product Owner (PPO) avec 100% de son temps alloué au projet 
  • Un UX Designer avec un nombre de jours fixes alloués au projet 
  • Trois développeurs dont deux à temps plein et un à 80% 
  • Un SCRUM Master/Coach agile à mi-temps 

 

Une DSI facilitatrice du projet

Nous avons eu la chance d’avoir une DSI qui a compris l’importance du travail « sans intermédiaire » dans les projets agiles, ce qui nous a permis de travailler directement avec les acteurs des métiers. En effet, nous voyons souvent notre interlocuteur (PO) « métier » être une personne de l’informatique qui fait le « passe plat » entre l’équipe et les acteurs des métiers. La DSI nous a donc fourni un soutien sur les sujets techniques lorsque nous en avions besoin, et le PO du projet était une personne directement du métier. 

 

Le rôle du PO : impliqué et à temps plein ! 

Pour moi, le rôle du PO est souvent sous-estimé en Agile. C’est pourtant lui qui porte le produit et qui définit ce à quoi il va ressembler. Nous avons eu l’occasion d’avoir ce que j’appelle un « vrai » PO ; une personne côté métier qui va utiliser l’application développée, qui connait les métiers et sait où chercher les informations sur les métiers. Notre PO a fait un travail colossal en amont pour définir avec les utilisateurs leur besoin, cadrer vis-à-vis à de la vision (et parfois dire non) et avoir 90% des informations de la user story lorsque nous l’abordions en séance d’affinage. Nous avons gagné beaucoup de temps en allers-retours inutiles et en discussions stériles 

 

L’UX designer: comment l’intégrer?

Vous avez sûrement dû vous poser la question « Comment intégrer les profils « spécifiques » dans un projet agile comme les architectes, les experts ou encore les UX Designer ? »
Le facteur primordial pour le rôle d’UX Designer est de l’impliquer le plus en amont possible dans le projet et tout le long. Dans notre cas, il a été présent dès le cadrage du projet (avant le sprint 0) ce qui a permis: 

  • À notre client de se projeter plus facilement dans le projet grâce à des maquettes en fils de fer. Le client a également pu plus facilement exprimer son besoin grâce à ce travail. 
  • À notre UX Designer de connaitre les besoins et contraintes du client pour proposer le meilleur design et parcours client.   

Pendant le sprint 0, il a travaillé avec nous sur l’affinage des premières US pour qu’il puisse fournir les maquettes dès le sprint 1. Il a aussi défini la charte graphique et les éléments principaux de navigation. Son activité n’est pas constante tout au long du projet : au début, il doit fournir tout le socle de l’UX dans lequel les développeurs n’ont qu’à piocher pour le design des nouvelles fonctionnalités, sauf si un nouveau comportement est attendu. Dans ce cas, une intervention sur ce sujet sera nécessaire. En revanche, je trouve important qu’il soit présent jusqu’à la fin pour garantir la cohérence jusqu’à la livraison du produit final et éviter toute dérive.  

 

Accepter le changement 

Les trois développeurs de l’équipe étaient expérimentés sur les technologies utilisées. Un point qu’il a fallu gérer a été l’acceptation des changements, à la suite des retours utilisateurs ou suite aux découpages des US. Le fait d’itérer sur un écran et/ou une fonctionnalité, de faire une solution simple avant la solution définitive n’était pas bien compris. Il fut crucial de leur expliquer que le but était que les utilisateurs puissent se projeter sur la fonctionnalité futureCette partie de mon job m’a demandé beaucoup d’écoute active, de compréhension des peurs sous-jacentes à ces réactions pour les aider à trouver la meilleure solution. J’ai essayé de ne jamais leur souffler une solution mais de faire en sorte qu’ils trouvent la solution adaptée à leur projet. Ils ont rapidement vu l’intérêt de montrer les fonctionnalités et d’avoir des retours. 

 

La phase projet : au cœur du sujet 

 

Périmètre / Coût / Délais 

La première chose à souligner est que nous avons respecté le budget et le délai ! Le périmètre s’est quant à lui ajusté au fil du projet. Au début, le client a choisi uniquement les besoins « MUST » que nous avons alors affinés sur notre story mapping. A la clôture du projet, en partant du story mapping initial, nous avons réalisé 99% des « MUST », 79% des « SHOULD », 65% des « COULD » et 50% des « WOULD » (méthode MoSCoW) avec le même budget. Comment est-ce possible me direz-vous ? 

Voici les facteurs de réussite : 

  • Une équipe stable et à temps plein pendant tout le projet 
  • L’expérience des développeurs pour proposer toujours la solution la plus adaptée au besoin (et souvent la plus simple) 
  • La réutilisation du socle technique d’un autre site du client qui nous a permis d’utiliser les ressources de ce socle pour des besoins métiers 
  • Le PO à temps plein, impliqué, avec du pouvoir de décision et qui sait dire « Non » 
  • Le travail en amont du PO avec les utilisateurs 
  • Une vision claire et partagée avec tous, y compris avec les sponsors 
  • L’utilisation de Drupal qui a permis une gestion facilitée des droits d’accès aux différents profils 

Si nous regardons le périmètre décrit initialement et le périmètre implémenté, nous nous rendons compte que certaines fonctionnalités n’ont pas été réalisées car elles sont devenues inutiles à la suite des retours utilisateurs. A l’inverse, et pour l’exemple, une démonstration nous a mis en lumière que le collaborateur à l’accueil du centre avait besoin tous les jours du planning des RDV pour faciliter l’accueil des volontaires, besoin qui n’avait jamais été évoqué. Nous avons pu ajouter ce retour dans notre backlog et le faire dans le sprint suivant car indispensable pour le bon fonctionnement de l’application. 

 

Le plus important d’abord 

Avec un projet agile, la priorisation doit être axée sur le plus important d’abord et non le plus compliqué ou risqué. Nous en avons fait l’expérience : un besoin primordial exprimé par les utilisateurs était la possibilité pour l’application de se connecter à leur agenda Outlook pour pouvoir lire leurs RDV et inscrire les nouveaux pris par les volontaires pour participer aux tests cliniques. Nous avions donc mis les US sur ce sujet dès le deuxième sprint. Malheureusement, suite à un problème sur l’accès sécurisé à Outlook, nous n’avons pas pu réaliser ces besoins qui se sont vus repoussés en sprint 6 (sur 8). La conséquence a été double : 

  1. Nous avons dû avancer en imaginant la solution pendant 4 sprints, ce qui a été un changement de priorisation énorme pour le PO. Nous avons dû également développer des solutions alternatives en attendant d’avoir la solution Outlook pour pouvoir tester et avoir un logiciel opérationnel ; solutions qui ont bien sûr été défaites par la suite. 
  1. Lorsque la solution Outlook a pu être implémentée, nous avons découvert plein de petites subtilités ou de problèmes sur les fonctionnalités liées, ce qui nous a demandé un important travail de tests, d’ajout d’US pour aménager les besoins pourtant validés par les utilisateurs aux nouvelles contraintes.  

 

Attention aux tests 

Une autre leçon que je retire de ce projet est l’importance des tests. Souvent en agile, nous négligeons un peu les tests car nous faisons les fonctionnalités au fur et à mesure. C’est là où des tests automatisés pourraient être fort utilesDans notre cas, les critères d’acceptation étaient bien notés dans les US, mais il manquait des tests plus globaux (ou TNR – Test de Non Régression) pour vérifier que l’ajout de ce besoin à la fonctionnalité globale ne l’avait pas altérée 

Nous avions également prévu des tests métiers mais ceux-ci ont été réalisés avec un décalage d’au moins un sprintdu fait du manque de temps de la part de certains intervenantsLa conséquence a été de voir des anomalies ou nouveau besoin tardivement et de devoir les gérer dans l’urgence lors des derniers sprints, mais tous les retours pertinents étaient pris en compte. Bref, une attention toute particulière sur les tests en général est à avoir en agile (et même en cycle en V) en gardant en tête le dicton « Just in time and just enough » (« Juste à temps et juste ce qu’il faut ») 

 

Si c’était à refaire, je préconiserais les points suivants : 

  • Ajout de tests automatisés sur les fonctionnalités clés 
  • Systématisation des TNR 
  • Implication et dégagement du temps des métiers pour faire les tests « Just in time » 

 

Implication des métiers  

Les utilisateurs finaux ont été identifiés très tôt et nous avons tenu à ce qu’ils soient présents aux différentes cérémonies et aux tests. Nous avons ajouté des ateliers spécifiques avec eux en milieu de projet pour : 

  • Leur rappeler l’importance de leur rôle 
  • Leur demander si notre façon de communiquer avec eux était satisfaisante ou non et comment l’améliorer 
  • Leur demander quels sont les nouveaux besoins qu’ils ont identifiés aux vues des précédentes démonstrations. 

Une implication forte de la part des intervenants métiers est primordiale pour la réussite d’un produit car sans eux nous ne pouvons que faire « un produit » et pas faire « LE bon produit ». 

 

Rédaction des spécifications

Attention, je vous vois venir en me disant que nous avions des spécifications donc nous n’étions pas tout à fait en agile ! Et bien si, car nous avons rédigé des spécifications non pas en amont des US pour dire à l’équipe de développement ce qu’il fallait faire, mais en aval de la discussion que nous avions eu lors de l’affinage de l’US. Ces spécifications servent uniquement pour la maintenance et les futures évolutions du produit. 

Il y a eu deux types de spécifications rédigées pendant ce projet : 

  • Les spécifications techniques que la dev team a produites tout au long du projet soit dans l’US elle-même soit lors du sprint N+1 sur les US terminées du sprint précédent. 
  • Les spécifications fonctionnelles qui ont été rédigées par moi-même sur les deux derniers sprints et sur les 2 premières semaines de garantie.  

Aussi bien l’une comme l’autre, le niveau de détails a posé quelques soucis par la suite (découverte de bugs et de contraintes techniques tardivement) et je pense que nous aurions dû les faire plus au fur et à mesure avec des validations intermédiaires.  

 

Transition avec l’équipe TMA (Tierce Maintenance Applicative) 

Lorsque nous avons démarré le projet, nous savions que l’application allait devoir être maintenue. Nous avons malheureusement traité ce sujet tardivement, ce qui n’a pas permis de fluidifier la passation. L’aprèsprojet doit être géré au plus tôt, ainsi que le transfert de connaissances. La solution idéale pour moi est d’avoir une maintenance gérée directement par l’équipe initiale et qui continue à faire les évolutions.  

 

La contractualisation

Pour finir sur les points positifs, nous avons géré ce projet avec une contractualisation au forfait qui n’a pas été du tout contraignante pour plusieurs raisons : 

  • Aucun suivi à la lettre du contrat quant aux périmètres engagés. Comme expliqué plus haut, nous avons suivi le besoin des utilisateurs tout en gardant en tête notre engagement.  
  • Un suivi financier allégé niveau SQLI puisque nous avions le bon nombre de jours par personne et par sprint pour l’ensemble du projet. 
  • Les indicateurs suivis étaient ceux de l’agilité (nombre d’US dans le backlog/réalisé, nombre de points dans le backlog/réalisé, velocity chart, burndown chart) et aucun engagement n’était fait dessus. 

En conclusion, ce projet est une réussite (utilisateurs satisfaits, client content, projet délivré dans les temps avec le budget respecté et l’équipe Scrum contente de son expérience) malgré quelques écueils grâce auxquels nous avons tous grandi pendant ce projet et tiré des enseignements pour les futurs projets. 

 

Kanban, l’art japonais de l’efficacité pour une TMA agile

Dans un monde digital où la méthodologie Scrum est omniprésente, les équipes TMA (tierce maintenance applicative) sont confrontées à des problématiques bien particulières. Difficile d’appliquer Scrum lorsque l’on gère en parallèle des dizaines de clients ayant tous des demandes de support, d’anomalies et d’évolutions toutes plus urgentes les unes que les autres. Comment construire des sprints avec des tickets qui arrivent au fil de l’eau ? Quand et comment prioriser ? Comment s’adapter rapidement et efficacement ?

 

Nouveau call-to-action

 

Pour moi, la réponse tient en un mot : Kanban.
Cette méthodologie issue de l’industrie automobile au Japon (Toyota) se base sur l’approche Lean. Elle vise l’amélioration continue des processus de production grâce à une méthode de gestion des flux qui permet d’éviter les blocages et de réaliser une livraison rapide et continue.

Kanban n’est pas une solution clé en main mais repose sur 4 principes et 6 bonnes pratiques.

 

Les 4 principes de Kanban

  1. Commencer par ce que vous faites actuellement
  2. Accepter d’appliquer des changements progressifs
  3. Respecter le processus actuel, les rôles, les responsabilités et les titres
  4. Encourager les actes de leadership à tous les niveaux

 

Les 6 bonnes pratiques de Kanban

  1. Visualiser le travail en cours et le processus
  2. Limiter le travail en cours
  3. Gérer et mesurer le flux de travail
  4. Rendre les règles explicites
  5. Implémenter des boucles de feedback
  6. S’améliorer de manière collaborative et expérimentale

Comment bien démarrer ?

  • Il est souvent difficile de convaincre les équipes de changer leurs méthodes de travail. Alors, n’essayez pas d’imposer la méthode Kanban, mais entrainez votre équipe dans ce processus de changement dès les premières étapes.
  • Partez d’un tableau le plus simple possible (avec les 3 colonnes To Do / Doing / Done). Ce tableau évoluera par la suite pour décrire le workflow idéal dans votre contexte.
  • Mettez en place des rétrospectives mensuelles, idéalement avec l’aide d’un coach Agile, pour vous permettre de prendre le recul nécessaire.
  • Rédigez en équipes des règles visibles de tous. N’ayez pas peur des conflits qui résulteront de l’application de ces règles car ce sont eux qui seront à l’origine de l’amélioration.

Vous constaterez rapidement des résultats positifs au niveau des équipes, de la qualité, des délais, du management et des clients.

  • Vous obtiendrez ainsi en un coup d’œil une visualisation globale de l’activité TMA sur votre tableau. Utile pour l’équipe mais aussi pour votre manager.
  • Vous identifierez rapidement les points de blocages et créerez une solidarité au sein de votre équipe pour les débloquer.
  • Vous arriverez à une meilleure prédictibilité de la capacité de production grâce à une meilleure gestion du flux.
  • Des règles connues et appliquées par tous participeront à l’amélioration de la qualité.
  • L’arrêt du multi-tâches permettra une meilleure productivité des développeurs.
  • En définitive une équipe efficace et solidaire pour des clients satisfaits par la qualité et les délais.

 

Pour vous donner une idée, voici un aperçu du workflow mis en place au sein de mon équipe :

Kanban

 

Et après ?

Une fois votre système bien en place, il peut être utile de le digitaliser via un outil tel que JIRA. Non seulement vous rendrez le travail d’équipes à distance possible (difficile de déplacer un post-it par Skype !) mais aurez également une totale visibilité sur les statiques avancées pour valider les améliorations constatées au quotidien.

Nouveau call-to-action

 

Vous souhaitez aller plus loin dans l’apprentissage du Kanban ?

Je vous recommande vivement les lectures suivantes :

Introduction visuelle à Kanban : Tableaux Kanban pas à pas

Une synthèse de la méthode Kanban : Kanban for Software Development

Maitriser la méthode Kanban : Kanban pour l’IT de Laurent Morisseau chez Dunod

Projets digitaux : quand l’empathie se met au service de la technologie

Panacher différentes méthodologies tout en faisant preuve d’une grande capacité d’adaptation… Voilà la clé pour réussir n’importe quel projet digital. Quelle que soit la taille de votre entreprise, il est fort probable que vous suiviez les dernières tendances pour gérer vos projets digitaux. Et de nos jours, la tendance est à l’agilité (@Scale ou « light »). Pourtant, pourquoi bouder les bonnes vieilles recettes ?

 

Le monde digital n’a pas attendu l’agilité

Bien avant l’avènement de l’ère agile, certaines entreprises disposaient déjà de structures organisationnelles qui apportaient une véritable valeur ajoutée sur le marché. Il serait donc dommage de sacrifier cette valeur ajoutée sur l’autel de nouvelles méthodologies au prétexte qu’elles ont aujourd’hui le vent en poupe.

Et l’agilité fut

L’agilité, ou le modèle en cascade (Waterfall), voici des méthodologies aujourd’hui plébiscitées par les entreprises et les digital factories (ces équipes qui utilisent la technologie digitale comme nouveau modèle industriel), convaincues qu’elles sont la clé de leur transformation digitale et de la réussite de leurs projets. Il est cependant important de garder à l’esprit :

  • Qu’il n’existe pas une seule et unique méthodologie pour gérer un projet digital ;
  • Que les modes passent… qu’il s’agisse de modèle en cascade, d’agilité@Scale ou d’autres ;
  • Que le pragmatisme est le seul baromètre qui vaille.

Pour transformer l’essai, il faut dans un premier temps analyser votre organisation informatique interne, définir sa valeur ajoutée et sur cette base, votre propre méthodologie de projet. Vous serez ainsi en mesure d’impliquer les autres services de votre société et de vous assurer qu’ils adoptent bien la méthodologie que vous avez choisie.

Nouveau call-to-action

L’ère du tout numérique ne date pas d’hier

Il est donc important de ne pas oublier qu’un projet digital n’est finalement qu’une façon de réinterpréter ce que l’on connait déjà. Prenons l’exemple de l’industrie de la presse au cours des dix dernières années. Les premiers projets de transformation digitale se sont souvent soldés par un échec, ou une réussite en demi-teinte, d’une part en raison d’une mise en œuvre hâtive et d’autre part, de la croyance selon laquelle les projets digitaux devaient être gérés à l’aide de nouvelles méthodologies (Digital Paradise)… Sans compter l’approche quasi monolithique des prestataires de services informatiques, qui n’a fait que renforcer le phénomène. À force de raisonner en termes de méthodologies et de techniques, les prestataires informatiques perdaient bien souvent de vue le vif du sujet, à savoir, l’importance des contenus (les articles) et la mise en page (le format précis visant à mettre en valeur cette information) … Autrement dit, tout ce qui fait la valeur ajoutée de la presse. Beaucoup de lecteurs se sont alors sentis perdus face à leur « nouveau » journal, car ils ne retrouvaient plus la qualité éditoriale et visuelle attendue. Les acteurs du secteur ont alors dû intégralement remanier de nombreux projets digitaux.

Les règles de l’ère pré-digitale sont encore valables aujourd’hui

L’un des principaux acteurs européens du secteur bancaire a récemment décidé de gérer l’ensemble de ses projets via la méthodologie Agile@Scale. Des années après avoir opéré ce virage stratégique, il en a oublié les clés jadis utilisées avec succès dans son entreprise, et toujours valables. Toute la valeur ajoutée créée par leur « ancien » service informatique, en termes d’organisation, de communication ou de méthodologies de projets notamment, avait été en partie réduite à néant par leur entêtement à utiliser les processus Agile@Scale. Un exemple édifiant où innovation a rimé avec destruction, plutôt qu’avec disruption.

Tout est une question d’empathie

Il n’existe aucune méthodologie vouée uniquement aux projets digitaux. Ces projets, comme tous les autres, nécessitent un savant mélange de différentes méthodologies pour s’adapter à l’entreprise, ainsi qu’une équipe de projet compétente (directeurs de projet, chefs de projet et direction) à même d’identifier la valeur ajoutée qui existe déjà au sein de l’organisation, de la préserver et de l’optimiser.

C’est pourquoi comprendre une entreprise, ses employés et ses process est indispensable à l’heure de choisir les méthodologies à employer pour votre projet digital.  L’empathie… une valeur qui a toujours fait ses preuves.

Be agile or die! Les 5 variables du changement de mindset des entreprises

Be agile or die! Ce crédo est apparu au cours des trois dernières années, avec le changement d’état d’esprit profond en entreprise qui s’est amorcé aux USA et s’est répandu en Europe puis en Afrique. Cette tendance mondiale fait suite aux différents projets de transformation digitale touchant de près ou de loin tous les secteurs d’activité.  

Son impact est tel que certains pays à l’instar de la Pologne ont changé leur politique d’imposition en exonérant les jeunes diplômés de l’impôt sur le revenu. La migration des ingénieurs informaticiens qui sont plus focalisés sur l’expérience de vie et l’épanouissement personnel que la génération de leurs managers dont l’attention est plus portée sur le développement de leur carrière et la stabilité professionnelle. 

Pour faire face à ces changements, l’entreprise doit se remettre en question et amorcer une transformation globale de l’intérieur qui touche tous ses aspects : organisation, politique RH et le plus important : le mindset, l’état d’esprit. 

Cet état d’esprit doit être matérialisé par une organisation qui fait la promotion de : 

  •  L’adaptabilité : le changement n’est plus une variable mais doit être une constante. 

Nous pouvons citer l’adaptabilité par rapport aux changements fréquents des enjeux business et à l’état d’esprit des MillennialsProposer à cette population non plus une carrière et un processus de fidélisation mais plutôt un « contrat » de collaboration gagnant-gagnant est une réponse. 

Face au marché de l’emploil’adaptabilité passe par une démarche proactive et industrialisée qui permet d’anticiper les départs programmés suivant les contrats de collaboration. 

  • La réactivité : face à un environnement mouvant, c’est une capacité incontournable, que ce soit envers les besoins clients ou les aspirations des collaborateurs.
  • Simplicité & transparence : grâce à une organisation plate, des « facilitateurs » leaders au lieu de managers. Ces leaders doivent avoir un rôle, une mission et des priorités clairement définies.
  • Performance & plaisir : bien que l‘entreprise ne doit pas perdre de vue ses objectifs de performance, le plaisir, le fun et la gamification doivent être aussi au centre de ses préoccupations.
  • L’attractivité :

Elle passe d’abord par l’image d’une entreprise jeunequi propose des espaces de détente et des espaces de jeux (consoles, VR, …). L’entreprise ne doit pas être vue comme un lieu de travail sombre, un lieu de labeur, mais un lieu agréable et coloré, favorisant les échanges et l’épanouissement de chacun ; n’oublions pas que le lieu de travail est le second chez soi. 

L’entreprise doit être en adéquation avec les attentes des collaborateurs en lui apportant des projets riches techniquement, des missions enrichissantes comme des missions à l’étranger, ainsi que des changements au rythme qui leur conviennent. 

Le management, lui, est idéalement de proximité avec un mindset non seulement tourné vers la performance mais qui entre également en résonance avec les Millennials 

 

 

Nouveau call-to-action

Finalement, cet état d’esprit agile doit répondre à des enjeux qui semblent contradictoires mais qui sont en fait très liés : lsatisfaction des clients et l’enrichissement de l’expérience collaborateur au sein de l’entreprise. Via une démarche « Delivery As a Fun Service », on assure un service de qualité qui répond aux enjeux des clients tout en procurant du bien-être et de l’épanouissement de nos collaborateurs.  

 

Un article de Fouad SelmouniDirecteur du centre de service SQLI au Maroc et Mehdi Sijelmassi, Microsoft Skill Center Manager 

Projets Scrum : comment impliquer le client durablement ?

L’agilité est le cadre de travail de tout projet e-commerce, c’est pourquoi elle est au cœur des pratiques SQLI, à travers Scrum en particulier.  Les organisations qui font appel à nous sont expertes de leurs métiers, mais pas toujours des technologies web et du cadre Agile. Le client est généralement novice sur le sujet. Pourtant, il est essentiel au succès d’un produit conçu en Scrum

Comment lui expliquer le rôle des parties prenantes et surtout le rôle clé du Product Owner (PO pour les intimes) ? Comment lui donner les moyens de tenir son rôle et de progresser tout au long du projet ? Comment compenser les inévitables insuffisances ? 

Dans les faits, ce que nous appelons dans notre jargon « manque de maturité client », est classé comme « risque » en début de projet et partagé avec lui. Cette étape assurément nécessaire reste insuffisante. Encore faut-il définir les actions pour que le risque soit au mieux évité, et au minimum réduit.  

 

Que faire pour engager le client dans un projet Scrum ? 

L’engagement est une valeur Scrum qui doit tout particulièrement être transmise au client. Son engagement, surtout en tant que PO, est indispensable tout au long du projet. 

Tout d’abord, il faut veiller à ne pas sous-estimer le travail que cela va représenter pour le Chef de Projet ou le Business Analyst ; sur tout un projet, il peut se traduire en jours. Il faut l’anticiper en termes de planning, car en plus de ses tâches habituelles, le Chef de Projet/ Business Analyst devra former à l’utilisation doutils, éduquer au vocabulaire (« sprint »« backlog »« review » …) et s’assurer que le client est invité et participe aux événements. Expliquer les grandes lignes de l’agilité est certes utile lors d’un kick-off, mais doit être doublé de ce que l’on pourrait appeler une formation continue jusqu’à l’accomplissement du projet. 

Inviter le client aux sprints reviews est essentiel, il sera là dans son rôle de partie prenante. C’est le plus évident de son point de vue et là ne réside pas la difficulté.  

La difficulté réside dans le rôle du PO, qui n’est pas (seulement) un testeur de livrable, sollicité une fois en atelier de spécification puis une autre fois après livraison. Cette approche correspond plutôt au fameux cycle en V (ou cascade), où client et agence se rencontrent deux fois dans le projet. Evitons le piège qui consiste à reprendre ce fonctionnement, en le déportant simplement de l’échelle du projet à l’échelle du sprint.  

Impliquons nos clients à tous les événements qui requièrent le PO : sprint planning, sprint rétro et bien sûr sprint review (auxquels on invitera aussi les parties prenantes). Impliquons aussi davantage le PO hors événements pour valider avec lui les choix fonctionnels et techniques. Plus il sera invité, plus il sera présent, plus il sera engagé. 

Et si le client manque de temps ? Souvent sollicité sur d’autres tâches, parfois absent (maternité, maladie…), il ne peut assumer ses fonctions en tout ou partie. Il me semble illusoire d’imaginer que l’accompagnement suffise toujours. Qu’avons-nous constaté sur nos projets ? Le Chef de Projet/ Business Analyst est intervenu comme filet de sécurité et a pris en main une bonne partie du rôle de Product Owner. 

Bien sûr, cela permet au produit d’être livré, mais est-ce l’idéal ? 

 

Un Product Owner : pourquoi en avons-nous besoin ?

Pas de produit réussi sans Product Owner présent et actif du premier au dernier sprint.  

Que se passe-t-il sur un cycle en V ? La fonctionnalité est spécifiée, puis développée, puis livrée. Résultat : beaucoup d’insatisfaction des utilisateurs finaux qui n’utilisent pas ou peu les fonctionnalités. Et de la déception côté client lorsqu’il découvre le livrable, pas forcément tel qu’il l’avait imaginé. Souvent aussi du retard dans le planning lorsqu’il faut revoir le développement. 

Pour éviter cet effet de (mauvaise) surprise à la livraison, Scrum implique le client durant tous les sprints. Un PO droit dans son rôle ne devrait jamais être surpris en review. Voilà le gain pour les clients et la raison pour laquelle les équipes SQLI choisissent Scrum. 

A nous, et surtout au Chef de Projet, d’être le porte-parole de ce type de bénéfice auprès du client. 

Allons plus loin, faisons de l’itératif ! 

 

Le manifeste Agile met en avant les individus et leurs interactions. SQLI ne peut pas être agile seul ; l‘interaction avec le client est fondamentale. Nous avons besoin des meilleurs PO. 

Comment y parvenir ? Comment améliorer l’implication de nos clients au quotidien ? Comment assurer un accompagnement de qualité pour leur transmettre notre expertise ? Soyons Scrum et posons-nous ces questions de manière itérative, à chaque rétro de sprint par exemple, et bien sûr à chaque bilan projet.  

Pour nous améliorer continuellement.  

5 raisons de digitaliser ses pratiques agiles

La digitalisation est au cœur de la transformation de bon nombre d’entreprises. La méthode Agile est souvent proposée comme la solution pour y arriver car elle permet de s’adapter rapidement aux changements des besoins des clients. Pour autant lorsque l’on parle d’agilité, la première image qui nous vient en tête est de voir une équipe debout devant un grand mur avec plein de post-it. Pas si digital que cela dans les faits. 

La raison principale est souvent une mauvaise interprétation des valeurs agiles et notamment de celle-ci : « Individus et interactions plutôt que processus et outils »Il faut pourtant se dire que ce n’est pas parce que les processus et les outils sont moins importants qu’il faut les négliger. 

 

Voici donc 5 bonnes raisons de digitaliser ses pratiques agiles : 

1.On évite la perte d’exigence  

Toute personne ayant travaillé sur un projet agile en utilisant des post-it s’est déjà retrouvée à les voir tomber par terre. La personne qui le ramasse ne se souvient alors plus forcément de l’endroit où il était. Parfois, ce dernier n’est même retrouvé que tardivement car un meuble le cachait ! 

Le fait d’utiliser un outil pour stocker les exigences règle ce problème. De plus, rien n’empêche d’utiliser un écran ou un vidéoprojecteur pour effectuer les événements agiles depuis l’outil, comme le Daily Scrum. 

 

2.Le reporting au management est simplifié 

Même si la priorité en l’agilité est d’avoir un produit fonctionnel, il n’est pas possible de présenter l’ensemble des fonctionnalités d’un produit au top management. On se retrouve alors à mettre en place des indicateurs d’avancement et il faut parfois beaucoup de temps pour repasser sur l’ensemble des exigences afin de renseigner un fichier Excel avec des données à jour. 

Avec des outils comme Jira, on peut maintenant non seulement gérer du Scrum (méthode agile par excellence), mais aussi générer automatiquement des Burn Up Charts (rapports d’avancement en Scrum). 

 

3.On s’ouvre aux nouveaux modes de travail 

Nous entrons actuellement dans une aire de décentralisation avec un essor grandissant du télétravail, aussi appelé home office ou flex office.  

Même s’il est préférable qu’une équipe agile soit proche physiquement, l’agilité doit aussi s’avoir s’adapter à ces nouveaux modes de travail, et l’utilisation d’outils est un moyen de répondre à ce besoin. Il n’y a alors plus besoin de board physiqueil est alors possible de gérer l’ensemble des événements agiles en vidéo conférence. 

 

4.La collaboration sur les projets d’envergure est facilitée 

Lorsqu’un projet devient trop important, il est nécessaire de faire travailler plusieurs équipes de concert. On parle alors d’agilité à l’échelle: plusieurs Scrum teams se partagent un même backlog. 

Chacune ayant ses propres événements, la communication entre elles s’affaiblitAvoir un outil commun facilite alors l’accès aux travaux des autres équipes et incite à aller voir une équipe ayant travaillé sur un problème similaire pour trouver rapidement comment le résoudre. 

 

5.Les actions à faible valeur ajoutée sont automatisées 

Dans tout projet digital, il est nécessaire de réaliser des tâches liées au code sourceSouvent répétitives et chronophages, ces actions n’apportent aucune valeur ajoutée au produit (exemple : gestion des dépôts et des déploiements). 

Une industrialisation de l’ensemble de la chaîne de développement permet cependant de supprimer cette charge de travail et de gagner en productivité. Par exemple, en créant automatiquement une branche de travail lorsqu’un développeur prend en charge une exigence, ou en lançant le déploiement d’une version sur un environnement après la validation d’une revue de code. 

L’utilisation d’outils et de processus apporte beaucoup de bénéfices à l’agilité car cela permet à l’équipe de se concentrer sur ce qui est producteur de valeur pour le produit. De plus, ce n’est pas incompatibles avec les valeurs de l’agilité, tant que les interactions entre les individus restent la clé de voûte de tout projet.

Nouveau call-to-action

L'agence digitale agile : la transformation dans les faits

« The Art of Doing Twice the Work in Half the Time » ou l’art de faire deux fois plus en deux fois moins de temps. Voilà ce que promet Jeff Sutherland, l’un des papes de la méthode Scrum, dans son livre éponyme. Quelle promesse, surtout pour les agences qui ne comptent généralement pas les heures de travail ! Les précurseurs de la communication s’appuient donc depuis plusieurs années sur les méthodes Scrum et Kanban, et la transformation agile est aujourd’hui ancrée dans le quotidien des agences. 

Dans la première partie de notre série, nous avions vu pourquoi la gestion de projet traditionnelle atteint ses limites, y compris dans de nombreuses agences digitales. Mais qu’est-ce que l’introduction des méthodes agiles change exactement ? Les sprints, les réunions quotidiennes face à un tableau blanc et une multitude de post-it de couleurs suffisent-il à rendre une agence agile ? 

 

12 principes du travail en mode agile

Quelle que soit la méthode de gestion de projet choisie, l’agilité repose toujours sur des valeurs et des principes similaires. Le Manifeste Agile peut d’ailleurs servir d’axe et de référentiel. Bien que ce cadre de travail pour équipes agiles ait été défini à l’origine pour les développeurs informatiques, ces 12 principes peuvent facilement s’appliquer à d’autres branches du digital (nous avons remplacé certains termes techniques de l’industrie informatique par des termes plus généraux dans la suite de cet article) : 

1.Notre priorité absolue est la satisfaction du client par la rapidité et la qualité des livrables en continu ; 

2. Les changements d’exigences « à chaud », même lorsque le développement est avancé, doivent être bien accueillis. Les processus agiles exploitent le changement au bénéfice et à l’avantage concurrentiel du client ; 

3. Les livrables doivent être fonctionnels et fournis en quelques semaines ou quelques mois en privilégiant les cycles courts ; 

4. Au quotidien, des professionnels de différents domaines se doivent de coopérer ensemble tout au long du projet ; 

5. Les projets doivent être confiés à des personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour mener à bien leur mission ; 

6. Le dialogue en face à face est la méthode la plus efficace et la plus efficiente pour transmettre l’information à une équipe (et au sein d’une équipe) ; 

7. Des services et produits opérationnels sont la principale mesure de progrès ; 

8. Les processus agiles favorisent le développement durable. Les clients, l’équipe et les utilisateurs doivent pouvoir maintenir un rythme constant sans limite de temps ; 

9. Porter une attention constante à l’excellence opérationnelle et à une bonne conception des processus de travail favorise l’agilité ; 

10. La facili  l’art d’éviter au maximum le travail inutile  est essentielle ; 

11. Les meilleurs processus, exigences et idées viennent d’équipes auto-organisées ; 

12. À intervalles réguliers, l’équipe réfléchit aux moyens d’améliorer son efficacité et adapte son comportement en conséquence. 

 

Ces 12 principes reposent sur 4 valeurs agiles :   

1.Les personnes et les interactions priment sur les processus et les outils ; 

2. Un logiciel opérationnel est plus important qu’une documentation complète ; 

3. La coopération avec le client prime sur la négociation du contrat ; 

4. Savoir réagir au changement est plus important que suivre un plan. 


Scrum, Kanban & Co : les multiples facettes de la gestion de projet agile

La plupart des gens associent naturellement le terme « agile » à la méthode Scrum. Pourtant, nul besoin d’adopter Scrum pour être agile. Cette méthodologie est un modèle qui définit certains rôles, règles et processus.
L’agilité consiste en un code de bonnes pratiques et une culture d’entreprise totalement indépendants de la méthodologie Scrum. Autrement dit, Scrum sans agilité ne donnera rien. Par contre, une approche agile pourra donner de bons résultats sans application d’une méthode Scrum.

De nombreuses agences digitales mettent en pratique Scrum dans leur gestion de projet, d’autres préfèrent Kanban ou optent pour des approches innovantes tels que le Design Thinking et les Design Sprints pour leurs processus créatifs. Au cœur des agences agiles, on retrouve des équipes stables et auto-organisées qui communiquent en harmonie. Elles sont à même d’identifier les problèmes en parfaite autonomie et d’y apporter les bonnes réponses. 

Les méthodes de gestion de projet et les outils agiles utilisés sont d’une importance secondaire et varient d’une agence à l’autre. En général, la plupart des précurseurs de la méthode agile recommandent de ne pas se perdre en règles et règlements, mais de se lancer avec courage et d’adapter, si nécessaire, les processus à son agence. 

 

La véritable agilité est plus qu’une simple méthode  

Ce n’est pas parce que les chefs de projets sont soudain rebaptisés Scrum Master ou Product Owner, et que la masse de travail se répartit en petits sprints, que tous les problèmes et lacunes d’une gestion de projet classique sont résolus du jour au lendemain.
Au sein de l’entreprise et au niveau de chaque collaborateur une réflexion doit s’engager. Sans l’état d’esprit adapté, les processus agiles sont voués à l’échec. La transition vers l’auto-organisation et la responsabilité personnelle, par exemple, n’est pas un processus aussi simple pour tous les collaborateurs. En matière de gestion également, l’abandon des responsabilités et la perte de contrôle est souvent une phase difficile.
La démarche visant à considérer les erreurs comme des opportunités d’apprentissage et à aborder les faiblesses en toute transparence est également un obstacle typique de la transformation agile. Parmi les autres pièges, citons les offres et modèles de facturation agiles, surtout s’il y a un « écart d’agilité » entre le client et l’agence. L’expérience montre que la formulation (et la signature) d’offres non basées sur un cahier des charges bien défini, mais sur des estimations, est difficile pour les deux parties au début. 

Nous savons que la transformation agile d’une agence digitale est un processus qui demande justement de l’expérience, et donc du temps. Et d’ailleurs, nous n’avons pas tout à fait atteint notre objectif non plus, mais les améliorations sont déjà clairement perceptibles.

Nouveau call-to-action

Dans le prochain article de la série, nous partagerons avec vous des détails de notre vision de l’agilité et de la transformation agile en place chez Osudio. 

 

Article écrit par Slawa Baryshev, Coach Agile et Solution Architect 

L'agence digitale agile : prête pour le futur

Mener de front plusieurs projets d’envergure, gérer trois pitchs en attente, intégrer les changements de dernière minute d’un client avant la mise en ligne de son site web… rien de plus normal pour une agence digitale. Face à de tels défis, une gestion de projet efficace est indispensable pour respecter les délais, tenir les budgets impartis, et satisfaire les clients. 

Or l’enjeu est le suivant : à la suite du passage au digital, la structure classique de la gestion de projet en agence atteint souvent ses limites. Dans le contexte mouvementé des avancées technologiques fulgurantes, de l’évolution permanente des attentes des clients et de la concurrence mondiale, ce phénomène touche de plein fouet les agences digitales notamment. 

 

La gestion de projet en agence, une discipline en pleine mutation

Plus le projet est complexe, plus ses exigences auront tendance à évoluer au fil du temps. Et ce, malgré tous les efforts des chefs de projet pour planifier, briefer, organiser et contrôler. Ce phénomène peut s’expliquer par les initiatives de certains acteurs du marché, qui reversent la vapeur avec des innovations techniques permettant de toutes nouvelles fonctionnalités. Oencore, par de premiers retours d’utilisateurs différents de ce qui avait été escompté. 

La technique traditionnelle de gestion de projet « en cascade », avec son plan fixe et ses processus et étapes rigides, n’est pas assez flexible pour faire face à cet  environnement VUCA.
Cahiers des charges, tables rondes contraignantes, phases de validation prolongées et silos de compétences organisés en équipes spécialisées sont autant de process qui ne sont pas adaptés à la souplesse des start-up, ni aux modèles commerciaux disruptifs, pas plus qu’à la dynamique des canaux, plateformes et points de contact modernes. 

Intégrer de nouveaux éléments ou des problèmes inattendus dans un plan de projet complexe est fastidieux et retarde toutes les phases suivantes. Dans le pire des cas, en plus d’entraîner un dépassement des budgets et une prolongation du time to market, cette démarche fait apparaître sur le marché des produits qui ne sont pas (ou plus) nécessaires. 

L’échec de nombreux projets digitaux n’a donc rien d’étonnant. Se borner à suivre des plans de projet validés à un instant T ne présente pas un grand intérêt si l’objectif du projet change plusieurs fois au cours de son évolution. Cela ne conduit qu’à des clients déçus, et à des employés frustrés, car en définitive, ils avaient tout donné pour atteindre les repères fixés. 

 

Pourquoi l’agilité ?

Ne vaut-il pas mieux s’épargner tout le temps passé à préparer une planification détaillée (qui, par expérience, sera de toute façon obsolète au bout de quelques semaines) et démarrer sans attendre, en adaptant le déroulement du projet de manière flexible aux conditions du marché et aux attentes du client ?
De nombreuses agences ont d’ores et déjà testé avec succès cette approche agile.

Avec les méthodologies telles que Scrum et Kanban, ou encore avec le design thinking, la gestion de projet agile s’articule autour de petites étapes partielles, d’un maximum de transparence et d’échanges intensifs avec les équipes et le client. Sur la base d’une ambition définie collectivement, les équipes disposent de la marge de manœuvre nécessaire pour trouver la solution la mieux adaptée à chaque tâche, sachant qu’elles sont aussi responsables de livrer dans les temps un résultat intermédiaire fonctionnel.
 

Téléchargez le how-to guide agilité

 

À intervalles réguliers rapprochés, le client peut se rendre compte de l’état d’avancement du projet et participe à la priorisation des prochaines étapes partielles.
Principal avantage de cette démarche : les erreurs, les impasses et les revirements de situation n’entraînent pas de blocages. Ils guident au contraire pas à pas le projet dans la bonne direction. 

  • Démarrage rapide du projet 
  • Grande flexibilité 
  • Transparence optimale 
  • Workflows efficaces 
  • Culture de l’erreur positive 
  • Transfert optimisé des connaissances 
  • Time to market réduit 
  • Résultats orientés utilisateur 

Parmi les effets secondaires favorables : les équipes qui adoptent une méthode de travail agile sont par expérience plus motivées et plus épanouies. Aussi, de nombreuses agences agiles ont une longueur d’avance dans la « guerre des talents », puisque l’exigeante génération Z attend des modèles de travail modernes axés autour de hiérarchies plates, de l’estime et du sens des responsabilités. C’est-à-dire précisément les conditions cadres induites par la gestion de projet agile. 

Dans le prochain article de cette série, nous présenterons sur notre blog des modèles agiles adaptés aux agences digitales. Nous expliquerons également pourquoi le recours à des méthodes agiles de gestion de projet ne permet pas à lui seul de mener à bien une transformation agile.   

 

Vous souhaitez approfondir le sujet ? Nous sommes là pour vous conseiller. 

[SUCCESS STORY] GENERALI : un espace client omnicanal

Chez Generali France, le client est au cœur de la stratégie digitale, et l’assureur italien s’attache à le fidéliser en soignant l’expérience offerte sur son dispositif. 

 

Success story generali fr

 

Dans une logique de réinvention de la relation client, le Groupe a donc choisi de faire évoluer son espace client et le site generali.fr. 

Découvrez comment Generali France et les équipes SQLI ont pu mettre en oeuvre un dispositif aux parcours enrichis, à la navigation plus fluide, et apportant un meilleur service aux utilisateurs - le tout en méthode Agile. 

 

Téécharger la success story Generali

L’omnicanal à l’épreuve de l’attention des consommateurs

Dire que le digital a bouleversé le terrain de jeu des marques ces dernières années est un euphémisme. L’innovation technologique a accéléré la recomposition du commerce, a estompé les frontières entre le physique et le virtuel, et régit désormais la relation entre une marque et ses consommateurs, au-delà même du produit ou du service qu’elle propose.  

L’attention, ce nouvel eldorado 

Les marques sont entrées dans l’ère du commerce unifié. Une ère où la notion de lieu compte moins que celle de parcours. Où l’expérience d’achat en magasin physique et digital est aussi importante que le service client – 61% des Français sont prêts à quitter une marque si le service client n’est pas à la hauteur*. Où l’enjeu est moins celui d’informer que celui de capter l’attention de consommateurs ultra-connectés – 75% des Français possèdent un smartphone et en font leur première porte d’entrée vers internet** – et par conséquent, ultra-sollicités.  

L’expérience et la personnalisation sont deux facteurs fondamentaux dans la capacité d’une marque à passer de l’indifférence à l’attention. À transformer une interaction furtive en une interaction mémorable. À donner envie aux consommateurs de revenir, encore et toujours, en dépit de nouvelles et incessantes tentations. À l’ère du commerce unifié, l’expérience que proposent les marques doit être persuasive et créer de la confiance. Elle doit accompagner le parcours du consommateur et s’adapter à l’évolution de ses attentes. 

En quête d’agilité 

Ce changement de paradigme dans le secteur du retail a été initié par l’avènement du e-commerce et de la donnée comme outil central de la relation entre la marque et le consommateur. En proposant des catalogues complets et personnalisés, accessibles rapidement, simplement et à tout moment, ainsi qu’un service client ultra-réactif;  Amazon, Alibaba ou encore Google ont fait de l’agilité et du sur-mesure les nouveaux standards du commerce. Des standards qui régissent aujourd’hui les attentes des consommateurs, quelle que soit la nature de leur interaction avec une marque.  

À l’ère du commerce unifié, les marques doivent plus que jamais cultiver leur agilité pour susciter l’attention de leurs consommateurs. Le succès des Digital Native Vertical Brands (DNVB) – Slip Français, Sézane ou Made.com – qui a ouvert une nouvelle voie entre des distributeurs traditionnels et des géants du e-commerce, illustre cette quête permanente. En plaçant le consommateur au coeur de leurs modèles économiques et en enrichissant continuellement l’expérience qu’elles proposent, ces marques ont réussi à capter une part du temps d’attention disponible du consommateur. 

L’expérience crée de la valeur 

La clé pour les marques réside dans la conception d’une expérience unifiée, cohérente et continue qui crée un lien entre les différentes interactions possibles avec les consommateurs, afin de convertir cette attention en mémorisation. Ainsi, l’ouverture de magasins physiques par les DNVB répond moins à un besoin de créer un espace de distribution complémentaire qu’à prolonger et enrichir l’expérience consommateur à travers des lieux de découverte qui entrent en résonance avec l’univers de la marque.  

Cet enjeu est d’autant plus important que la grande majorité des consommateurs (77%***) privilégient désormais l’usage à la possession. Dans ce contexte, l’expérience prend le pas sur le produit et sur le prix et agit comme un élément central de création de valeur pour la marque. Elle les rapproche de leurs consommateurs en étant porteur de sens et en créant un lien émotionnel qui transcende l’usage et enrichit la vie quotidienne. 

Télécharger la success story visilab

 

 

*Source : SAP Hybris – “Consumer Insights 2017” 

**Source : Baromètre du numérique 2018 

***Source : Observatoire Société de Consommation 2018 

 

Initialement paru sur Les Echos