Design thinking, lean, agile ou design sprint : lequel, et quand

Choisissez le design thinking quand vous ne comprenez pas encore le problème. Choisissez le lean startup quand vous avez une idée et devez découvrir, à moindre coût, si elle fonctionne. Choisissez l'agile quand vous savez quoi construire et devez le livrer par éléments fonctionnels. Choisissez un design sprint quand un problème clair et important exige une réponse testée en une semaine. Ce ne sont pas des rivaux : chacun répond à une question différente, et la plupart des projets réels en utilisent plusieurs à la suite.

La confusion vient de ce que les quatre parlent d'utilisateurs, d'itération et d'apprentissage. La différence tient à ce que chacun suppose que vous savez déjà au départ. Pour la question plus large de l'outil à utiliser, voyez quel outil d'innovation utiliser ?.

D'où vient chacun

Un bref historique aide, car chaque approche porte encore la marque du problème pour lequel elle a été conçue.

• Le design thinking est issu de la pratique du design et a été popularisé comme démarche générale de résolution de problèmes par l'agence de design IDEO et la d.school de Stanford (le Hasso Plattner Institute of Design, fondé en 2005). Le Double Diamond du Design Council britannique, créé en 2003, décrit une forme similaire. Il a été conçu pour les problèmes où le besoin lui-même n'est pas clair.
• Le lean startup a été formalisé par Eric Ries dans son livre de 2011, The Lean Startup, en s'appuyant sur le customer development de Steve Blank et sur le lean manufacturing. Il a été conçu pour les fondateurs qui risquent de passer des années à construire quelque chose dont personne ne veut.
• L'agile remonte au Manifeste pour le développement agile de logiciels, rédigé par 17 praticiens du logiciel à Snowbird, dans l'Utah, en février 2001. Scrum, créé par Ken Schwaber et Jeff Sutherland, en est le cadre le plus connu. Il a été conçu pour les projets logiciels qui échouaient sous des plans longs et figés.
• Le design sprint a été conçu par Jake Knapp chez Google et Google Ventures, et décrit dans le livre Sprint (2016) de Knapp, John Zeratsky et Braden Kowitz. Il a été conçu pour faire passer une équipe d'une question difficile à un prototype testé en cinq jours.

Côte à côte

Quand chacun convient

Le design thinking quand le problème n'est pas clair

Vous entendez plusieurs descriptions différentes du problème selon les interlocuteurs. Les plaintes existent, mais personne ne sait dire ce qui les cause. Un nouveau service est nécessaire pour un public que vous n'avez jamais étudié. Dans ces cas, commencer par les idées ou par la livraison fait l'impasse sur le travail le plus précieux. Commencez par des entretiens avec les parties prenantes et terminez le cadrage avec un énoncé de point de vue et des questions « Comment pourrions-nous ». Le processus complet est dans le design thinking, étape par étape.

Ne l'utilisez pas quand le problème est bien compris et que l'organisation a besoin de livrer. Mener une phase d'exploration sur un problème que tout le monde comprend déjà met à l'épreuve la patience, pas les idées.

Le lean startup quand vous avez une idée et que le risque est que personne n'en veuille

Vous avez un concept, un sponsor et un certain enthousiasme, mais aucune preuve que les gens l'utiliseront, paieront pour lui ou changeront de comportement pour lui. L'approche lean vous demande d'identifier l'hypothèse la plus risquée avec une cartographie des hypothèses, de rédiger un test d'hypothèse, et de mener la plus petite expérimentation capable de vous donner tort, comme un test concierge. Pour en savoir plus : comment tester une idée avant de la construire.

Il est moins pertinent quand le problème lui-même n'est pas clair (vous testerez des réponses à la mauvaise question) et dans les services où l'on ne peut pas, sur le plan éthique ou juridique, expérimenter sur le public sans précautions. Dans le secteur public, beaucoup d'expérimentations demandent une conversation sur le consentement et le risque différente de celle d'une startup.

L'agile quand vous savez quoi construire

Le concept est validé et le travail relève surtout de la livraison : construire le système, le processus, le service. L'agile découpe le travail en petits incréments, rédigés sous forme de user stories, livre des éléments fonctionnels par cycles courts et s'ajuste grâce à des rétrospectives régulières.

L'agile ne vous dit pas quoi construire. Les équipes qui l'utilisent pour l'exploration finissent souvent par livrer rapidement des fonctionnalités dont personne n'avait besoin. Il convient mal aussi là où les contrats, les achats ou la réglementation figent le périmètre à l'avance, sauf si ceux-ci sont conçus pour permettre le changement.

Le design sprint quand une question importante doit trouver sa réponse cette semaine

Un design sprint convient quand le défi est défini, que l'enjeu justifie cinq jours du temps d'un décideur, et que l'équipe est bloquée entre plusieurs options. Le schéma classique : lundi, cartographier le problème et choisir une cible ; mardi, esquisser des solutions individuellement ; mercredi, décider et réaliser le storyboard ; jeudi, construire un prototype réaliste ; vendredi, le tester avec cinq utilisateurs.

Il convient mal quand personne n'a étudié les utilisateurs (le sprint reposera sur des suppositions), quand le décideur ne peut pas être présent, ou quand le problème est trop vaste pour être prototypé en une journée.

Les combiner : l'enchaînement habituel

Ces approches fonctionnent le mieux dans un ordre qui suit l'incertitude.

1. Le design thinking pour comprendre et cadrer. De la recherche et un énoncé du problème validé.
2. Un design sprint pour converger. Servez-vous de la recherche pour rendre le lundi du sprint plus rapide et mieux ancré, et ressortez avec un concept testé.
3. Des expérimentations lean pour réduire le risque. Testez les hypothèses que le sprint n'a pas tranchées, par exemple si les gens continueront d'utiliser le service après la première semaine.
4. L'agile pour livrer. Construisez et livrez par incréments, en continuant de tester avec les utilisateurs au fil de l'eau.

Tous les projets n'ont pas besoin des quatre. Une petite correction de processus interne peut se contenter d'une semaine d'exploration avant la livraison. Un nouveau produit numérique peut passer directement à un sprint si la recherche existe déjà. La règle empirique : identifiez votre plus grande inconnue, et utilisez l'approche conçue pour elle.

Un exemple concret

Illustratif. L'opérateur postal national d'un pays européen de taille moyenne veut proposer un service aux petits vendeurs en ligne.

Design thinking (six semaines). L'équipe interroge vingt vendeurs et en observe plusieurs pendant qu'ils préparent leurs commandes. Le problème attendu était le coût de l'affranchissement. Le vrai : les vendeurs perdent des heures chaque semaine à gérer les retours, parce que les acheteurs impriment mal les étiquettes et que les colis reviennent sans identification. L'énoncé du problème est validé : « Comment pourrions-nous rendre les retours sans effort pour les vendeurs qui traitent moins de cinquante commandes par semaine ? »

Design sprint (cinq jours). Avec le directeur colis dans la salle le lundi et le mercredi, l'équipe esquisse, choisit et prototype un code de retour que l'acheteur présente au guichet, sans rien imprimer. Cinq vendeurs le testent le vendredi. Quatre le veulent, et les cinq demandent s'il fonctionne avec leur place de marché.

Expérimentation lean (quatre semaines). L'hypothèse restante la plus risquée est que le personnel des guichets peut traiter les codes sans ralentir la file d'attente. L'équipe mène une version concierge dans trois bureaux de poste, le personnel traitant les codes manuellement à partir d'une liste imprimée. Les temps d'attente restent stables.

Livraison agile (en continu). Une équipe de réalisation construit le vrai système par sprints de deux semaines, en commençant par l'intégration d'une place de marché et l'étape de scan au guichet, et teste chaque version avec des vendeurs.

Chaque approche a fait le travail pour lequel elle a été conçue. Commencer par l'agile aurait produit rapidement un outil de remise sur l'affranchissement. Commencer par un sprint serait complètement passé à côté du problème des retours.

À faire, à éviter

À faire

• Nommer d'abord votre plus grande inconnue, puis choisir l'approche conçue pour elle.
• Alimenter les design sprints avec de la recherche. Un sprint qui repose sur de vrais insights utilisateurs est bien plus solide qu'un sprint bâti sur des suppositions.
• Continuer de tester avec les utilisateurs une fois la livraison agile lancée.
• Convenir dès le départ de qui porte le passage de relais entre les étapes, en particulier du sprint à la livraison.

À éviter

• Traiter les quatre comme des marques concurrentes ou demander laquelle est « la meilleure ». Autant demander si une carte vaut mieux qu'un marteau.
• Utiliser l'agile pour l'exploration. Des cycles de livraison courts ne remplacent pas la compréhension du problème.
• Mener un design sprint sans le décideur. Vous obtiendrez un bon prototype et aucune décision.
• Appeler « design sprint » n'importe quel atelier. Cinq jours avec la structure définie, c'est une chose ; une séance d'idéation de deux heures, c'en est une autre.
• Laisser chaque approche vivre dans un service différent avec son propre vocabulaire. C'est dans les passages de relais que l'apprentissage se perd.

Questions fréquentes

Un design sprint, est-ce la même chose que le design thinking ? Non. Un design sprint est un processus fixe de cinq jours qui utilise plusieurs outils du design thinking pour répondre à une question définie. Le design thinking est la démarche plus large, et son travail d'exploration précède généralement un sprint.

Le design thinking et l'agile peuvent-ils fonctionner ensemble ? Oui, et ils le devraient. Le design thinking détermine quoi construire et pour qui ; l'agile le construit par incréments. Le schéma courant : une période d'exploration, puis une livraison agile qui garde un rythme régulier de tests utilisateurs.

Lequel convient le mieux aux projets publics ? Cela dépend de l'inconnue. Le design thinking convient aux services où les besoins des citoyens ne sont pas clairs ; l'agile convient à la livraison numérique une fois les besoins clarifiés ; les expérimentations lean demandent une attention particulière au consentement et au risque quand le public est concerné. De nombreux référentiels publics de services numériques combinent exploration et livraison agile.

Pour aller plus loin

Pour l'exploration, commencez par les entretiens avec les parties prenantes. Pour réduire le risque d'une idée, utilisez la cartographie des hypothèses. Pour la journée de prototypage du sprint, voyez le prototype papier, et pour la livraison, les user stories. Tous les guides de méthode sont dans l'index des guides.