Business : Pourquoi de nombreux propriétaires de produits échouent-ils?

Le rôle Product Owner est similaire à la définition Scrum. Simple à comprendre, difficile à maîtriser. Le Scrum Guide clarifie la mission du Product Owner, mais suppose que l’exécution peut varier considérablement en fonction de la situation de l’organisation. Donc, vous êtes seul en matière d’implémentation.

le Propriétaire du produit est responsable pour maximiser la valeur du produit résultant du travail de l’équipe de développement. Comment cela se fait peut varier largement à travers les organisations, Équipes Scrum, et personnes.

Guide Scrum

Alors, comment peut-on être un chef de produit réussi? Les compétences en gestion de produits sont la réponse, car les chefs de produit savent comment créer d’excellents produits et ce que signifie la valeur. Sans cette connaissance, il sera difficile de prospérer en tant que Product Owner.

L’expert en gestion de produits de Scrum est appelé le Product Owner. Un excellent Product Owner est un solide Product Manager. Vous ne pouvez pas être un bon propriétaire de produit sans comprendre la gestion des produits. Sans suivre les pratiques de gestion des produits, Scrum ne peut pas tenir sa promesse de fournir des produits de la plus haute valeur possible.

– Maarten Dalmijn, Devriez-vous embaucher des chefs de produit ou des propriétaires de produit pour vos équipes Scrum?

La complexité ne s’arrête pas aux compétences de gestion de produit. Dans Scrum, la figure d’un chef de projet est inexistante, qui doit le gérer? Le propriétaire du produit acquiert également cette responsabilité.

Ma photo préférée d’un Product Owner est les quatre quadrants, qui Bob Galen décrit comme suit.

Passons maintenant aux anti-patterns. Quelles sont les mutations les plus courantes que j’ai jamais vues?

• serveur: reçoit les commandes et les envoie directement à l’équipe. Le comportement du serveur entraîne une faible valeur commerciale et de nombreuses fonctionnalités inutiles.
• Directeur: microgérer l’équipe et se comporter comme le manager de l’équipe de développement.
• Architecte: définit toutes les solutions seules. L’équipe de développement n’a pas de voix sur la façon de résoudre les problèmes.
• Protecteur: protégez l’arriéré et le verrouillage pour que personne ne puisse le gérer, seul le propriétaire du produit peut toucher cet enfant.

« Puis-je prendre votre commande, monsieur / madame? « . C’est ainsi que les fonctionnalités inutiles commencent.

Le Product Owner agit littéralement comme serveur. Dans ce scénario, le Product Owner n’est pas propriétaire de la hiérarchisation. Au lieu de cela, il ou elle ne reçoit que les commandes ou les souhaits des parties prenantes, écrit les éléments du carnet de produit et les remet à l’équipe sans remettre en question le besoin.

Ce scénario est répandu car certaines entreprises pensent que l’implémentation de Scrum n’est qu’un ensemble de rôles, d’événements et d’artefacts. Cependant, ils oublient l’état d’esprit. Par conséquent, de nombreux problèmes émergent. Mais pourquoi? Si les parties prenantes restent avec la mentalité de l’approche traditionnelle, cela ne correspond tout simplement pas à l’équipe Scrum.

Le défi consiste à implémenter Scrum correctement et à comprendre que Scrum est plus qu’un cadre. C’est un état d’esprit de collaboration et de maximisation de la valeur pour l’entreprise et les utilisateurs. Le Product Owner, dans ce cas, doit contester les demandes et devenir le visionnaire du produit, où il ou elle voit la situation dans son ensemble et comprend ce qui a du sens et ce qui ne l’est pas!

Soyez prudent avec cette mutation, si vous y tombez, vous remarquerez peut-être:

• Fournir des tâches au lieu de maximiser la valeur.
• Le focus n’existe pas.
• Tout est une priorité.
• Parties prenantes mécontentes, car aucune valeur réelle n’est délivrée.
• L’équipe ne sait pas pourquoi elle se bat.

Scrum.org classe ce rôle de malentendu du Product Owner comme Le greffier.

Il est 9 h 15, la mêlée quotidienne commence.

Propriétaire du produit: La tâche d’amélioration de la recherche se trouve déjà sur la piste des tâches depuis trois jours. Björn, pouvez-vous faire ça? Je veux le tester d’ici demain. Ah! Aussi, j’ai besoin de toi, Harold, avec autre chose, je te le dirai plus tard.

J’ai vécu des mêlées quotidiennes comme ça. La compréhension vitale est que le Product Owner n’est pas un manager; le Product Owner est un serviteur-leader.

Les propriétaires de produits se comportent comme responsables de l’équipe une fois que la mutation du gestionnaire s’est produite. Un tel comportement est une énorme erreur car le Product Owner fait plutôt partie de l’équipe. Scrum n’a pas de hiérarchie. Par conséquent, le propriétaire du produit, Scrum Master et l’équipe de développement sont tous des pairs.

Comment pouvez-vous identifier ce comportement dangereux?

• Le Product Owner commence à faire des commandes et des contrôles, à surveiller les progrès quotidiens de l’équipe et à faire pression sur eux pendant le sprint.
• Face à face entre le Product Owner et les développeurs.
• Les parties prenantes considèrent le propriétaire du produit comme le responsable de l’équipe.
• La performance individuelle est importante.
• L’équipe de développement ne peut pas se déplacer sans l’approbation du propriétaire du produit.

Le comportement du gestionnaire est un problème critique car la confiance s’évapore tandis que la collaboration diminue. Jusqu’à ce que le Product Owner comprenne que l’équipe de développement est auto-organisée, l’équipe n’atteindra pas plus que des résultats ordinaires. Ce comportement est également une autre approche de malentendu pour le rôle de Product Owner connu sous le nom de Le directeur.

En résumé, le Product Owner fait partie de l’équipe et non au-dessus d’eux.

« Nous avons besoin d’une API performante. Faisons-le avec Go! «  C’est ainsi que le combat commence.

Une fois que le Product Owner franchit la ligne dangereuse Comment, l’équipe de développement ne le recevra pas à bras ouverts. Le propriétaire du produit est responsable de Pourquoi et Quoi, tandis que l’équipe de développement est responsable de Comment. C’est une ligne mince, que l’équipe Scrum devrait respecter pour avoir un lieu de travail durable et productif.

Les propriétaires de produits doivent se concentrer sur le problème que nous voulons résoudre ou sur l’opportunité que nous voulons saisir et en discuter. D’autre part, l’équipe s’occupe de la mise en œuvre. L’équipe définit la solution pour le Quoi présenté par le Product Owner.

Comment pouvez-vous identifier cela?

• Le Product Owner arrive à la session de raffinement du backlog avec les User Stories totalement préparés, où la solution est claire, et l’équipe n’a pas de place pour explorer les options.
• L’équipe de développement est frustrée parce qu’elle ne réfléchit pas; ils exécutent seulement.
• Aucune discussion sur les épopées ou sur le problème lui-même.

Soyez prudent avec ce comportement car il peut démoraliser l’équipe et ne donner aucun résultat. Garder à l’esprit; Scrum est un cadre collaboratif signifiant que l’équipe est plus grande que la somme de son individu.

«Le talent gagne des matchs, mais le travail d’équipe et l’intelligence remportent des championnats.» – Michael Jordan

Vous pouvez éviter ce problème en signalant les problèmes à l’équipe et en explorant les alternatives ensemble. Le Product Owner doit présenter le défi et espère que l’équipe trouvera la meilleure solution.

Les excellents propriétaires de produits sont des humbles, des grands joueurs d’équipe et un savoir-faire pour favoriser la collaboration. Une équipe performante transforme l’impossible en possible.

Partie prenante: Bonjour Product Owner, je voulais écrire une demande dans le Product Backlog, mais je n’y ai pas accès. Pourriez-vous m’aider avec ça? S’il vous plaît.

Propriétaire du produit: En fait, je suis le seul à insérer de nouveaux éléments dans le Backlog produit. De quoi avez-vous besoin? Je peux comprendre avec vous, puis éventuellement l’insérer dans le Product Backlog.

C’est ainsi qu’un Product Owner diminue la collaboration et devient surchargé.

De nombreux propriétaires de produits gèrent seuls le backlog produit. Par conséquent, n’importe qui d’autre peut insérer de nouveaux éléments dans le Backlog de produit. Est-ce correct? Bien sûr que non! Le Product Owner est responsable du Product Backlog, ce qui ne veut pas dire que nous sommes le seul à pouvoir insérer de nouveaux éléments, être responsable du Product Backlog signifie que nous:

• Doit comprendre chaque élément du backlog.
• Devrait être en mesure de commander de manière à maximiser la valeur commerciale.
• Devrait affiner avec les articles jusqu’à ce qu’ils soient prêts à être développés.

Nous devons encourager les parties prenantes à insérer de nouveaux éléments dans le Product Backlog. Ensuite, le Product Owner doit comprendre chaque élément et définir leur pertinence pour l’entreprise. Ainsi, déterminez si et quand ils pourraient entrer dans un sprint.

Le Product Owner gérant seul le Product Backlog est un mythe qui Christiaan Verwijs cloué ce sujet!

Être Product Owner est un défi de tous les jours. Nous devons adopter un état d’esprit d’apprentissage continu et nous ne pouvons pas être dans la zone de confort. Chaque jour, nous devons mieux comprendre comment nous pouvons maximiser la valeur de l’entreprise de manière durable, ce qui signifie que les principes de Scrum sont respectés et appliqués!

Pour prospérer en tant que Product Owner, une personne doit:

• Avoir d’excellentes compétences en gestion de produits.
• Concentrez-vous sur la maximisation de la valeur commerciale, tout en disant non à ce qui n’y contribue pas.
• Faites partie de l’équipe Scrum au lieu de vous comporter en tant que Manager.
• Respectez les frontières entre le Product Owner et l’équipe de développement.
• Invitez les parties prenantes à collaborer pour créer un produit significatif.

Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?