En Scrum pur, ce rôle de proxy Product Owner n’est pas défini.
Pour autant de mon organisation, il s’est révélé être un facteur clé de succès.
Dans notre organisation, le proxy PO travaille en binôme total avec le Product Owner.
Rattaché au service IT, il va avoir un regard plus technique, une meilleure maîtrise des méthodes et un rôle d’interface avec la dev team.
Voici plusieurs arguments qui motivent ce choix :
Des Product Owner métier rares et peu formés
Effectivement, les équipes métiers ont souvent beaucoup de besoins, mais quand ceux-ci se transforment en projet, il n’y a plus personne pour prendre le lead.
Quand bien même un “référent métier” serait nommé, il n’a souvent pas l’étoffe d’un vrai Product Owner :
- Manque de formation
- Pas assez de prise de recul sur le besoin réel
- Peu de temps alloué à sa tâche
- Sous-estimation totale de l’investissement à produire
Dans ce cas-là, le Proxy PO va aider au décollage du projet, participer à la montée en compétences du PO (avec le scrum master bien sûr!), tenir les rênes du backlog. Bref, service de carburant pour faire décoller la fusée dans les règles!
Uniformiser les méthodes
Un cadre complètement différent pour chaque projet, c’est ce que l’on veut EVITER!
Si les potentiels PO sont éclatés dans les services métier, les Proxy PO eux sont rattachés à l’IT. Et c’est une force :
Formés et accompagnés par le Scrum Master, les différents proxy PO vont ainsi pouvoir animer le projet avec le même cadre enseigné.
Cela va contribuer à assurer un bon partage d’informations entre les différentes équipes projet et également avec le responsable de service (DSI…)!
La proximité va également agir comme un think tank, permettant de s’améliorer en confrontant les situations vécues sur les différents projets.
Proximité avec la dev team
Les proxy PO, souvent rattachés au service IT ont ainsi une place privilégiée car proches des équipes de développement.
Le meilleur canal de communication étant l’échange en face à face, on voit facilement l’intérêt d’avoir une proximité physique avec le développement.
Des COPIL mieux préparés
Le comité de pilotage est un moment essentiel pour se synchroniser avec les décideurs. Il ne faut donc pas lésiner sur la préparation et le format de ces moments décisifs.
Le fait de préparer à deux (PO / Proxy PO) ces échéances permet d’avoir la prise de recul nécessaire pour penser à présenter les bons éléments, de la bonne façon.
Complémentarité technique / fonctionnel
C’est l’argument que l’on retrouve souvent en tête de liste.
Effectivement, le proxy PO, via son expérience sur de multiples projets, périmètres, va avoir plus de recul sur le projet, sera moins juge et parti et va apporter sa vision plus technique.
Ainsi, il va pouvoir orienter les stories pour qu’elles s’accordent avec les exigences de l’architecture et de la dev team!
Il va également aider à prioriser le backlog avec plus d’objectivité et de rationalisme.
Ce travail se faisant de pair avec le PO.
