Skip links

Scrum seul ne suffit pas pour construire un excellent produit – Partie 1

NB: Cet article m’a été inspiré par l’article “Design Sprints for Scrum Projects” (en anglais) de Benjamin Bestmann, je vous invite à le lire sur Medium ici et pour les non anglophones, je vous ai traduit le principal dans l’article ci-dessous. Bonne lecture

 

Créer un bon logiciel n’est pas facile. Les méthodes Agiles comme Scrum sont la nouvelle norme pour construire des logiciels et aider les équipes à livrer de meilleurs produits plus rapidement. Mais Scrum seul ne suffit pas pour construire un excellent produit. Les marchés étant de plus en plus encombrés, il est de plus en plus difficile pour une entreprise de se différencier. Une bonne expérience utilisateur (UX) est devenue l’un des facteurs clés de succès. Aujourd’hui un produit “qui fonctionne” ne suffit plus, il doit répondre aux besoins réels des utilisateurs voir les surpasser.

Mais comment faire pour mettre un maximum de chance de notre côté et créer cet excellent produit sans investir dans de longues et coûteuses études ?

De brillants cerveaux se sont posés la question et depuis plusieurs années, des milliers d’entreprises à travers le monde ont adopté leur solution : Sensibiliser rapidement leurs équipes au Design.

« Le design ce n’est pas seulement l’apparence et le ressenti. Le design c’est comment cela fonctionne. » Steve Jobs

L’essor de l’expérience utilisateur

Depuis toujours, les équipes produits sont continuellement sous pression pour mettre de meilleurs produits sur le marché en moins de temps et avec un budget réduit. Au cours des deux dernières décennies, Scrum s’est imposé comme le cadre de développement agile le plus populaire pour délivrer des logiciels. Il a permis aux équipes de livrer plus rapidement des produits de meilleure qualité et a permis aux entreprises d’être plus compétitives sur des marchés de plus en plus complexes et imprévisibles.

Mais livrer des changements en cycle court ne suffit pas. Scrum ne garantit pas à lui seul que votre équipe fournira en permanence des produits réellement attrayants et percutants. L’un des aspects les plus difficiles dans la construction de logiciel est de faire les bons choix et savoir quoi construire en priorité pour résoudre les problèmes utilisateurs les plus importants.

Avec la multiplicité d’acteurs sur le marché, nous sommes de plus en plus exigeants. Nous n’acceptons plus les produits que nous ne comprenons pas ou que nous avons du mal à utiliser. Nous cherchons des solutions qui nous aident à réaliser notre activité, notre tâche, notre travail aussi vite que possible.

En conséquence, une bonne expérience utilisateur (UX) est devenue l’un des principaux facteurs de différenciation sur le marché et un facteur de succès crucial pour les produits logiciels. Des méthodes orientées Design comme le Design Thinking et le Lean UX ont vu le jour et les entreprises engagent de plus en plus de concepteurs UX pour rendre leurs produits plus intuitifs et utiles.

 

Scrum doit intégrer une vision design

Vous allez me dire que c’est formidable mais malheureusement il y a un gros problème. Scrum et les autres méthodes agiles manquent de pratiques spécifiques pour intégrer systématiquement les activités de design dans le processus de développement. Par conséquent, la conception et le développement sont souvent traités comme deux activités très distinctes qui suivent leurs propres processus et sont réalisées par des équipes indépendantes.

Les designers ne sont pas des membres entièrement intégrés à l’équipe Scrum, mais jouent souvent le rôle de consultants ou de prestataires de services qui aident les développeurs à prendre des décisions en matière de conception. Pour construire d’excellents produits, les équipes Scrum doivent intégrer une vision design et trouver de nouvelles façons de construire systématiquement des solutions qui résolvent les bons problèmes.

Le Design Sprint est un cadre relativement nouveau récemment devenu très populaires au sein de la communauté du design et de l’innovation. Il permet à une équipe d’identifier rapidement les bons problèmes à résoudre et de tester les solutions grâce à un prototypage rapide et à un retour d’expérience. En tant que tels, ils constituent un complément idéal pour les projets Scrum. Alors que Scrum est une approche optimisée de résolution de problèmes et de fourniture de solutions, le Design Sprint est une approche optimisée de recherche et de compréhension des problèmes.

 

Qu’est-ce qu’un Design Sprint ?

Un Design Sprint est une approche rapide et agile de la conception de produits. Il s’agit essentiellement d’un processus structuré de cinq jours qui permet à une équipe multidisciplinaire de construire et tester de nouvelles idées à l’aide d’une série d’exercices de réflexion sur la conception. Le résultat de chaque Design Sprint est un prototype interactif de haute fidélité, testé par des utilisateurs réels, qui donne des indications claires sur la voie à suivre.

 

Source: Google Ventures

Les Design Sprint ont été développés à l’origine par Jake Knapp de Google Ventures et popularisés par le livre à succès “Sprint” : Comment résoudre de gros problèmes et tester de nouvelles idées en seulement cinq jours”. Après un grand succès, les Design Sprints sont maintenant adoptés dans le monde entier par des milliers d’entreprises innovantes de toutes tailles et de tous secteurs – y compris des marques telles que LEGO, Ebay, RedBull, Slack, Lufthansa, Bosch et UNICEF.

Un raccourci pour apprendre

L’idée centrale du Design Sprint est de proposer une méthode complète étape par étape pour construire et tester de nouvelles idées en un temps record sans rien avoir à développer. Ainsi, au lieu de réaliser un Minimum Viable Product (MVP) coûteux pour voir si une idée est bonne, vous construirez rapidement et obtiendrez des données à partir d’un prototype réaliste.

Cela fait du Design Sprint un excellent outil pour découvrir et explorer les besoins et pour aligner une équipe autour d’une perspective unifiée. Au lieu de perdre du temps à rédiger et à débattre des spécifications dans des réunions interminables, vous les intégrez dans un prototype et les présentez aux utilisateurs finaux.

 

Comment fonctionne un Design Sprint ?

Pour mener à bien un Design Sprint, vous avez besoin de trois ingrédients de base :

  • Un défi bien défini : Un Design Sprint réussi ne peut pas commencer sans un défi clairement défini. Le défi détermine la portée et l’objectif du Design Sprint. Supposons que vous ayez un produit SaaS dans lequel vous offrez une période d’essai gratuite, mais que vous vous battiez pour convertir les essais en clients réels. Dans ce cas, votre défi pourrait être le suivant : “Comment pouvons-nous améliorer l’expérience pendant notre période d’essai de 30 jours pour réussir à convertir plus de prospects en clients payants ?
  • Une équipe multidisciplinaire : Vous avez besoin d’une équipe pluridisciplinaire composée idéalement de 6 à 8 participants qui sont motivés et apportent toutes les compétences nécessaires pour relever le défi. Une bonne équipe devrait certainement comprendre le Product Owner, des personnes du marketing, des ventes, mais aussi un designer, des personnes de l’équipe de développement et du service client.
  • Un bon facilitateur : Comme le processus du Design Sprint est très riche en exercices rapides, le succès d’un Design Sprint dépend grandement d’un facilitateur compétent. Il se chargera des préparatifs, dirigera l’équipe dans toutes les tâches et guidera les discussions et les décisions de l’équipe. Le facilitateur doit donc être quelqu’un qui a non seulement une expérience du Design Sprint, mais aussi de grandes compétences en matière de communication et de gestion d’équipe.

Une fois que vous avez réuni ces ingrédients, l’organisation d’un Design Sprint est assez simple. Chaque jour consiste en une série d’exercices clairement définis et chronométrés avec un objectif bien particulier.

 

Source: thesprintbook.com

 

Voici ce qui se passe pendant les différents jours et phases :

Lundi (Comprendre) : Le premier jour du Design Sprint est consacré à la compréhension du défi et à l’exploration du problème. Il s’agit de tracer le parcours du client et de mener des entretiens avec des experts.

Mardi (Idéation) : Une fois que l’équipe a compris le problème, il est temps de générer des solutions. Grâce à une série d’exercices créatifs, chaque participant va d’abord créer un tas d’idées potentielles et finalement arriver à son propre concept esquissé sur le papier.

Mercredi (Décider) : L’équipe vote et décide quel concept sera prototypé. Il peut s’agir d’une solution, mais le plus souvent, il s’agit d’une combinaison des meilleures parties de plusieurs idées.

Jeudi (Prototyper) : L’équipe crée un prototype haute-fidélité à partir du concept final et prépare les tests utilisateurs pour le jour suivant.

Vendredi (Tester) : Le dernier jour du Design Sprint, l’équipe présentera le prototype à cinq utilisateurs afin de recueillir leurs commentaires et leurs idées. À la fin, l’équipe sait exactement comment aller de l’avant.

 

Le résultat de chaque Design Sprint est un prototype interactif haute-fidélité, testé par de réels utilisateurs. Source: GV.

 

Relier Design Sprints et Sprints Scrum

Les Design Sprints peuvent s’intégrer assez facilement dans un projet Scrum. Mais il y a quelques pièges. Pour que cela fonctionne, vous devez comprendre quels types de résultats un Design Sprint fournit réellement et où ils s’intègrent dans Scrum.

Ne vous laissez pas happer dans le flot de la cascade

Une fausse idée courante lorsqu’on utilise les Design Sprints dans un cadre agile comme Scrum, est que les gens s’attendent à ce que le Design Sprint fournisse des maquettes hautes définitions parfaites prêtes à alimenter l’équipe de développement. Ce n’est pas l’intention d’un Design Sprint et cette idée est dangereusement proche d’une mentalité de gestion de projet dite “en cascade” (waterfall en anglais) qui ne permet pas de gérer efficacement les risques rencontrés sur la route de la réussite du projet.

Un conseil, terminer la phase de conception avant de débuter la phase de mise en œuvre.

 

Attention, ne tombez pas dans la cascade !

 

Les dessins qui sortent d’un Design Sprint sont des prototypes et ne seront donc la plupart du temps pas du tout prêts pour le développement. Ils seront souvent incomplets et contiendront de nombreux éléments  “de façade” pour gagner du temps dans le prototypage et éviter d’observer les détails du comportement de l’application. En effet, un bon prototype est construit pour tester un ensemble d’hypothèses clairement définies et omettra tout ce qui n’est pas pertinent pour ce test.

 

Le véritable enjeu des Design Sprints

Ce qu’un Design Sprint fournit réellement, ce ne sont pas des maquettes détaillées mais une vue d’ensemble et une indication claire sous la forme de commentaires des utilisateurs. Il donnera à votre équipe des informations essentielles sur une idée et vous indiquera si vous êtes sur la bonne voie. Plus important encore, il vous aidera à planifier et à classer par ordre de priorité vos releases, backlogs et user stories sur la base des commentaires réels des utilisateurs et non sur la base de vos propres hypothèses.

C’est l’un des plus grands défis de Scrum, car Scrum donne très peu de conseils (presque aucun) sur la façon de gérer votre backlog produit. C’est donc à l’équipe, et en particulier au Product Owner, de s’assurer que le backlog représente toujours le point de vue du client. Il est donc facile de croire que vous savez déjà ce que veulent vos clients. C’est pourquoi même les meilleures équipes Scrum, bien intentionnées, peuvent perdre leur temps à créer les mauvaises fonctionnalités ou à créer les bonnes fonctionnalités de la mauvaise manière, parce qu’elles n’ont pas une compréhension claire de l’utilisateur.

Ainsi, les Design Sprints, lorsqu’ils sont utilisés dans Scrum, vous aident à créer des backlogs qui ne sont pas seulement une représentation théorique de tout ce qu’une équipe doit faire. Ils vous aident plutôt à visualiser vos user stories et vos backlogs dans le contexte de l’utilisateur et à répondre à des questions comme “Pourquoi construisons-nous cela ? Pour qui le faisons-nous ? Quelle valeur la solution apportera-t-elle au client et à quel moment ?”

Comment faire pour que tout fonctionne

L’utilisation de Design Sprints au sein de Scrum est assez simple. En gros, le processus fonctionne comme ceci :

  1. Lancez un Design Sprint. Définissez votre défi, rassemblez l’équipe et lancez un sprint de conception. Quand devez-vous lancer le sprint ? Il y a de nombreux cas où un sprint de conception peut être utile dans un projet Scrum et aussi de nombreux cas où ils sont tout simplement exagérés. J’y reviendrai plus en détail dans la section suivante.
  2. Déclinez les User Stories. Une fois le Design Sprint terminé, utilisez le prototype et les commentaires pour en tirer systématiquement des témoignages d’utilisateurs. Il n’y a pas de véritable meilleure pratique pour cela, mais nous pensons que le User Story Mapping de Jeff Patton est le moyen idéal de faire le lien avec le résultat d’un Design Sprint. Vous pouvez en apprendre davantage à ce sujet dans ce billet de blog (en anglais).
  3. Lancez votre Sprint Scrum. Prenez les User Stories obtenues et planifiez votre Sprint Backlog comme d’habitude. Pendant le Sprint Scrum, l’équipe peut ensuite utiliser le prototype créé pendant le Design Sprint pour itérer et créer des interfaces détaillées pour les différentes histoires d’utilisateurs. Cela nécessite une étroite collaboration entre l’équipe de développement et l’équipe de conception.

 

Il est assez simple de faire entrer les Design Sprints dans Scrum.

 

Intégrer les designers dans l’équipe Scrum

Une autre condition préalable très importante est que les designers doivent devenir de véritables membres de l’équipe Scrum. Cela signifie qu’ils intégreront leur travail dans les Sprints Scrum et participeront à toutes les réunions Scrum, telles que les sessions de planification, les stand-up quotidiens, les revues de sprint, les rétrospectives et l’affinement du backlog. Ils travailleront également directement avec l’équipe de développement pour mettre en œuvre les users stories et faire du travail de conception pendant la semaine du sprint.

 

Ok, très bien, maintenant que l’on a compris qu’il était facile d’intégrer le Design Sprint, vous pourriez vous poser la question “Quand est-ce qu’il est le plus judicieux de faire des design sprint ?”

Je vous propose d’étudier le sujet dans notre deuxième article ICI.

 

Si vous souhaitez en savoir plus, n’hésitez pas à nous contacter.

 

Robin SUR – Lead UX
Return to top of page
Nous utilisons les cookies pour optimiser les performances de notre site et vous proposer des services et offres adaptés à vos centres d’intérêt. Vous pouvez modifier vos préférences à tout moment.
Mentions légales
Accepter
Refuser

Nous utilisons les cookies pour optimiser les performances de notre site et vous proposer des services et offres adaptés à vos centres d’intérêt. Vous pouvez modifier vos préférences à tout moment.

Mentions légales
Accepter
Refuser