V, Scrum, Lean startup, … le rapprochement progressif Devs-Users

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, et 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 que le produit ne répond pas vraiment aux besoins des utilisateurs.

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

• l’information sur le besoin et la meilleure façon d’y répondre est perdue/retardée/déformée dans son long voyage entre l’utilisateur et le dev
• 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

Concrètement, voici un test tout simple pour estimer la tête que feront les utilisateurs de votre appli lorsqu’ils la verront pour la première fois :

Quelle tête feront vos utilisateurs en découvrant l’appli ? positionnez vous sur le graph pour le prédire

Explication :

Si le feedback utilisateur met trop de temps à arriver jusqu’à vos développeurs (abscisse), votre produit va dériver et risque de ne pas répondre à son objectif.

De même, si il y a trop d’intermédiaires entre les développeurs et les utilisateurs (en ordonnée), l’information sera diminuée en quantité et en qualité, et le produit dérivera également.

Si on combine les deux, le résultat est détonnant.

Diminuer le nombre d’intermédiaires entre les utilisateurs et les dev

Pourquoi c’est important :

Il faut faire le deuil de l’idée selon laquelle on peut spécifier entièrement à l’avance une appli et pousser ensuite ces specs vers les développeurs, dans un mouvement en sens unique.

Les spécifications doivent être faites sur la base d’échanges constants entre les différents acteurs (devs, UX, PO, marketing, sponsor, utilisateurs …) avant, pendant, et après le développement du produit.

Les intermédiaires risquent donc de venir ralentir ce flux d’informations.

Après, cela ne veut pas dire que les intermédiaires sont complètement inutiles : 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 passage obligé pour toute l’information, et donc un goulet d’étranglement.

Diminuer le temps nécessaire pour valider une hypothèse métier

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 et tels besoins, telle solution répondra à leur problème, ils comprendront tout de suite qu’ils doivent faire telle chose…

De la rapidité avec laquelle on obtient du feedback utilisateur sur ces hypothèses dépend la réussite du produit.

C’est sur ce postulat que se basent toutes les méthodos récentes.

Scrum, Kanban, lean startup, Design thinking… tendent toutes à raccourcir le “time to feedback” utilisateur ou client, même si elles ne le font pas toutes de la même manière, comme nous allons le voir.

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 certains 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, avec peu d’intermédiaires.

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 d’utilisateurs finaux. 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 de Scrum), 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, du marketing ou de la technique. 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.

Voici deux types d’organisations Scrum classiques :

Attention, si vous êtes 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.

Conclusion

Si le test plus haut vous donne déjà une bonne tendance sur la réception de votre produit par les utilisateurs, il y bien sûr d’autres éléments qui vont venir moduler tout ça positivement ou négativement. Comme par exemple le fait que la communication entre les parties se fasse plutôt à l’oral ou à l’écrit.

Ressources

• « Running lean » de Ash Maurya.
• Scrum guide
• 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 »

Cet article a été initialement publié sur le blog de Xebia