Google Design Sprint

Vous avez fait un produit d'innovation, mais vous constater qu'il ne correspond pas à la demande ?
Vous avez passé des mois ou même des années à faire des hypothèses, trouver des solutions, utiliser les dernières technologies à la mode, pour un produit qui rate sa cible ?
Aujourd'hui, je vais vous présenter une méthode pour vous aider à valider les hypothèses d'un projet d'innovation avant de faire le MVP en une semaine.

Processus Agile et ses limites

Quand on parle de réalisation de produit, on parle souvent de processus Agile, LEAN, Scrum... Pour ceux qui ne connaisse pas l'agilité (et Scrum), voici une petite explication.

Qu'est-ce que l'agilité ?

Pour répondre à cette question, les méthodes agiles sont des pratiques de gestion de projet favorisant la collaboration entre plusieurs équipe auto-organisé et pluridisciplinaire, et leurs clients. Elles se base sur le manifeste agile publié en 2001 qui présente les 4 piliers et les 12 principes de l'agilité.

Une de ces méthodes les plus connu est SCRUM créé par Ken Schwaber et Jeff Sutherland (décrit en 2010 dans le "Guide Scrum").

Cette méthode se base sur la livraison (delivery) de manière itérative du produit via des sprints (d'une durée de 2 à 4 semaines dépendant de la maturité de l'équipe et de la complexité du projet). Exemple, on a un produit qui doit contenir 6 fonctionnalités, pour le premier on doit avoir les fonctionnalités n°1 et n°3, pour le second les n°2, 4 et 6, et pour le dernier sprint, la fonctionnalité n°5.

Et voici le schéma Scrum expliquant les différentes phases d'un sprint :

Quelques explications s'impose :

• Les termes :
  • Product Owner (PO) : Chef de projet Scrum qui possède des compétences fonctionnelles.
  • Scrum Team : 5 à 9 membres composés de développeurs, architecte, UX Designer, Scrum Master...
  • User Story (US) : Scénario d'une fonctionnalité du point de vue de l'utilisateur.
  • Product Backlog : Liste de toutes les US pour le produit.
  • Sprint Backlog : Liste de toutes les US pour le sprint.
• Le processus :
  • Le client va exposer son besoin métier au PO qui va rédiger les US dans le Product Backlog.
  • Ensuite la Scrum Team choisi les US à faire dans le Sprint Backlog et défini celles à faire en priorités.
  • Pendant le sprint, l'équipe Scrum se retrouve tous les matins pour faire le Daily Scrum (savoir comment avance les US).
  • En fin de sprint, on fait tester les développement au client et 3 choix s'offres à nous :
    • Persévérer : Il reste des US à faire donc on continu le développement.
    • Pivoter : L'équipe Scrum à un problème quelconque avec le projet et à besoin du retour des clients.
    • Stopper : le produit est fini ou le projet est arrêté.

Après cette courte explication des méthodes agiles et de Scrum, nous allons parlé des limites que ce processus peut avoir dans des projets d'innovation.

Limites dans des projets d'innovation

Certaines Start-up sont confrontés à 3 problèmes majeurs :

• Ce processus est centré sur les bonnes pratiques de réalisation mais il ne garantit pas la pertinence du produit (Etait-ce le bon produit ?).
• On démarre le sprint après la définition du Product Backlog (et le Priority Meeting) mais il ne décrit pas comment faire ce travail efficacement (par quoi commencer).
• La qualité du product Backlog repose sur le PO (ses compétences et sa vision / compréhension du besoin métier) et non sur la méthode.

Pour pallier à ces problèmes, Eric Ries développe le Lean Startup, initié en 2008, en se basant sur sa propre expérience (mauvaise compréhension des besoins des consommateurs chez Catalyst, et trop de temps et d'argent dépensé dans un produit chez There Inc), le Développement par la clientèle (ou "Customer development") de Steve Blank et le Lean Management de Toyota.

Il décrit que le premier delivery doit être un MVP (Minimum Viable Product) pour tester les hypothèses du produit le plus tôt possible pour corriger les éventuels faux pas.

Phases de conception avec un MVP

Voici un schéma explicatif des phases de conceptions :

Nous avons 4 phases :

• Réflexion
• Construction
• Lancement
• Amélioration

Si on ajoute le MVP, ça nous donne :

Donc on commence avec la phase de Réflexion. On fait nos sprints avec la phase de Construction. Lors de la phase de Lancement, le MVP est prêt à être en production. Et on fait des tests utilisateurs avec la phase d'Amélioration.

Le but du MVP est de pouvoir en apprendre le plus vite possible sur le produit à faire. Donc plus on itère vite, plus on apprend vite.
Cependant, la vitesse est limitée dû au temps de construction de ce MVP.

C'est la qu'entre en jeux le Google Design Sprint. Mais avant ça, petit point historique.

Création du Google Design Sprint

Le Design Sprint à été créé en 2016 au sein du Google Venture (incubateur de start-up de Google) sur une idée de Jake Knapp avec l'aide de John Zeratsky et Branden Kowitz, tous les trois Designer de projet.

Ils intègrent dans leur méthode le "Design Thinking", le "Lean Startup" et le "Lean UX" (créé en 2013 par Jeff Gothelf et John Seiden).

Qu'est-ce que c'est ?

Le Google Design Sprint est un processus de conception pour startup ou grandes entreprises pour répondre, en un court laps de temps (environs 5 jours), à une problématique business pour arriver à un produit / service. Il impose cette contrainte temporelle pour réduire les risques d'un projet.

Et le principal atout est le MVC. Non, ici ce terme ne signifie pas Modèle Vue Contrôleur mais Minimum Viable Concept. C'est toute conceptualisation, comme des schémas, maquettes..., pour s'affranchir de la limite de vitesse imposé par le MVP.

Pour être plus clair, nous allons modifier notre schéma des phases de conception :

Le but est de passer directement de la phase de Réflexion à la phase d'Amélioration avec un prototype et d'itérer autant de fois que nécessaire pour correctement cadrer le besoin et minimiser les risques :

Dès que le projet est correctement cadré, on peut commencer les phases de Conception et de Lancement avec la réalisation d'un MVP.

Mais comment faire ce MVC ? Qu'est-ce que la méthode nous dit pour y arriver ?

Processus Google Design Sprint

Le guide du Design Sprint nous montre un processus en 5 jours, détaillé heure par heure. Ici, le but est de faire une présentation assez courte, si vous êtes intéressé, je vous conseille le lien vers le site GV ou encore le livre dédié au GDS.
Mais le GDS est multiformes et peut s’adapter à vos besoins. Nous y reviendrons dans le chapitre Multiformes, pour l’instant concentrons-nous sur les bases de ce processus :

Avant de le détailler, il faut faire une étape d'initialisation des ateliers (ou "Set the stage"). Cette partie est crucial pour réaliser correctement la méthode. Heureusement, on nous donne une checklist des étapes à suivre !

Je ne vais pas la détailler ici mais voici les idées principales à retenir :

• Bien choisir les participants, entre 5 et 9 personnes. Ces personnes doivent être disponible lors de la réalisation du sprint.
• Choisir un décideur. C’est la personne qui va trancher si l’équipe propose plusieurs solutions. Cette personne n’a pas besoin d’être présente lors de l’entièreté du sprint mais doit être à minima joignable à tout moment.
• Préparer la “War Room”. La salle dans laquelle la magie opère, il faut la préparer ! Voici une explication de comment la préparer.
• La “Shopping List”. Tout le matériel dont vous avez besoin pour travailler comme des tableaux blanc, post-it, marqueurs...

Et il faut bien garder en tête les idées clés :

• Pas de distraction. Pas d’ordinateurs, de téléphones... (sauf si vous avez besoin d’une information importante pour travailler)
• La “Timebox”. Les ateliers sont timer, il faut donc être vigilant à respecter la durée de chaque atelier.
• Planifier le repas et les pauses. Pour garder l’énergie tout au long du sprint, ces pauses sont obligatoires.

Maintenant que nous sommes prêt pour le sprint, nous pouvons attaquer les journées !

Lundi
Le but de cette journée est que chacun doit comprendre les objectifs, les problèmes du projet et de partager toutes les connaissances sur le sujet.
Durant cette journée, nous allons utiliser différentes méthodes pour prendre les bonnes décisions, faire remonter les problèmes et les objectifs les plus important.
Vous pouvez retrouver une checklist de la journée ici

Mardi
Sur cette journée, nous imaginons des solutions pour résoudre les problèmes majeurs évoqué lors de la première journée.
De plus, il est conseillé de recruter les testeurs pour la dernière journée même si il vaut mieux faire cette étapes lors du “Set the stage”.
Vous pouvez retrouver une checklist de la journée ici

Mercredi
Maintenant, nous allons voter pour la solution qui répond le plus à nos objectifs. Ce vote est basé sur 3 critères du Design Thinking : la Désirabilité, la Faisabilité et la Viabilité Business.
Et nous faisons des storyboards pour créer la maquette le jour suivant
Vous pouvez retrouver une checklist de la journée ici

Jeudi
Créons notre maquette ! Nous nous basons sur les storyboards du Mercredi pour pouvoir les transformer en prototype.
Ensuite nous allons faire des hypothèse concernant ce prototype pour le Vendredi. Nous voulons en valider le plus possible pour être sûr que c’est le bon produit à faire.
Vous pouvez retrouver une checklist de la journée ici

Vendredi
C’est l’heure du test ! Nos testeurs vont essayer le prototype et nous faire du feedback.
Quand tous les tests sont fini, nous pouvons faire une synthèse sur l’expérience des testeurs et 3 situations s’offre à nous :

• Succès : nos hypothèse ont été validé, on sait que c’est le bon produit, on peut passer au développement d’un MVP
• Réussite partielle : il y a encore des zones de flou, ou il manque quelque chose. Nous refaisons une autre itération à partir des retours des testeurs
• Inadaptée : ce n’est pas le bon produit. Ce n’est pas un échec puisque nous n’avons pas dépensé de l’énergie et de l’argent dans ce produit

Vous pouvez retrouver une checklist de la journée ici

Multifomes

Plus haut, j’ai mentionné que le Google Design Sprint était multiformes. Mais peut-on avoir un processus adapté à tout nos besoins ? Et peut-on adapté la durée du sprint ?
Oui. Et je vais vous montré un tableau pour le prouver :

Vous pouvez aussi consulter cette page qui ressence une bonne partie des Design Sprint.
Vous pouvez y voir des durées propres à chaque sprint (3 jours, 4 jours...) et leurs livrables attendu.
Lors d’une précédente expérience, nous avions un processus en 3 jours avec comme livrable des schémas d’architecture testé devant les responsables des SI.
De plus vous pouvez ajouter d’autres ateliers que ceux proposé de base par le GDS.

Ce qu’il faut retenir

Le Google Design Sprint est une méthode pour valider nos hypothèses, avant de faire un MVP, via un MVC qui est testé avec des utilisateurs finaux. Il permet de décider rapidement si c’est le bon produit à faire, et réduit les risques de dépenser trop d’énergie et d’argent dans un produit qui ne fonctionnera pas.


Si cette présentation sur le Design Sprint vous a plus, n’hésitez pas à la partager et nous faire des retours. Vous pouvez aussi consulter nos autres articles ou entamer la discution pour une future collaboration.