Cycle en V, Scrum, Lean startup, … le rapprochement progressif Devs-Users pour des meilleurs produits

“Rudderless agile lets us build the wrong products twice as fast as we did before”
Rich Mironov.

« Life is too short to keep building something nobody want »  
Ash Maurya.

 

Cet article parle de :

• L’importance d’améliorer le feedback utilisateur, entre autre par le rapprochement devs/users
• Ce que les différentes méthodos (waterfall, scrum, kanban, lean startup) préconisent concrètement sur ce sujet, ainsi que la tendance qui se dégage

 

L’importance du feedback utilisateur

Vous connaissez certainement cette situation où l’équipe se bat pour finir un projet dans les temps, pour se rend compte finalement peu de temps après la mise en prod qu’une partie des choses développées ne sont jamais utilisé, et que le produit développé ne répond pas vraiment aux besoins des utilisateurs.

Lorsque ce problème arrive, il est probable que les causes soient méthodologiques :

• la validation des développements n’est pas faite au fil de l’eau. Nous ferons l’hypothèse que ce point est quand même bien intégré maintenant par la majorité des équipes agiles.
• le produit, ses fonctionnalités et la façon dont elles sont implémentées se basent sur des hypothèses non vérifiées
• l’information sur le besoin et la meilleure façon d’y répondre est perdue/retardée/déformée dans son voyage entre l’utilisateur et le dev

Voici donc un test tout simple pour estimer la réception de votre application par vos utilisateurs finaux lors de la mise en production :

Quelle tête feront vos utilisateurs en découvrant votre appli ?

Explication

Nombre d’intermédiaires entre les utilisateurs et les dev (en ordonnées)

Pourquoi c’est important :

Même si l’agile est arrivé en France depuis quelques années maintenant, nos organisations sont encore trop souvent héritées de cette époque où l’on pensait pouvoir spécifier entièrement un logiciel à l’avance. Et pousser ensuite ces specs vers les développeurs, dans un mouvement en sens unique.

Il faut faire le deuil de cette idée. Les spécifications doivent être faites “Just In Time”, sur la base d’échanges entre les différents acteurs (devs, UX, PO, marketing, sponsor, utilisateurs …).

Car :

• les meilleures User Stories naissent de discussions informelles entre les différentes parties : devs, PO, métier, ux, designers, …
• les devs étant en première ligne (et souvent assez nombreux), ce sont souvent les dévs qui vont révéler des incohérences dans le produit imaginé, détecter les situations métier à la marge, les oublis,…
• ceux qui auront les réponses les plus pertinentes à ces questions métier sont ceux qui sont à l’autre bout de la chaîne : les utilisateurs ou, à défaut, ceux qui sont au plus près d’eux
• les meilleures idées (fonctionnelles) pour répondre aux besoins des utilisateurs pourront venir de n’importe où : utilisateurs eux mêmes, marketing, ux, devs,… et en général, elles naitront lors de dialogues entre deux personnes ayant un point de vue différent

Tout ce qui va ralentir les échanges de questions/réponse entre ces différentes parties est donc fortement nuisible à votre produit. Il faut s’assurer de la présence de canaux de communication rapides et directs.

Après, cela ne veut pas dire que les intermédiaires sont inutiles, au contraire : peut être ont ils une connaissance particulière, une faculté à exprimer simplement un besoin ou encore des caractéristiques humaines qui aident le projet. Mais ils ne doivent pas devenir un goulet d’étranglement et un passage obligé pour toute l’information.

Il existe de nombreuses configurations possibles selon les entreprises.

Pour se positionner sur le graph, on va chercher le chemin le plus court entre l’utilisateur et le développeur, qui passe par les personnes qui travaillent ensemble très régulièrement.

Prenons deux exemples classiques :

Dans l’exemple de gauche le Proxy Product Owner (PPO) sert d’intermédiaire exclusif pour tout échange entre les dévs et le Product Owner. Dans ce cas on se placera donc sur la ligne “2 intermédiaires” de l’abaque.

L’exemple de droite est presque identique mis à part que les dévs dialoguent également régulièrement avec le PO. Dans ce cas on pourra donc se positionner sur la ligne “1 intermédiaire”

Temps nécessaire pour valider une hypothèse métier (en abscisse)

Pourquoi c’est important

Quand on construit une appli, on se base, consciemment ou pas, sur une multitude d’hypothèses : les utilisateurs ont tels problèmes, tels profils, telles habitudes, tels besoins, telle solution répondra à leur problème, pour réaliser telle action ils comprendront qu’ils doivent faire cela… De la rapidité avec laquelle on obtient du feedback utilisateur sur ces hypothèses dépend la réussite du produit. C’est le postulat de base de toutes les méthodos récentes.

Toutes les méthodologies (Scrum, Kanban, lean startup, …) tendent à raccourcir le “time to feedback” utilisateur ou client, même si toutes ne le font pas de la même manière, comme nous le verront plus bas.

Comment se positionner sur la courbe : ex : si pendant toute la durée du cycle de vie du projet, les utilisateurs finaux n’ont rien vu ( ni maquette ni release intermédiaire) alors le ‘time to feedback’ = la durée du projet. Dans l’extrême inverse, si vous livrez toutes les semaines une nouvelle version à vos utilisateurs et recueillez / mesurez leur feedback dans la foulée, alors votre temps est d’une ou deux semaines.

Comment se positionnent les différentes méthodos sur ces sujets ?

Cycle en V

Dans un cycle en V, on va typiquement se retrouver dans la partie du graph où l’utilisateur a les cheveux en flamme. Les specs sont écrites longtemps en avance. La communication se fait principalement par écrit, les specs passent dans les mains de nombreux intermédiaires. Les hypothèses ne sont pas vérifiées.

Si des projets dits ‘agiles’ se retrouvent également dans cette partie du graph c’est à cause d’une organisation ou d’habitudes héritées de cette époque.

EXtreme Programming (XP)

XP encourage la présence du client (au sens commendataire de l’application) sur site avec les développeurs. Si ce “client” est une personne en contact direct avec les utilisateurs finaux, alors on a une situation très saine.

Concernant la validation des hypothèses : Si XP précise que le client doit être livré tous les semaines (dans sa dernière version), il ne dit cependant rien sur la validation des hypothèses métier par du feedback utilisateur final. Cela dépendra donc de la pro activité du client et cela est hors scope d’XP.

Lean Startup

Le Lean Startup encourage la validation des hypothèses le plus tôt possible, via l’interview des utilisateurs et la livraison de Minimum Viable Products. On est donc dans la partie la plus a gauche du graph.

L’organisation recommandée pour les équipes est également optimisée pour l’obtention d’informations pertinentes sur le produit :

• une « Problem Team » dont l’activité principale se déroule “outside the building” : « interviewer des consommateurs, faire des tests d usabilité,…
• une « Solution Team » dont les activités se déroulent principalement « inside the building » : développement, tests, déploiement, …

Remarquez le « principalement « . Car en lean startup les équipes sont fortement cross fonctionnelles et il est de la responsabilité de tout le monde de parler aux utilisateurs. On a donc un contact direct et régulier rentre devs et utilisateurs.

Scrum

En Scrum, le Product Owner (PO) est au centre de cette problématique d’expression du besoin. Selon les situations (et les interprétations), le PO sera plus ou moins loin du client final. Il n’est pas précisé par exemple si le PO doit faire partie du métier ou pas. Dans tous les cas, la situation idéale est que le PO soit en contact direct régulier avec les utilisateurs. Dans les faits ce n’est pas toujours le cas.

Concernant la validation des hypothèses, Scrum encourage de livrer et démontrer au client (client au sens commanditaire de l’appli) régulièrement. Ce qui représente un premier niveau de validation des hypothèses intéressant. Mais ne remplace pas la validation et le feedback des utilisateurs finaux.

Une nuance cependant puisqu’Alistair Cockburn (un des fondateurs de Scrum) proposait récemment de mixer Scrum et Lean Startup en utilisant chaque sprint pour valider des hypothèses business.

Deux organisations Scrum classiques. Attention, dans la situation de droite il faut être très vigilant sur les démos de fin de sprint. Car si par malheur vous ne faites pas de démo régulières ou si elles sont bâclées, alors vous êtes en réalité dans un cycle en V déguisé. Avec tout ce que cela implique comme retard, fin de projet chaotique, produit déconnecté de la réalité des utilisateurs, etc…

Lean Kanban

Il existe plusieurs interprétation du lean dans le monde l’IT mais en général elles ne définissent pas de rôles ni de façon de gérer son produit. Elles ne se positionnent donc pas directement sur le graphique.

Enfin ça c’est la théorie. Car en réalité, le fait de passer à Kanban ou à Scrumban, et donc de chercher à fluidifier le flux, aboutira fatalement à faire tomber quelques barrières entre les dévs et les utilisateurs. Et à créer des canaux de communication rapide entre les dévs et les personnes capables de répondre de manière pertinente à leurs questions.

Mobius loop

Une nouvelle méthodo que je n’ai jamais essayé personnellement mais qui semble intéressante en cela qu’elle permet de challenger la solution ET le problème résolu par la solution à chaque itération.

Ce que ce test ne dit pas

Si ce test vous donne déjà une bonne tendance, il y bien sûr d’autres éléments qui vont venir moduler tout ça et influer positivement ou négativement sur l’adéquation entre ce que vous développez et l’attente des utilisateurs.

Par exemple :

• La communication entre les différentes parties se fait-elle par écrit majoritairement ? lors de réunions ? En dialogue face à face ? par téléphone ? La quantité et la qualité des informations remontées variera fortement selon les modes de communication préférés
• L’expérience utilisateur (UX) est-elle une préoccupation quotidienne ? Une personne est-elle dédiée à ces aspects ?
• Vos développeurs ont-ils une appétence pour le fonctionnel et une séniorité suffisante pour pouvoir challenger la solution ?
• Tous les membres de l’équipe sont-ils capable de faire l’elevator pitch de votre appli ? connaissent-ils les principaux profils utilisateurs (ou personnas) ? Ont-ils déjà été mis en position d’utiliser les solutions alternatives à votre appli ?
• Votre équipe est-elle potentiellement utilisatrice de votre appli ? Si c’est le cas, vous aurez un input utilisateur de première main. Quand à savoir si vos profils sont représentatifs des futurs utilisateurs finaux de l’appli, là c’est une autre question
• …

Bref, savoir à l’avance si votre application répondra aux besoins des utilisateurs est un exercice difficile. Le plus important est de minimiser le risque en se mettant dans les meilleurs conditions possibles.

Ressources

« Running lean » de Ash Maurya.

Scrum guide

Mobius loop

Une organisation de type lean startup chez BufferApp

Le logo de l’utilisateur avec les cheveux en flamme vient du livre « Code complete » de Steve McConnell (repris également dans le blog de Jeff Atwood, Coding horror)

L’image « Brittany, will you marry me » a été empruntée au compte twitter « You had one job »