Guide de mêlée | 7. Les erreurs les plus courantes du Product Owner

Dans l'article d'aujourd'hui, nous nous concentrerons sur les défis les plus courants auxquels sont confrontés les Product Owners. Nous vous indiquerons également comment vous préparer aux situations dans lesquelles ces erreurs de Product Owner se produisent le plus souvent.

Erreurs du Product Owner – table des matières :

1. Ce qui peut mal se passer entre le Product Owner et le Client
2. Défis auxquels le Product Owner est confronté concernant le reste de l'équipe Scrum
3. Sommaire

Ce qui peut mal se passer entre le Product Owner et le Client

Le Product Owner est la personne qui est personnellement responsable des défaillances de l'équipe Scrum. Du fait de cette position au-delà des activités de l'équipe, on considère que le Product Owner est l'unique cou essorable . En d'autres termes, c'est le Product Owner qui souffre le plus lorsque l'équipe Scrum tourne mal. Alors, comment gérer les situations gênantes lorsqu'elles apparaissent ou mieux encore les empêcher de se produire en premier lieu ?

Pour répondre à ce point, nous avons fourni une analyse claire et approfondie de certaines erreurs majeures des Product Owners et des Clients dans le tableau suivant, ainsi qu'une discussion détaillée de chacune.

Incapacité à prioriser

L'erreur de ne pas savoir prioriser est le fléau de nombreux Product Owners. Pourquoi la priorisation des tâches est-elle une compétence de base ? Parce que quand tout devient tout aussi important, le Product Goal disparaît. C'est l'effet escompté de l'activité de l'équipe Scrum.

Le problème commence déjà lors des premières conversations avec les clients sur l'objectif du produit. Le client souhaite généralement que toutes ses idées soient réalisées le plus rapidement et le moins cher possible. La tâche du Product Owner est d'établir une liste de priorités. Sa tâche est de créer une liste d'attentes claires et réalisables classées de la plus importante à la moins importante, en fonction des attentes non structurées des clients.

Le problème de priorisation provient le plus souvent d' une mauvaise compréhension des attentes du client. Il apparaît lorsque le Product Owner n'est pas en mesure d'extraire des informations sur les véritables Objectifs du Produit du Client. C'est la réponse à la question de savoir à quels besoins le produit est censé répondre.

Alors comment se protéger de cette erreur ? Premièrement, écoutez attentivement le client. Deuxièmement, apprenez à poser des questions sur l'objectif et sur le fonctionnement de chaque fonctionnalité du produit. Troisièmement – ​​négocier et limiter les objectifs à atteindre. Et pour cela, vous aurez besoin d'affirmation de soi.

Lorsque le Product Owner a une liste de tâches à accomplir, il existe des méthodes éprouvées pour améliorer leur progression et leur élaboration. Par exemple, l'utilisation de la matrice dite d'Eisenhower permet de hiérarchiser les tâches selon des critères d'importance et d'urgence.

Manque d'assurance du Product Owner

Le problème qui est étroitement lié à l'incapacité d'établir des priorités est le manque d'affirmation de soi. Cela se traduit par des tâches mises en file d'attente de manière inappropriée et conduit à bloquer la réalisation de l'objectif du produit en l'aggravant avec des tâches excessives. Par conséquent, la capacité de dire non au client est cruciale.

L'assertivité du Product Owner doit reposer sur trois piliers :

• connaissance des capacités de l'équipe,
• connaissance des solutions utilisées et développées par l’équipe,
• conscience de leur rôle et de leur valeur en fonction de leur place dans l'équipe Scrum.

Par conséquent, l'un des moyens les plus importants de prévenir les problèmes d'affirmation de soi est que le Product Owner travaille quotidiennement avec l'équipe Scrum. Cela l'aidera à construire des croyances réalistes sur le temps et la capacité de mettre en œuvre les idées du client.

Compétences commerciales insuffisantes

La prochaine erreur dont nous aimerions discuter est le manque de qualifications commerciales appropriées. Les points forts de ces Product Owners sont généralement des qualifications spécialisées. Leurs compétences sont plus étroitement liées au domaine de l'équipe de développement qu'à l'entreprise. Il y a donc un manque de connaissances pratiques bien établies sur la concurrence, sur les règles du marché et sur le client final du produit créé par l'équipe Scrum.

Il n'y a pas de remède simple car cela peut survenir dans des situations très spécifiques. Cependant, une bonne ligne de conduite pour un Product Owner est certainement de le reconnaître et de continuer à apprendre et à acquérir de l'expérience et des compétences commerciales.

Défis auxquels le Product Owner est confronté concernant le reste de l'équipe Scrum

La capacité à prioriser les tâches, l'assertivité du Product Owner, et ses hautes compétences métier sont les pré-requis nécessaires à la constitution d'un Product Backlog exemplaire, socle pérenne de la Scrum Team. Si le Backlog n'est pas décrit de manière cohérente et précise, les problèmes dans la relation Product Owner-Client se répercuteront sur la relation Product Owner-autre membre de l'équipe Scrum. Et à leur tour, ils affectent directement l'efficacité de l'équipe Scrum. Quels autres pièges attendent le Product Owner dans ses relations avec les autres membres de la Scrum Team ?

Pour vous faciliter la tâche, nous avons présenté les problèmes entre le Product Owner et l'équipe Scrum dans un tableau. Vous trouverez ci-dessous une discussion détaillée de chaque problème et des suggestions de solutions.

Mauvais charisme

Au quotidien, le rôle du Product Owner est de coordonner les guidelines du Client avec la manière dont elles sont mises en œuvre par l'Equipe de Développement. Cela nécessite sans aucun doute d'avoir la bonne autorité, l'écoute et le charisme.

Le problème d'une autorité insuffisante ne peut pas être résolu du jour au lendemain. Cela demande un travail de longue haleine sur les soft skills. Et aussi acquérir des connaissances sur l'étendue des tâches et les compétences des autres membres de l'équipe.

Compétences spécialisées insuffisantes

Comme nous l'avons écrit dans l'article répondant à la question Qui est un Product Owner ?, le rôle d'un Product Owner n'est pas strictement technique. Cependant, connaître les bases des compétences spécialisées des membres de l'équipe de développement peut augmenter considérablement l'autorité d'un Product Owner. Des qualifications insuffisantes dans le domaine d'expertise de l'équipe peuvent non seulement générer des problèmes avec le charisme et l'autorité du Product Owner. L'erreur de ne pas s'intéresser à la spécialité des membres de l'équipe de développement et aux bases de leurs compétences peut générer des situations cocasses, mais aussi des situations aux conséquences commerciales et interpersonnelles désastreuses .

Par conséquent, pour que l'équipe Scrum puisse fournir des produits de la meilleure qualité, le Product Owner doit avoir une compréhension approfondie du produit. Il ne devrait pas être difficile d'obtenir la bonne qualification étant donné que le Product Owner fait partie d'une équipe de professionnels. Ils peuvent fournir non seulement des explications, mais aussi des suggestions sur les endroits où acquérir des connaissances sur leur domaine.

Indépendance

Le Product Owner doit être en mesure de prendre des décisions en toute indépendance. Bien sûr, le problème clé est de connaître les conditions de l'équipe Scrum et de communiquer en permanence avec l'équipe de développement. Cependant, c'est le Product Owner qui est tenu responsable de l'efficacité de ses actions. Pour cette raison, les Product Owners doivent renforcer leur autorité et assumer la responsabilité des décisions qu'ils prennent. Le dernier appel à la direction de l'équipe, à la priorisation et à l'acceptation des tâches leur appartient.

Sommaire

Nous avons découvert les erreurs les plus courantes du Product Owner. Le rôle d'un Product Owner n'est pas simple. C'est pourquoi, en le prenant, il vaut la peine de se préparer aux problèmes que d'autres ont rencontrés sur leur chemin.

Les problèmes de relation client découlent généralement d'un manque d'assurance, d'une incapacité à établir des priorités et de compétences commerciales insuffisantes.

Les erreurs de Product Owner qui surviennent lors du travail avec le reste de l'équipe Scrum résultent du manque d'indépendance et du charisme insuffisant de la personne qui a assumé le rôle de Product Owner. Une autre raison peut concerner le manque de compétences spécialisées et la réticence ou le manque de temps pour approfondir les connaissances.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Linkedin et Twitter.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit