Product Owner et Proxy Product Owner

Article d’origine : http://yannick.ameur.free.fr/dotclear/index.php?post/agile/Product_Owner_Proxy_PO

De plus en plus d’organisation Agile sont confrontées au problème de la scalabilité des processus Agiles.

Safe, LeSS, Scrum Of Scrum, ScrumBan, Kanban et multi-flux

Je vous propose de redéfinir l’un des principes : la mis en place d’un Proxy Product Owner ou d’un Product Manager Owner (PMO).

Principe du Proxy Product Owner

Petit rappel : Le rôle du Product Owner

Définissons le mot Proxy

Dans le cadre plus précis des réseaux informatiques, un proxy est alors un programme servant d’intermédiaire pour accéder à un autre réseau

Pourquoi un Proxy PO

Le cadre de travail du Proxy PO est rattaché à la scalabilité d’un Produit nécessitant de le découper en plusieurs sous produits. Il faut de l’énergie et du courage pour être un facilitateur de PO et faire circuler l’information.

Rôle du Proxy PO (PPO ou PMO)

  • Etre au service des Products Owner
  • Défendre la roadmap, être le représentant des PO
  • Aider à trouver des solutions et à les mettre en place.
  • Il est le garant des processus mis en place au sein de l’équipe PO.
  • Canalisateur de l’information et de la transparence qui en découle.

Je rejoins le point de Bertrand présenté au ScrumDay 2011 ici.

L’objectif du Proxy PO :

  • Aider à la décision entre plusieurs PO ou trouver la ou les bonnes personnes pour prendre la décision.
  • Le Proxy PO Priorise la RoadMap mais il ne peut pas dire comment réaliser les sous produits,
  • Il est facilitateur et doit connaitre un maximum de personne pour orienter et aiguiller les PO : Aiguilleur du ciel.
  • Le PPO est sur le terrain avec les PO et donc il sait qui fait quoi dans la team de PO.
  • Comme pour une team de développeur avec son Scrum Master, chaque PO de son équipe va présenter les éléments de son produit aux CODIR et démos externes.
  • Facilitateur des autres PO (au préalable les autres PO lui auront donnés mandat de PPO), le Proxy Product Owner peut même être élu dans une équipe de PO par élection sans candidat.
  • Le PPO n’est pas obligatoirement hiérarchiquement supérieur au autres PO.
  • Avec le temps le proxy PO devrait disparaître, pour redevenir PO à plein temps, il devrait garder et gérer le sous produit le plus petit.
  • Le Proxy PO doit responsabiliser son équipe, l’équipe doit rechercher ses coéquipiers.

Contre exemples

  • Le PPO n’est pas un PO bouche trous (amicalement)
  • Certain MANAGER s’improvisent Proxy PO et confondent Proxy et Firewall…
  • Certain manager pratique le « Juste in time », traduisez par : Je te donne l’information au dernier moment (voir pas du tout).
  • Le Proxy PO n’est pas un PO secrétaire entre les équipes de dev et les responsables de marchés et/ou le métier (ex AMOA).

Pour finir la définition de votre Proxy PO est la vôtre dans le cadre de votre entreprise avec les contraintes qui sont les vôtres.


C’est ma vision biensur.

Chaîne de valeur : comment la définir ?

La chaîne de valeur dans votre Produit ou dans votre entreprise est spécifique, donc je vous propose une solution à adapter avec si possible un coach Agile.

La recherche de chaînes de valeurs est pour moi la résultante d’un système complexe dans certain grand groupe, ou dans des contextes de Produits imbriqués nécessitant une gestion scallée des équipes.
Quand les membres d’un système ne comprennent plus ce qu’ils apportent comme valeur dans le système : quêtes de sens, responsabilités, valeurs.

Voilà donc une façon d’aborder la définition d’une chaîne de valeur(s).

Merci à Béatrice Kreng d’avoir scribé la Chaîne de Valeur

Définition de la chaîne de valeur : la chaîne de valeur est l’ensemble des produits et des personnes qui participent à la réalisation de votre Epic.

L’Epic est une fonctionnalité Macro à réaliser, elle peut se découper en plusieurs Users Stories.

Release glissante : c’est un ensemble d’Epic qui représentent 3 mois de production estimée des Produits de votre système.

Chaque Epic doit aller en production le plus rapidement possible et permettre à une nouvelle Epic de rentrer dans la release, d’où la notion de Release Glissante.

Lire la suite

Agile Framing

Le Framing Agile donne du sens à nos initiatives de BootCamp et des starterKit Agile qu’AgileTribu a lancé ces dernières années.

Le Framing Agile est née de différente aventures initialisées avec Nathaniel Richand, poursuivi avec Judicael Paquet lors de nos missions communes.

Judicael à réussi à formaliser les réflexions sur : comment industrialiser le bootstrapping de Produit Agile avec Agile Framing sur son blog MyAgilePartner :

framing-agile-2

Bravo pour cette synthèse que nous partageons et qui évolue avec les différents coach, clients, Produits, tests réalisés autour des différents éléments du Framing.

Je conseils de lire les articles liées ici :

https://blog.myagilepartner.fr/?s=framing

A suivre pour 2019.