Qu'est-ce qu'un Product Owner Agile ?

Le rôle du Product Owner est propre au cadre agile. En tant qu'agent de liaison entre les équipes commerciales et de développement, le Product Owner doit être le pont qui aide une organisation à atteindre ses objectifs.

Le propriétaire du produit met en œuvre la vision du produit, définit les critères du projet et gère le backlog du produit.

Voici les Les cinq principales façons dont tout propriétaire de produit peut améliorer ses performances et diriger efficacement :

1. N'oubliez pas que le leadership engendre le travail d'équipe

Les projets avec plusieurs propriétaires de produits ou des propriétaires de produits de haut niveau sont plus difficiles et plus susceptibles d'échouer que de réussir.

Pourquoi le fait d'avoir plusieurs propriétaires de produits n'est-il pas efficace ? Parce que si vous avez plusieurs propriétaires de produits, qui prend les décisions ? À qui les parties prenantes doivent-elles s'adresser ? À qui les développeurs et les Scrum Master répondre à leurs questions ?

Que se passe-t-il si les propriétaires du produit ont deux points de vue opposés ? Que se passe-t-il s'ils ne s'entendent pas ? Qui est réellement responsable et le véritable propriétaire du produit ?

Le fait d'avoir plusieurs responsables de produit dans un projet augmente les risques d'hypothèses et de points de vue contradictoires. De plus, la présence de plusieurs responsables de produit peut entraîner une confusion inutile lors de la prise de décisions et de la définition des meilleures pratiques.

Le « bon » propriétaire du produit doit être disponible pour s’approprier pleinement le produit et y consacrer la majeure partie de son temps.

Pourquoi un cadre supérieur, un vice-président ou un manager est-il inefficace en tant que responsable produit ? Bien qu'il soit utile d'avoir un responsable produit de niveau C ou vice-président, les personnes occupant ces postes sont rarement des responsables produit agiles efficaces. Leur fonction principale consiste à gérer des services entiers et de multiples processus.

Les responsables de produit de haut niveau ne pourront pas se concentrer sur un projet ou un produit spécifique pour en assurer le succès. Les responsables de produit assistent à toutes les réunions, s'impliquent dans les moindres détails du projet et gèrent tout. Ce sont des attentes déraisonnables, et il est peu probable qu'un responsable de haut niveau ait le temps de tout faire.

Un propriétaire de produit devrait consacrer entre 60 et 100 pour cent de leur temps et de leurs efforts pour qu'un projet réussisse. Que se passera-t-il avec leurs autres tâches et leur travail si le responsable de niveau supérieur est propriétaire d'un produit ? Au lieu de cela, la haute direction devrait choisir avec soin le responsable du produit et lui donner les moyens de prendre les bonnes décisions.

Le « bon » propriétaire du produit doit être disponible pour :

• S'approprier pleinement le produit et y consacrer la majeure partie de son temps.
• Parlez avec toutes les parties prenantes et communiquez clairement avec le Scrum Master et les développeurs.
• Transmettre clairement une vision du produit final qui guide le processus de développement.
• Donnez la priorité aux fonctionnalités tout en communiquant le raisonnement derrière toutes les décisions.

2. Gérer les parties prenantes en instaurant la confiance

Le défi le plus courant des propriétaires de produits est de gérer les parties prenantes et leurs attentes.

Pour représenter efficacement les parties prenantes auprès de l’équipe de développement, le responsable produit doit gagner leur confiance. Il doit être convaincu qu’il saura exprimer ses besoins aux développeurs et savoir ce qui est « essentiel » à développer.

Alors, comment gagner la confiance des parties prenantes ? le Scrum Master, écouter et apprendre des parties prenantes.

Connaissez-vous déjà les parties prenantes ? Si c'est le cas, vous avez peut-être déjà leur confiance. Si vous ne les connaissez pas, apprenez à les connaître dès maintenant.

Commencez par la première étape, facile, qui consiste à vous présenter, à décrire votre rôle et vos attentes. La deuxième étape consiste à leur poser des questions sur leur travail et leurs besoins. Écoutez leurs frustrations et leurs attentes par rapport à la nouvelle solution. Les gens sont plus que prêts à parler de leurs processus et à partager leur expertise.

Pour représenter efficacement les parties prenantes auprès de l’équipe de développement, le propriétaire du produit doit gagner leur confiance.

Parfois, vous rencontrerez des détracteurs qui sont contre le nouveau produit et qui ne veulent pas changer et travailler avec vous. La stratégie la plus simple pour faire face aux détracteurs est de les contourner.

Cependant, s'ils ont des arguments valables, vous devriez les écouter et prendre en compte leurs commentaires. Veillez simplement à ce qu'ils ne vous détournent pas de votre mission première, qui est de créer un produit performant.

3. Assurez-vous que tout le monde comprend le storyboard

Le storyboard dans Développement agile contient vos exigences et ce que les développeurs doivent construire. Si les histoires sont confuses, peu claires ou mal hiérarchisées, le projet ne réussira pas. Ainsi, les propriétaires de produits doivent se concentrer sur la gestion du backlog produit et des sprints.

Lorsque les parties prenantes soumettent des commentaires, assurez-vous de :

• Examinez attentivement chaque élément de rétroaction.
• Acceptez uniquement les commentaires clairement définis et ayant une valeur commerciale.
• Examinez et rejetez tous les autres commentaires.

Pour obtenir des commentaires et des histoires clairs, montrez aux parties prenantes à quoi sont censés ressembler des commentaires et des histoires de qualité.

Après le lancement d'un projet, accompagnez les parties prenantes pendant les premières semaines. Vous devez les accompagner tout au long de la création de l'histoire et du processus de feedback.

Lors de la démonstration, montrez-leur le lien entre leurs histoires et ce qui a été développé. Plus les parties prenantes se familiariseront avec le projet, plus vous pourrez vous efforcer d'améliorer le processus.

4. Les compétences du Product Owner se développent avec la pratique

Nous avons écrit sur les 5 compétences indispensables du Product Owner, mais personne ne commence en tant que propriétaire de produit agile parfait.

Le cadre agile récompense l'expérience. Voici un excellent article pour vous aider à réfléchir au canevas du produit Apprenez à utiliser la méthodologie Scrum et à affiner votre vision des objectifs du produit. Des éléments comme la communication et la manière de déléguer des tâches deviendront plus intuitifs à mesure que vous et votre équipe évoluerez ensemble.

5. Qu'est-ce qui fait un bon Product Owner ? Restez calme et automatisez

En tant que Product Owner, vous devez gérer plusieurs personnes et leurs attentes, en plus de l'ensemble du backlog produit. Cela représente beaucoup de travail qui demande du temps et des efforts. Ne soyez donc pas surpris si, parfois, vous vous sentez dépassé.

Si vous vous sentez dépassé, faites une pause. Ayez une vue d'ensemble et demandez de l'aide à d'autres personnes.

De plus, vous devez automatiser autant d'étapes de communication que possible. Par exemple, vous pouvez créer des modèles dans PowerPoint ou utiliser des outils pour les étapes de projet suivantes :

• Lancez le projet et définissez clairement les objectifs.
• Établir des canaux de communication clairs et répondre aux attentes.
• Créez un modèle hebdomadaire pour présenter l’état du projet aux parties prenantes.
• Créez un flux de travail et un processus pour les démonstrations de produits hebdomadaires ou bimensuelles et la collecte de commentaires.

Enfin, n'hésitez pas à demander de l'aide si vous en avez besoin. Demandez l'aide de la direction si vous ne vous sentez pas en mesure de prendre les décisions nécessaires. Demandez l'aide du Scrum Master pour le backlog produit et le processus de développement.

En tant que propriétaire de produit dans un cadre agile, vous avez beaucoup de responsabilités et de travail à faire. Mais tout ce travail acharné portera ses fruits lorsque le projet sera terminé et que le produit sera disponible.