Scrum: que faire si le Product Owner a des tâches?

Je viens de commencer à travailler avec une équipe qui a repris certains aspects de Scrum (timeboxing de deux semaines) mais pas d'autres (l'équipe n'est actuellement pas d'accord avec toutes les estimations ou le nombre de points dans un sprint, mais je vais changer cela bientôt.) Le propriétaire du produit est également une ressource technique (scientifique) avec une certaine expérience en développement.

Est-il approprié de mélanger les tâches du propriétaire du produit (qui impliquent principalement la recherche) avec les tâches de l'équipe (dont certaines sont de la recherche et du développement).

Les experts de Scrum sont très fermes en déclarant que le Product Owner et le Scrum Master doivent être deux personnes différentes. Cependant, il n'existe aucune règle de ce type excluant non plus de l'équipe de développement. Remarque dans le Scrum Guide :

Taille de l'équipe de développement

La taille optimale de l'équipe de développement est suffisamment petite pour rester agile et suffisamment grande pour effectuer un travail important. Moins de trois membres de l'équipe de développement diminuent l'interaction et entraînent des gains de productivité moins importants. Les petites équipes de développement peuvent rencontrer des contraintes de compétences pendant le sprint, ce qui empêche l'équipe de développement de fournir un incrément potentiellement libérable. Le fait d'avoir plus de neuf membres nécessite trop de coordination. Les grandes équipes de développement génèrent trop de complexité pour un processus empirique à gérer. Les rôles Product Owner et Scrum Master ne sont pas inclus dans ce décompte, sauf s'ils exécutent également le travail du Sprint Backlog.

Le corollaire de cette dernière ligne serait que, si le Product Owner exécute le travail du Sprint Backlog, il ou elle est compté comme membre de l'équipe de développement.

Cela dit, faites tout ce qui fonctionne pour bien faire votre travail.

Le propriétaire du produit est responsable de maximiser la valeur du produit et le retour sur investissement. Cela peut sembler simple, mais c'est généralement un rôle à temps plein et très exigeant - sans doute le plus difficile de Scrum. Cela implique beaucoup de travail stratégique de haut niveau ainsi que des tâches de niveau inférieur, de l'analyse des opportunités de marché et de la consultation des parties prenantes et des utilisateurs du produit pour prendre les bonnes décisions, à garder la feuille de route du produit et le backlog toujours polis, à assister à la planification et revoir les activités, se rendre disponible pour que l'équipe réponde à leurs questions, etc.

Si l'OP est en charge d'autres tâches en plus de cela, je ne les considérerais que comme marginales dans la plupart des cas. Donc ma réponse serait oui, créez des tâches pour le PO si vous en avez vraiment besoin et si elles contribuent directement à la production de l'incrément logiciel du sprint, mais je ne vois pas cela se produire souvent dans votre projet Scrum moyen.

Scrum est avant tout une question de communication et de travail pertinent et opportun. Tout est possible pour atteindre cet objectif si c'est ce qui permet à votre équipe d'être la plus productive.

Il est cependant difficile de bien faire. Je suis dans cette position maintenant et j'ai du mal à consacrer une quantité appropriée de temps en tant que propriétaire du produit tout en laissant du temps pour le développement. Cependant, l'arrangement fonctionne bien pour cette équipe spécifique à ce stade. Nous reviendrons sur la décision pour moi de retirer le double devoir lorsque nos performances chuteront, mais d'ici là, nous continuerons à travailler de cette façon.

Alors essayez-le. Faites des rétrospectives afin d'améliorer continuellement votre processus. Ne laissez pas vous en tenir à une méthodologie gênant la productivité de votre équipe.