Le PO proxy n'existe pas

J'ai participé vendredi à une réunion/débat organisée par l'association Agile Toulouse sur le rôle de PO, axée sur la notion de PO Proxy[1].

Note

[1] Ce billet n'est pas un compte-rendu de la réunion, j'y présente mon point de vue.

Nathalie, dont c'était la fête, nous a fait une présentation de pratiques pour lesquelles le PO pouvait être assisté, par exemple pour l'animation d'ateliers de type Innovation Games.

De mon côté, j'avais préparé une carte heuristique centrée sur le rôle de Product Owner :

Product_Owner.png

C'est un résumé, tiré du chapitre 3 de mon livre, qui présente :

  • ses responsabilités,
  • sa participation aux activités faites en collaboration par l'équipe,
  • les compétences souhaitées et
  • des conseils pour progresser.

PO est un rôle. Il est, en principe, tenu par une seule personne qui aura ces responsabilités et participera à ces activités. Il existe des situations où une seule personne ne sera pas en mesure d'y parvenir. Les 2 principales raisons sont le manque de compétence et le manque de temps. A noter que ce sont des situations temporaires, on peut acquérir des compétences et s'arranger pour avoir du temps.

On peut donc envisager qu'il y ait plusieurs personnes qui jouent le rôle de PO dans une équipe[1].

Voyons quelques cas :

  • une personne novice se fait assister par un coach, qui l'aide à tenir ses responsabilités et à animer des ateliers et réunions,
  • deux personnes se partagent des domaines fonctionnels,
  • il y a une personne pour le remplacement au cas où (backup).

Pour que ça fonctionne bien, il convient d'être clair sur deux responsabilités clés : prioriser les stories et déclarer les stories finies ; il faut aussi assurer la participation aux réunions d'équipe.

Quand une seule personne joue le rôle de PO, il peut déléguer certaines responsabilités à des membres de l'équipe, par exemple sur les critères et tests d'acceptation.

Par contre si une personne délègue la plupart des responsabilités, en particulier la priorisation et la finition des stories, et ne participe pas à la majorité des réunions, on ne peut plus considérer qu'elle soit PO. C'est celui qui reçoit la délégation et participe au travail collaboratif qui est le PO. C'est pourquoi le rôle de substitution présenté sous le nom de PO proxy n'existe pas.

Note

[1] Dans iceScrum, c'est une évolution qui s'est faite il y a quelque temps, alors que dans les premières versions une seule personne pouvait tenir le rôle.

Commentaires

1. Le lundi 30 juillet 2012, 11:23 par Geoffrey

Bonjour,
Je suis d'accord avec le fait qu'être PO c'est jouer son vrai rôle dans l'organisation Scrum et non pas porter un titre et tout déléguer.

Néanmoins, pour ce que j'en ai compris, le PO proxy me semblait plus être le lien de communication entre une équipe PO et la Team dans le cadre d'une organisation dispersée (offshore and co ...). Dans ce cas, il est toujours mieux de ne parler que d'une seule voix et que ce porte-parole soit clairement défini. Le PO proxy serait cette voix selon moi.
Pas d'accord. La distance n'empêche pas la communication directe entre un membre de l'équipe et le PO. Le rôle de se proxy n'est alors pas le même que celui du PO. Il se contente de répondre aux sollicitations de la Team, de communiquer autour des stories et du produit etc ..., pas de prioriser, ni de finir les stories.
Il me semble alors que n'importe quel membre de l'équipe PO pourrait tenir ce rôle à partir du moment qu'il possède la compréhension suffisante du produit et va dans le sens de son équipe.

2. Le lundi 30 juillet 2012, 14:08 par Geoffrey

Je suis absolument d'accord avec vous s'il n y a qu'un seul PO, mais dans le cas d'une équipe de POs ?

Il n'y a qu'une équipe Scrum et le PO est dedans

Le rôle de PO est unique dans le Scrum mais le PO peut être une équipe aussi composée par exemple du PO et de plusieurs Business Analyst.

Ca fait une personne qui joue le rôle de PO. Le rôle de Business Analyst n'existe pas avec Scrum, ce sont des membres de l'équipe.

Que la delivery team parle avec tous les membres de l'équipe PO ( BA, PO etc ) n'est évidemment pas exclu mais risque de compliquer la compréhension globale si par malheur les voix des membres de l'équipe de PO ne s'accordent pas.

Il n'y a qu'une équipe Scrum, pourquoi parler de delivery team et de PO team ?

Il me semble que dans ce cas là définir un porte-parole (le fameux PO proxy) est assez indiqué, non ?

Ce cas n'existe pas, pas plus que le PO proxy.
3. Le mercredi 01 août 2012, 11:19 par addinquy

Bonjour Claude,
J'aime bien ton billet, d'autant que je ne suis vraiment pas à l'aise avec cette notion de "PO proxy". Toutefois je pense que cette notion correspond plus à une situation où le "vrai PO" ne participe pas à tous les aspects opérationnels du projet mais où il ne délègue pas non plus les responsabilités !
En gros, dans ce genre de situation, le PO proxy est une sorte d'écuyer: il fit le boulot opérationnel: écriture des stories, des acceptance tests, de la priorisation sans être investi de l'autorité. Ils doivent alors faire confirmer / valider cela par le Chevalier, pardon le PO. Ils répondent aussi aux questions de l'équipe quand ils peuvent (plutôt une minorité des cas) sinon se retournent vers le PO.
Je vois deux origines à ce type de situation:
- Le "vrai PO" n'a pas le temps. Cela me laisse dubitatif, ayant bossé avec des traders qui sont les gens les plus occupés de la galaxie. Pour un projet capable de leur rapporter de l'argent, ils trouvaient toujours du temps à nous consacrer. Question : si le PO n'a pas le temps, le projet est-il vraiment important. N'est-ce pas un signe qu'il faut arrêter ou ne pas faire le projet ?
- Le "vrai PO" n'a pas le savoir-faire ou le goût pour les projets informatique. Bref, il a la connaissance, la vision et tout et tout, mais être impliqué dans un projet informatique le gonfle. Hélas je pense que cette situation est assez commune. J'ai l'impression que trouver un PO avec les qualités que l'on en attend reste souvent un challenge ...

4. Le mercredi 01 août 2012, 16:08 par Eric Siber

D'accord avec l'analyse de Christophe. Il ne manque plus que le proxy PO soit le Scrum Master pour que ca ne sente pas du tout bon (pour le Scrum Master tout comme le projet).

5. Le lundi 06 août 2012, 12:14 par Geoffrey

Ok, je pense que j'ai mal compris ce que vous définissiez comme "PO proxy" et que je l'ai confondu avec la même expression utilisée par Jeff McKenna lorsqu'il parle de communication entre des équipes géographiquement dispersées.

En substance, je suis d'accord avec vous : si le PO ne tient pas son rôle il ne sert à rien d'utiliser un scribe.

Tout est une question d'attitude et pour tous les membres d'un projet Agile. Si on ne "joue" pas le jeu on est peut-être simplement pas le bonne personne