Les Open-Spaces Agile France

Jeudi 17 et vendredi 18 juin se sont déroulées les journées d’Agile France.

La journée du 17 juin est découpée en deux parties : une première matinée avec diverses conférences et l’après-midi organisée autour d’open-spaces.

Les open-spaces sont des sessions spontanées, autour d’un thème improvisé à la volée par une personne, qui propose son sujet et un lieu pour un débat de 45 minutes.

L’une des sessions, proposée par Caroline Damour avait pour Thème « Et si on se passait du Product Owner »

Le P.O, métier de plus en plus tendance au fur et à mesure de l’adaptation de l’agilité au sein des entreprises est devenu indispensable dans les organisations fonctionnant en Scrum.

L’idée de cette session, est de peser le pour et le contre afin de déterminer si ce rôle est réellement nécessaire en se basant d’un postulat où les clients/utilisateurs sont situés à un étage en dessous de l’équipe de développeurs.

Rappel du rôle de Product Owner

Le Product Owner est en charge de gérer le produit dans la méthodologie Scrum. Il est le lien entre les développeurs et le client.

Celui-ci s’occupe d’analyser et de prioriser avec le client les tâches dont il a le plus besoin afin d’améliorer son ROI, ainsi que de valider les développements à réaliser.

Il s’occupe de maintenir un stock de tâches à réaliser par l’équipe afin qu’ils puissent assurer un flux continu de développement.

Il est également en charge de la rédaction des « User Stories », pour lesquelles il a pour objectif d’être le plus complet possible.

En outre, son rôle est d’assurer que le produit délivré corresponde le plus possible au besoin du client.

Pouvons-nous nous en passer ? Qui le remplacerait ?

L’équipe

Aperçu d’une partie de notre équipe

Qui serait le plus à même de remplacer ce rôle, l’équipe?

Pourquoi pas après tout? Cela leur permettrait de comprendre au mieux le besoin client, de prendre plus de responsabilités dans le logiciel délivré en recevant directement les demandes du client.

Cependant, ce n’est pas si simple, qui s’en occuperait au sein de l’équipe ? Toute l’équipe ? Une seule personne ? Au final, cela ne reviendrait-il pas à mettre son rôle de développeur de côté pour reprendre celui de Product Owner ?

Pouvons-nous nous passer des tâches qu’accomplit un P.O?

Et si, au lieu de répartir les tâches du P.O sur l’équipe, nous nous passions des tâches qu’il a pour mission d’accomplir?

Peut-on se passer de la priorisation ? Il est bien difficile de répondre par l’affirmative à cette question, d’autant plus que les utilisateurs ont souvent des besoins bien différents de ceux de leurs employeurs.

Des besoins où leur avantage tiré de la fonctionnalité ne correspond pas forcément aux priorités de l’entreprise. Mais qui leur permettrait de leur faciliter davantage la vie.

Admettons que nous nous passions de la priorisation, que les clients soient à même, d’affiner leurs demandes et de les prioriser, qui s’occuperait de maintenir un flux constant pour l’équipe?

Caroline, animant la session, indique que lorsqu’elle n’est pas là, ou qu’elle n’a pas laissé un stock assez important de tâches à accomplir à son équipe, ceux-ci descendent voir les utilisateurs et s’occupent de chercher d’eux même leur travail pour la journée.

Cependant ce travail correspond surtout aux besoins que l’utilisateur remonte, le petit plus qu’il aimerait, pas forcément ce qui ferait gagner le plus de temps à toute son équipe.

Cependant, admettons que celui-ci donne directement les tâches les plus pertinentes. Qu’ils arrivent à alimenter assez le stock sans avoir à relancer régulièrement les clients pour obtenir ce qu’ils veulent, est-ce que l’aspect technique ne prendrait pas le pas sur l’aspect fonctionnel?

Il est difficile, en tant que développeur, de ne pas imaginer directement la partie immergée de l’iceberg et de proposer la solution la plus simple à développer, même si elle n’est pas la plus pertinente pour l’utilisateur.

Responsabilités

Un des avantages, de partager les rôles, est également de pouvoir répartir les responsabilités.

La charge correspondant à l’ensemble des emplois au sein d’une équipe agile SCRUM est assez monstrueuse lorsqu’elle n’est répartie que sur un seul pilier.

Il est difficilement envisageable de demander à une équipe ou bien encore à un un développeur en particulier d’endosser le rôle de Scrum Master et de Product Owner à la fois sans impacter la production fournie en terme de développement.

Disponibilité

Un des avantages principaux ressorti, concerne la disponibilité.

Le Product Owner, du fait de son métier, se doit d’être disponible pour gérer les demandes clients ainsi que les retours de son équipe.

Il s’assure de la compréhension du besoin par son équipe à tout moment ainsi que de la remontée des demandes clientes, tels que les nouvelles fonctionnalités ou les bugs.

Il est difficile (et je parle en tant que développeur) de se faire interrompre en permanence sans perdre son fil dans le développement et ainsi sa productivité, là où un Product Owner a plus de facilité à gérer ces interruptions et à se montrer disponible.

Un rôle dont il est difficile de se passer

Aperçu du tableau à l’issue de la discussion

A la fin de ces 45 minutes (cf : tableau), nous sommes parvenus à la conclusion que le rôle de Product Owner est difficilement remplaçable, même dans le cadre où les utilisateurs sont proches et situés à un étage en dessous de l’équipe de développement.