Un prototype en 5 jours au lieu des plusieurs mois habituels. Telle est la promesse du Design Sprint développé par Google Ventures ! Cette méthodologie, décrite par Jake Knapp dans son livre “Sprint: How to solve Big Problems and Test New Ideas in Just Five Days”,  est une formalisation de l’organisation des équipes performantes que j’ai observée en tant que coach pendant les Start-up Week-end.

De l’idée aux tests utilisateurs en 1 sprint.

Curieux de nature, j’ai expérimenté le Design Sprint lors d’un accompagnement à la construction collective d’un laboratoire d’innovation ouverte dans le domaine de la e-Santé, le Living Lab.  La finalité est de réaliser un prototype de la gouvernance partagée du  Living Lab. Le processus est structuré pour trouver rapidement des réponses à une problématique métier critique (http://blog.thiga.fr/innovation-digitale/design-sprint-idee-prototype-5-jours/) autour de 5 phases (1 phase par jour):

• Jour 1: Analyse (Map): Acquérir la connaissance métier et dégager une problématique à solutionner.
• Jour 2: Divergence (Sketch): Émettre le plus grand nombre de solutions possibles sans se limiter,
• Jour 3: Convergence (Decide): Se mettre d’accord sur la solution la plus pertinente pour répondre à la problématique dégagée lors de la phase d’analyse.
• Jour 4: Prototypage (Prototype): Construire le prototype de la solution.
• Jour 5: Tests (Test).

Résultat : un modèle de gouvernance, co-construit à l’aide de briques Lego et de pâte à modeler, et validé par l’ensemble des acteurs du Living Lab. Le Design Sprint est très efficace pour la réalisation rapide de prototypes.

Le Design Sprint, un sprint agile de projet?

Ce lundi, lors d’une synchronisation de coachs pour un client dans le domaine aéronautique, la coach programme nous annonce « que les équipes doivent être accompagnées selon la méthodologie Google ». Bien qu’elle soit efficace pour la conception d’un prototype, cette méthodologie ne vous fait-elle pas penser à un cycle en cascade, certes rapide, mais très traditionnel ? Le Design Sprint peut-il être étendu à l’ensemble du cycle de vie d’un projet?

1ère constatation : la “War Room” exacerbe les tensions.

Un principe sous-jacent du Manifeste Agile est de réaliser “les projets avec des personnes motivées”, de leur fournir “l’environnement et le soutien dont ils ont besoin” et de leur faire “confiance pour atteindre les objectifs fixés”.

Or les équipes sont généralement constituées pour le prototypage de projet. Les membres sont sélectionnés et n’ont pas nécessairement travaillé ensemble auparavant posant une problématique de motivation.

C’est pourquoi, un isolement dans une « War Room » s’avère un facteur de réussite du Design Sprint. Néanmoins, ce cadrage annihile toutes constructions d’interactions de confiance à long terme. Les tensions sont exacerbées. Le Sprint Master souffre pour maintenir le cadre sur le long terme. Il oriente alors les réflexions vers la solution qu’il considère la meilleure plutôt que de soutenir l’équipe.

2ème constatation  : le principe de soutenabilité est absent.

“Les processus agiles encouragent un rythme de développement soutenable” (principe de soutenabilité). A contrario, l’énergie dépensée lors d’un Design Sprint est importante ! Aucune protection de l’équipe par rapport à sa capacité. Au bout de la semaine, bien que l’équipe soit fière de sa réalisation, chaque membre est « lessivé ».

Pensez-vous que vos équipes soient capables d’enchaîner de tels sprints tout au long d’un projet ?

3ème constatation : Un prototype n’est pas forcément un produit fonctionnel.

Centré sur l’UX Design, le résultat du Design Sprint est souvent une maquette, un storyboard… Rarement un produit fonctionnel préconisé dans les principes agiles (“Livrez fréquemment un logiciel opérationnel”). Et pour cause. Bien trop souvent, l’objectif de résultat incite l’équipe à réfléchir à « La » solution au problème (même principe que le jeu agile bien connu du Marshmallow Challenge) au lieu de se poser la question « Que voulons-nous apprendre ? ». L’équipe prend alors trop de temps sur la partie d’analyse et pas assez sur la partie de prototypage.

4ème constatation : Et l’utilisateur final dans tout ça ?

“Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet” (principe sous-jacent du Manifeste Agile). Dans le meilleur des cas, l’équipe demande l’avis de l’utilisateur lors de la phase de test du prototype. Mais toute la valeur ajoutée des méthodes agiles de conduite de projet est l’implication dès le début (au moins par la présence du Product Owner). Pourquoi construire un produit sur des hypothèses que l’équipe a la capacité de faire valider dès le lancement de la réflexion ?

Aujourd’hui, même si nos utilisateurs ne sont pas disponibles, nous disposons des outils nécessaires à un contact facile : téléphone, visio, réseaux sociaux… N’oubliez jamais que si vous apportez une solution aux besoins de vos utilisateurs, il n’y a aucune raison pour qu’ils ne soient pas coopératifs.

Le Design Sprint, attention au Buzzword.

Attention aux dangers du Buzzword. L’erreur majeure des entreprises est de vouloir adapter le Design Sprint pour conduire un projet. Vous comprenez bien que, cette méthode est très efficace lors de la phase de prototypage. Et dans ce cas, je le recommande. Mais ce n’est absolument pas un sprint agile.

Prenez-vous un tournevis pour planter des clous ?