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 Soft’it
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.
"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"
Ah, quelle bonne surprise ! 🙂
Deja, le scrum est mis en place dans pas mal de boites avec comme argument "on va plus avoir besoin de faire des specs". Donc de la à virer le product owner et laisser les devs seuls avec le client….
Dites, vous qui avez de bonnes idées, si on virait les devs ? Ils coutent cher, on voit pas trop a quoi ils servent et on pourrait les remplacer par des stagiaires…
pareil pour l'admin sys ou les graphistes d'ailleurs.
En fait, si on virait le boss ? Le ceo ? le cto ?
voire même, soyons francs : le marketing ?
On y repasse 45 minutes ?
Bonne journée,
Camille
Bonjour Camille,
Pour tout te dire, Caroline ayant proposé d'avoir cette réflexion est elle-même Product Owner.
Elle se demandait, sans vouloir démontrer quoi que ce soit, si son rôle était vraiment indispensable.
Le but de cette réflexion et par conséquent de cet article n'est en aucun cas de démonter le rôle de Product Owner mais d'avoir une réflexion autour de ce poste et de sa nécessité dans un cadre où l'équipement de développement se situe à 1 étage au-dessus des clients.
Bien à toi,
Cédric