POc’est l’un des 3 rôles (avec le ScrumMaster et les Développeurs) proposé par Scrum; c’est aussi un vrai point de vigilance pour moi en tant que Coach Agile.
Le Product Owner est responsable de maximiser la valeur du produit. Il est le représentant du client et des utilisateurs et donc à ce titre l’interlocuteur privilégié de l’Equipe.
Le rôle est essentiel; son importance est primordiale:
être Product Owner sur produit, c’est déjà pas mal de responsabilités (LA DECISION), c’est aussi:
être Product Owner sur produit, c’est déjà pas mal de responsabilités (LA DECISION), c’est aussi:
- s’impliquer
- savoir communiquer
- savoir collaborer
- se rendre un minimum disponible
- disposer d’un certain savoir-faire…
Autant d’éléments, autant de risques que les choses dérapent…
Quant à l’activité du product Owner, même si son profil peut varier, elle est plutôt bien cadrée :
- Partager la Vision
- Gérer de manière efficace le Backlog de produit (le définir, l’alimenter, l’ordonnancer, ajouter, supprimer des items…)
- Fixer les priorités
- Décrire les fonctionnalités
- Ajuster les fonctionnalités et les priorités à chaque sprint
- Accepter ou rejeter les résultats (sur la base des critères d’acceptation)
Autant d’activités (et des registres différents), autant de risques que les choses ne dérapent… Backlog incomplet, exigences déconnectées de la réalité, de la valeur, Vision non partagée voire obscure, Absence de décision, Imprécision des critères d’acceptation, inéfficacité des échanges avec l’équipe, des ateliers de travail, manque de disponibilité et de présence à des RDV clés.
Seul, le Product Owner, peut il y arriver ? LA REPONSE EST NON!
mais il peut compter sur l’équipe me dire-vous?
OK mais pas suffisant…
Le Product Owner doit d’abord être accompagné.
Ensuite, même si le Product Owner doit parler d’une seul voix (vis à vis de l’équipe notamment, c’est un fondamental), constituer autour de lui une « Team Product Owner » est trés souvent une pratique gagnante.
De ce point de vue, l’Ergonome ou encore l’Analyste fonctionnel sont des partenaires privilègiés qui vont appuyer le travail d’estimation et de priorisation du Product Owner. Ils sont aussi ceux qui peuvent l’aider à clarifier et communiquer sa Vision, à recueillir et définir les besoins au travers de multiples ateliers de travail et d’une approche Personas. Associer trés vite Product Owner et testeurs est aussi un facteur clé de réussite
Mon Challenge, essentiellement un travail de coaching de Product Owner:
- Faire adhérer aux valeurs Agiles
- Former à la pratique du SCRUM: les règles à respecter, le déroulé, l’attitude et les points de vigilance
- Définir précisément les rôles et responsabilités de chacun
- Diagnostiquer et dimensionner le rôle Product Owner sur le projet
- Construire le Team Product Owner si nécessaire
- Coacher le Product Owner sur 1 ou 2 sprints, avec un fort accompagnement en Sprint O
Mes autres Alertes:
Bonjour,
Pour développer sur cette notion de « team Product Owner » avez vous identifié d’autres rôles/postes que celui d’ergonome ou de coach agile pouvant collaborer de manière temporaire ou permanente sur ces tâches clés ?
D’autres blogs Agile mentionnent notamment le tandem produit « Product manager / Product owner » où le premier est en charge de la vision long terme et des relations business (impliquant une faible disponibilité, notamment aux Daily Scrum Meetings) et le second beaucoup plus proche de l’équipe au quotidien. Qu’en pensez vous ?
Bonjour,
Dans une entreprise d’ingénierie du bâtiment, une direction immobilière ou plus largement dans l’immobilier d’entreprise, il y a beaucoup de similitudes avec le monde l’informatique.
Avec les méthodes Agiles et Scrum en particulier, la première est que le représentant du client (qui peut être aussi l’utilisateur final) est le Product Owner (PO ou Maître d’Ouvrage, MO), le second qu’un projet répond à la définition du PMI, et en dernier point que le livrable produit est résolument orienté client.
Les 6 six points décrits dans l’activité du PO, avec au préalable l’accompagnement dans l’expression du besoin, sa « programmation », sont le quotidien d’un PO, tout en étant aussi le représentant du client et des futurs utilisateurs. Toutefois dans l’habit du super PO – et quelque soit la méthodologie projet utilisée – c’est une partie prenante très forte qui se doit d’être épaulée, soutenue par le client, le sponsor, l’équipe projet (la maîtrise d’oeuvre, Moe). Il est évident que seul, le PO ne peut pas arriver à grand chose et je rejoins l’article. De plus qu’il est à mon avis primordial que le PO doit avoir du leadership, du charisme, de l’empathie, et une maîtrise du binôme comportement/communication.
Donc pour revenir à l’article, s’il est fait état de la nécessité d’un Ergonome, pourquoi pas, mais je pense que d’une manière réaliste et objective, nous parlons ici d’une seule et même personne!
Sans parler que pour reprendre le commentaire précédent de NC, le PO (ou le MO) se doit être très très disponible! Et pour appréhender la vision à long terme, il est à mon avis essentiel de se doter d’un esprit Lean et Business Analysis TOUT EN conciliant à court terme la vision courte du livrable en se reposant sur les Scrum Master et l’équipe. La MO doit gérer un « portefeuille de visions » : long terme, court terme et activités.
Je pense ici qu’il faut donc et surtout recentrer les rôles et responsabilités de chacune et chacun. Ajouter d’autres parties prenantes ne seraient pas utiles au quotidien, par contre que le N+1 puisse gérer ses ressources en leur allouant du temps suffisant et nécessaire pour être disponible et orienté client me semblerait plus pertinent, non ?