Les problèmes d intégration d une approche Design Thinking à un cadre opérationnel Scrum

By Vincent Loiseau.

Après vous avoir introduit l’approche Design Thinking et son utilité pour la gestion de produit, nous vous partageons quelques problèmes fréquemment rencontrés chez nos clients.

Problème 1 – Avoir un Product Backlog complètement structuré en fonction des écrans issus des prototypes

Les apprentissages générés grâce aux prototypes peuvent mener à la construction d’un Product Backlog complètement orienté "action sur l’interface graphique", au détriment des fonctionnalités. Nous avons constaté chez des clients que l’écriture des User Stories pouvaient se décomposer en une User Story décrivant l’accès à un écran ou une information, puis une seconde User Story décrivant l’écran ou l’information attendue:

US 1: En tant que Richard je souhaite cliquer sur le bouton "Mes commandes" pour accéder à la liste de mes commandes

US 2: En tant que Richard je veux voir liste de mes commandes triées par date de création décroissante afin de savoir où en est la livraison de la dernière commande que j’ai passée.

En confrontant ces deux User Stories avec le modèle INVEST qu’elles devraient suivre, nous constatons les choses suivantes:

• I – Indépendante – Les deux US sont dépendantes l’une de l’autre. Si l’une des deux n’est pas réalisée, l’autre n’est pas utilisable.
• N – Négociable – La première US est trop simple et petite – Il n’y a aucune possibilité de la négocier.
• V – Valeur – Quelle est la valeur de cliquer sur un bouton pour accéder à une liste de commandes? Aucune. La première US est bien trop petite.
• E – Estimable – Oui biensûr.
• S – Suffisament petite – Elles le sont même trop.
• T – Testable – Oui elles le sont toutes les deux, même si tester l’affichage d’un écran ou d’une fonctionnalité lorsqu’on clique sur un bouton n’est pas ce qu’il y a de plus intéressant à réaliser et pertinent comme test.

Ce type de découpage de User Story, orienté interface graphique, impose une charge de travail trop grande pour les équipes de développement et leur product owner. Les premiers doivent mettre des tests en place pour valider des sujets qui n’apportent pas de valeur. Les seconds passent trop de temps à rédiger de petites User Stories, souvent au détriment d’échanges avec les utilisateurs ou d’analyses du marché.

Problème 2 – Le temps de mise sur le marché du produit est ralenti

Les cinq phases de l’approche Design Thinking sont en très grande majorité réalisées avant le lancement de l’implémentation. Le cadre de travail Scrum a permis de diminuer drastiquement la date de démarrage de l’implémentation des fonctionnalités par rapport aux approches traditionnelles de gestion de projet.

Nous avons constaté plusieurs fois chez des clients différents que l’approche Design Thinking était réalisée entièrement avant le moindre lancement des développements. Le livrable pour les équipes de développement était un prototype complet et validé de ce qui devait être réalisé. Cela revient à remettre en place une phase de spécifications détaillées avant le lancement de l’implémentation.

Cela provoque un retard du premier sprint, un retard de feedback sur les incréments réalisés et donc par la même occasion un retard de mise sur le marché.

Problème 3 – On ne profite pas de faire monter en connaissance fonctionnelle l’équipe de développement

Nous avons constaté que les approches Design Thinking étaient réservées à des experts chez plusieurs de nos clients. Si l’équipe de développement ne peut pas participer aux différentes phases de l’approche, elle se coupe de la connaissance du contexte des utilisateurs, des problèmes réels qu’ils essayent de résoudre. L’équipe ne pourra donc que très peu apporter des innovations. Il ne faut pas oublier qu’une équipe ne peut être performante si elle ne connaît pas bien le sujet fonctionnel et les problèmes réels qu’elle doit résoudre. Elle se contentera d’implémenter des solutions imaginées par d’autres.

Problème 4 – Le prototype validé est considéré comme validation des hypothèses

L’approche Design Thinking limite les risques de cibler la mauvaise solution pour répondre aux problèmes des utilisateurs. Cependant, ce n’est pas parce qu’un prototype est validé par les utilisateurs que la solution est satisfaisante pour eux. Voici deux cas que nous avons rencontré chez nos clients:

• les utilisateurs sur lesquels le client s’est appuyé pour réaliser l’approche Design Thinking étaient des experts de leur domaine. L’expérience utilisateur proposée s’est avérée un échec lorsque la solution définie a été mise dans les mains d’utilisateurs "usuels". La solution était trop complexe à appréhender pour eux.
• La nouvelle version d’une solution offraient de nouvelles fonctionnalités et s’ouvraient à de nouveaux utilisateurs externes à l’entreprise. L’expérience utilisateur a été validée par des prototypes qui n’ont été présentés et validés qu’aux utilisateurs internes. Les nouveaux utilisateurs externes n’ont finalement eu accès la nouvelle version qu’à la fin du projet. Rien ne permettait d’assurer que la solution choisie convienne aussi à ces derniers.

Problème 5 – Le résultat des prototypes issus d’une approche Design Thinking se rajoute à une charge déjà importante de travail à faire dans le Product Backlog

L’intégration d’une approche Design Thinking fonctionne plutôt bien dans un contexte de nouveaux produits. Cependant, nous avons constaté chez plusieurs de nos clients qu’il n’en était pas de même lorsque le Product Backlog était déjà bien rempli de sujets à réaliser et que la capacité de l’équipe de développement n’était pas suffisante pour tous les adresser rapidement.

Nous avons remarqué les difficultés que certains Product Owners avaient à prioriser les sujets contenus dans leur Product Backlog. Voici les trois options qu’ils retenaient le plus en général:

Nous devons refondre l’expérience utilisateur que l’on propose aux utilisateurs au plus vite!

Cela satisfait certainement les participants aux ateliers, mais risque de crisper plusieurs utilisateurs qui attendaient d’autres fonctionnalités déjà planifiées.

Nous devons finaliser nos premiers engagements avant de travailler sur l’expérience utilisateur!

En général, cela frustre toutes les parties prenantes à la mise en oeuvre de la nouvelle approche et, à long terme, rajoute une défiance supplémentaire à toute volonté de changement dans les entreprises.

Ou encore, et certainement la pire des solutions:

On doit mener ces sujets de front!

Les premiers à grogner sont les membres de l’équipe de développement, pour qui le souhait de "rythme soutenu mais soutenable" ne devient plus qu’une utopie.

Et puis finalement tout le monde est insatisfait puisqu’aucun sujet n’avance réellement, les bénéfices attendus encore moins.