Qui est le boss de chaque élément du backlog ?

Les outils de gestion de projet, même considérés comme agiles, ont l'habitude de mettre en avant la possibilité d'associer un élément de travail (une user story, une tache, etc.) à une personne. 🧑‍💼

J'ai longtemps été perturbé par cette information. Que signifie-t-elle ?

Et ne faudrait-il pas simplement la supprimer ? ❌

L'interrogation est d'autant plus grande que, bien souvent, l'association ne propose qu'une unique personne. C'est bien connu : dans la majorité des cas, les gens travaillent seuls et de manière complètement isolée sur un sujet donné. 🤔

"Oui, plusieurs personnes peuvent travailler sur un sujet, mais sur des tâches distinctes. Découpe ton sujet en tâches et tu auras une personne par tâche."

Outre le fait qu'un découpage en plein de petites tâches, c'est galère à gérer, ça nous amène où ? Si j'ai une fonctionnalité développée par une personne et testée par une autre, je fais 2 tâches ?

"Si c'est la même tâche qui passe par plusieurs états, tu peux toujours modifier la personne en charge à un instant donné. Quand la fonctionnalité est en dev ou en test, ce n'est pas la personne qui y sera attachée"

Et c'est d'ailleurs comme ça que certains outils associent automatiquement la tâche à la personne qui a changé la tâche d'état. Spéciale dédicace aux scrummasters qui s'assurent que toutes les informations sont à jour dans un board et à qui il arrive de déplacer des tâches oubliées. 🤯

Et ne parlons même pas du pair programming. Une fois, j'avais entendu parler d'un projet où les gens envisageaient de de créer des comptes utilisateurs pour des paires, ce qui permettait d'associer une tâche à une paire. L'histoire ne dit pas ce qu'il auraient fait s'il y avait eu de l'ensemble-programming. Ils auraient révisé leur triangle de Pascal ?

"Si tu détestes tant que ça ce champ d'information où on met le nom d'une personne, il te suffit de ne pas l'utiliser"

Et c'est d'ailleurs ce que proposent des gens avec quelques arguments :

  • 🤝 Renforcer l'idée d'une propriété collective
  • ⚙️ Focaliser sur les fonctionnalités et non pas sur les personnes qui les implémentent
  • 😴 Éviter les situations où quelqu'un va se désintéresser d'un sujet car ce n'est pas le sien

Moi aussi j'ai été tenté par cette approche. Je pense même l'avoir parfois conseillée. Elle n'est ni bonne ni mauvaise.

Si aujourd'hui je devais pousser pour un usage précis et uniforme, je pense que je suggèrerais la notion de référent sur un élement de travail. Le référent, ce n'est pas forcément la personne qui fait le boulot, bien qu'elle y a probablement participé dans la plupart des cas.

Le référent, c'est la personne

  • 🤓 qui s'assure d'être au courant de tout ce qui concerne le sujet précis de cet élément de travail
  • 📞 que l'on va pouvoir contacter en priorité si on a besoin d'info
  • 👍 qui va faire en sorte que l'élément en question soit terminé au plus vite et avec l'attention nécessaire.

Cela peut être quelqu'un du produit, ce la peut être un expert métier, cela peut être un dev. L'idéal serait peut être même d'avoir une répartition équilibrée.

J'ai brièvement expérimenté une telle approche dans un contexte où il y avait besoin, à mon avis, d'inciter à plus de responsabilité individuelle de la part de tous les membres d'une équipe. C'est une approche exigeante car on a plus souvent l'habitude de se laisser porter.

Où, pour le dire autrement, la responsabilité d'une fonctionnalité est bien souvent laissée au product owner. Les autres membres de l'équipe se voient comme faisant avancer un élement en apportant une contribution ponctuelle mais ils se voient rarement comme responsables de bout en bout.

Est-ce que chez vous aussi la personne qui, objectivement, est associée à un élément de backlog pendant la totalité de sa (courte) vie, c'est le product owner ?

Une réaction ? Un commentaire ? Rejoignez la discussion.   linkedin   twitter