Tout bon chef de projet le sait : un projet ne peut réussir que si le besoin client/utilisateurs est compris et pris en compte. Mais quand on en arrive à la pratique, les couacs sont fréquents. 

En approche "prédictive" (on essaie de tout prévoir au départ pour qu'il n'y ait pas de changement), les équipes bien organisées font des études complètes du besoin au démarrage. Mais en cours de projet, la traçabilité entre ce que vous développez et ce besoin utilisateur est facile à perdre. Même si ce besoin était initialement parfaitement défini, complet, clair et bien interprêté (ce que je n'ai jamais vu).  

En Agile, le risque d'oublier ou de faire dériver le besoin client est couvert en partie par les rencontres fréquentes avec le dit-client : à chaque itération, son feedback permet de réajuster le tir en cas de mauvaise compréhension ou d'oubli. Sur le papier, tout est donc parfait. 

Mais dans la vraie vie, que se passe-t-il? 

Plusieurs équipes agiles qui m'ont appelée au secours avaient un backlog qui ressemblait plus ou moins à ça :

Vous avez vu le problème? Bingo! La colonne de droite s'intitule User Story, mais elle contient en fait des tâches de développement. 

Eh oui! Tout développeur contient malheureusement en natif la fonction de traduction automatique "besoin utilisateur --> tâche de développement". 

Comment on en arrive là ?

Avec un Client/PO (Product Owner, celui qui est censé écrire les US) peu expérimenté, ou peu sûr de lui.

Avec un SM (Scrum Master, celui qui est censé aider le PO et l'équipe dans leur boulot et faciliter le projet) qui a un profil trop technique ou qui laisse un peu trop faire l'équipe. 

Vous me direz : où est le problème? Après tout, une fois les tâches développées, les fonctionnalités sont là. Et comme le client voit le résultat toutes les 2 ou 3 semaines, il peut faire rectifier si nécessaire. 

Les effets de bord sont plus vicieux que ça :

1- la logique étant une logique de développement et pas une logique d'utilisation, le résultat de fin d'itération ne "parle" pas au client : OK l'écran est là, mais il ne sert à rien. Soit le client va dire "c'est beau/pas beau", soit il va embêter l'équipe sur des détails graphiques futiles. Dans tous les cas, les feedbacks sont peu constructifs.

Il arrive même qu'il n'y ait rien à montrer au client --> pas de feedback. 

2- Ce n'est jamais fini. 

D'un point de vue utilisateur, c'est au niveau de chaque EPIC que ça se passe. Or une EPIC peut prendre des mois à être complétée.Et dans cette logique, une seule petite tâche manquante fait que l'EPIC n'est pas complète. 

3- le client se désintéresse du projet. 

Les revues de fin d'itération ne lui parlent pas. Le choix entre "est-ce qu'il vaut mieux développer la partie Base de données ou faire le mécanisme d'envoi des données sur le serveur?" ne le concerne pas vraiment. 

Il finit par se détacher du projet. D'autant que les cérémonies finissent par devenir des réunions d'équipe de développement, où l'on discute technique. 

C'est ce que j'appelle les projets/entreprises pris en otage par la technique. L'inverse existe aussi, j'en parlerai dans un autre post. 

Que faire? 

Soignez votre PO, aidez-le à garder le pouvoir sur l'expression des US. 

Choisissez bien votre SM, qui doit arriver à maintenir l'équilibre entre la technique et la vision utilisateur. 

Entrainez-vous tous à raisonner "découpage utilisateur" même si c'est perturbant au début.

Et gardez en tête que ce genre d'approche est valable pour tout type de projet, même en dehors de l'informatique.