Le Product Owner ne s’occupe pas que de Business!

Pour le PO, le boulot ce n’est pas seulement de produire toujours de la valeur business (entendre la valeur d’usage du produit), c’est aussi d’optimiser l’intérieur de son produit jusqu’à l’intérieur de son organisation !

Les responsabilités du Product Owner

Le rôle de Product Owner est décrit dans l’approche Scrum de la façon suivante :

“Le Product Owner est responsable de l’optimisation de la valeur du produit […]”

En résumé, son rôle est d’optimiser les moyens dont il dispose (Times & Materials) pour produire le meilleur résultat possible. Aucune précision supplémentaire n’est apportée autre que “la façon de le faire peut varier largement suivant les organisations”.

La plupart du temps, nous focalisons notre attention sur les aspects liés à l’usage qui est fait du produit par ses utilisateurs. Ça n’est cependant qu’une partie des attributions du Product Owner.

Je propose de mettre en lumière d’autres domaines qui sont de la responsabilité du Product Owner même s’ils ne sont pas tous intuitifs, voire l’amènent à avoir un impact sur son organisation !

La responsabilité du Product Owner pour développer son produit sur le marché (entendre le lieu d’usage de celui-ci)

Le PO agit comme un “explorateur de marché” pour aller chercher, mettre en place tout ce qui va permettre de faire vivre et progresser son produit sur le marché : études de marchés, travaux sur les retours utilisateurs, expérimentations, améliorations des fonctionnalités….

Son produit doit apporter le plus de valeur le plus rapidement possible !

OK, mais pas seulement !

Se considérer exclusivement comme tel, serait détourner pour moitié le rôle de Product Owner et oublier d’autres responsabilités importantes qu’il doit porter :

• Assurer une maintenance au fil de l’eau de son produit
• Maintenir toutes les exigences non fonctionnelles (sécurité, performance)
• Assurer la maintenance du produit auprès des utilisateurs
• Assurer l’entretien régulier des composants qui le constituent (vieillissement)
• Maintenir un effort de maintenance le plus faible possible
• Assurer la cohérence et la compatibilité technique de son produit avec l’ensemble de l’organisation

Et quand la maîtrise de mon produit dans l’organisation m’échappe !

Ce dernier point, sur l’articulation du produit avec d’autres produits de l’organisation est souvent absent des discussions.

En effet, dans la réalité, le produit est souvent pris dans un ensemble d’interrelations complexes avec les autres produits, ce qui limite son autonomie.

Vous ne pourrez livrer votre produit sur le marché que lorsque l’autre produit dont vous dépendez aura livré la fonctionnalité dont vous avez besoin pour que l’ensemble fonctionne.

Comme si vous aviez besoin de travailler sur l’embrayage de votre voiture pour changer une roue !

Alors non seulement, vous vous trouvez ralenti par des modifications que votre équipe pourrait faire elle-même (et donc plus rapidement), mais en plus, il vous faut justifier auprès d’un autre Product Owner du bénéfice apporté (ce qui peut être chronophage !).

Le résultat dépendra en partie de la façon dont vous avez présenté votre besoin aux autres, mais aussi de la relation que vous entretenez avec eux.

Il est impossible de se débarrasser totalement des dépendances, mais lorsque cette situation se présente quasiment au quotidien, il faut alors reconnaître que cela devient un problème. En effet les sollicitations « à répétition » sont vite sources de conflits. Votre équipe peut s’en trouver démotivée; lasse de ne pas pouvoir toujours réaliser en autonomie les travaux que vous avez valorisés ensemble !

Votre responsabilité est alors engagée et on vous donne les moyens d’agir (extrait du SCRUM Guide : “l’ensemble de l’organisation doit respecter ses décisions”) !

Agir au fil de l’eau

Lorsque la situation est critique, le premier réflexe est de faire appel à un échelon managérial pour arbitrer. Ça fonctionne sur le coup, mais c’est aussi une façon de continuer à entretenir le problème, et plus vous en faite usage, plus vous enfermez votre produit dans une funeste dépendance !

Dès la première apparition des symptômes, envisagez plutôt de prioriser au fil de l’eau des sujets comme :

• La clarification des périmètres produit
• La réduction des développements spécifiques
• Le rapatriement de composantes techniques d’un composant vers un autre
• Le nettoyage d’un code dont on ne sait plus ce qu’il fait !
• La rétro documentation technique
• La création de périmètres techniques-fonctionnels clairs, simples et documentés

Ces travaux sont toujours difficiles à valoriser dans une organisation, en effet combien de refontes ou de documentation à postériori ont eu un coût très élevé sans parfois jamais être utilisées ! Les instances dirigeantes sont par ailleurs souvent (et à juste titre) très réfractaires aux reprises en profondeur, risquées, coûteuses et parfois sans effets ! D’où l’utilité d’y aller par petits pas successifs qui permettent de créer la confiance et de toujours maintenir une habitude de prendre en compte ce type de travaux.

Quelques conseils utiles pour vous lancer :

• Allez-y par petits pas successifs
• Evitez les grands changements qui promettent des lendemains meilleurs
• Ayez toujours en tête un bénéfice court terme mesurable
• Reconnaissez régulièrement avec votre équipe le bénéfice obtenu
• Prenez l’habitude de toujours faire du « nettoyage » au fil de l’eau

N’oubliez pas, si vous êtes Product Owner, vous aurez toutes ces responsabilités à assumer

Rassurez-vous, vous n’êtes pas isolé, votre équipe est là pour vous soutenir et vous aider à trouver les meilleures solutions ! Prendre en compte leur besoin est pour vous le meilleur moyen de souder toute l’équipe autour de vous pour atteindre la performance, 100% gagnant !