Dans Scrum, pourquoi les rôles Product Owner et ScrumMaster ne devraient-ils pas être combinés?

19

Dans les projets plus traditionnels sur lesquels j'ai travaillé, le chef de projet (et, sur les grands projets, il peut y avoir des chefs de projet associés / adjoints / assistants si une personne n'est pas disponible) est la personne chargée de communiquer avec le client, de recevoir le projet mises à jour de l'état et de la santé, détermination de la planification et de la budgétisation, gestion du processus, vérification que l'équipe a ce dont elle a besoin pour effectuer les tâches, etc.

Dans Scrum, cependant, ces responsabilités sont partagées entre le Product Owner et le ScrumMaster. Le Product Owner est la voix du client. Ils interagissent directement avec le client, créent des histoires d'utilisateurs, organisent et hiérarchisent le backlog de produit et d'autres problèmes rencontrés par les utilisateurs / clients. Le ScrumMaster gère le processus, supervise les réunions (y compris l'estimation et la planification), supprime les obstacles et surveille la santé globale du projet, en effectuant les ajustements nécessaires.

J'ai lu dans plusieurs sources, y compris Wikipedia , que le rôle de ScrumMaster et du Product Owner devrait être tenu par deux personnes différentes. J'ai non seulement lu, mais travaillé sur des projets réussis de style "traditionnel" où les activités des deux étaient gérées par une seule personne. En fait, il est plus logique qu'une à trois personnes soient responsables de la gestion des projets (y compris les ressources humaines / dotation en personnel) et des tâches au niveau du processus, car elles vont souvent de pair. Les modifications de processus ont un impact sur la planification, la budgétisation, la qualité et d'autres objectifs au niveau du projet, et les modifications de projet ont un impact sur le processus.

Pourquoi Scrum appelle-t-il à isoler ces activités en deux rôles? Quels avantages cela offre-t-il réellement? Quelqu'un a-t-il réussi un projet Scrum où le Product Owner et ScrumMaster étaient la même personne?

— Thomas Owens
source

De plus, je jure que cette question a déjà été posée, mais je ne la trouve pas et je ne l'ai pas mise en favoris. Beaucoup de questions sur les définitions de rôle ici, mais je ne vois pas celle PO / SM que je suis sûr de lire.

— Thomas Owens

Pensez-vous à cette question ?

— Adam Lear

@Anna Cela semble familier, mais il ne semble pas en fait être un doublon. Je suppose que cette question spécifique n'a peut-être pas été posée auparavant.

— Thomas Owens

Et celui-ci ? :)

— Adam Lear

1

Je recommande de lire Réussir avec Agile où cela est discuté plus en détail.

— Ladislav Mrnka

17

Ils peuvent (et sont souvent) combinés et réalisés par une seule personne (il n'y a pas de règle contre cela (sa mêlée après tout)).

MAIS vous avez besoin d'équilibrer soigneusement la responsabilité de la différence car les deux rôles ont des agendas concurrents (et il faut une personne spéciale pour pouvoir faire les deux simultanément). J'en ai vu beaucoup essayer mais peu réussissent sur une longue période (c'est une position stressante).

Pour être le SM, vous avez besoin de plus de connaissances techniques que le PO (car vous aiderez à organiser l'équipe de développement). Il faut une connaissance détaillée du produit pour pouvoir extraire des éléments du backlog de produit dans le backlog de printemps (parfois, vous ne pouvez tout simplement pas tirer les premiers éléments car cela peut être contre-productif).
Le PO nécessite une meilleure compréhension de l'extrémité utilisateur de l'équation que le SM. Cela n'a pas besoin d'être aussi technique mais nécessite une connaissance de la façon dont le produit va être utilisé dans le monde réel et de la direction que le client souhaite prendre.

Si vous pouvez trouver une personne qui peut jouer les deux rôles, je ne vois aucune raison de l'empêcher.

Des problèmes peuvent survenir lorsque le bon de commande est tiré par le client dans une direction, ce qui cause des conflits importants aux développeurs (car ils doivent d'abord construire une autre infrastructure). Le travail de SM n'est pas de suivre les caprices du client mais de protéger les développeurs de leurs caprices. Il est difficile de retirer cela objectivement.

— Martin York
source

1

Oui, selon moi, c'est le conflit d'intérêts qui cause le problème. Le propriétaire du produit veut autant que possible, le maître de mêlée doit gérer les attentes du propriétaire du produit.

1

Votre description de SM est fausse. Vous décrivez quelque chose comme chef d'équipe, pas SM.

— Ladislav Mrnka

1

Je suis fortement en désaccord avec cela. PO et SM sont deux emplois vraiment différents. borisgloger.com/2009/12/07/…

@Pierre Ce lien a été publié dans une réponse. Comme je l'ai dit en réponse à cette réponse, tous sauf 3 ont des contre-arguments que je peux trouver ici et maintenant, et 3 est tellement général qu'il s'applique à tous les postes.

— Thomas Owens

3

Assurez-vous également de consulter cet article qui en parle spécifiquement: blog.mountaingoatsoftware.com/… . Si le mélange des rôles vous convient, je vous promets que je vous enverrai une boîte de chocolats belges.

4

Je ne suis pas un expert, mais je pense que le Scrum Master devrait être le défenseur / facilitateur de l'équipe. La voix du client doit avoir à cœur les intérêts du client. Le Scrum Master devrait aider à aider l'équipe à obtenir ce dont elle a besoin pour réussir son sprint.

— Amy Anuszewski
source

1

Aussi, gardez à l'esprit le plus souvent, vous ne travaillez pas sur 1 client à la fois. Les propriétaires de produits peuvent gérer plusieurs clients et peuvent se concentrer sur cette partie de l'entreprise, et ScrumMasters peut se concentrer sur le développement de projets.

Comme beaucoup l'ont dit, les deux rôles ont des intérêts distincts, mais un objectif commun et des compétences différentes pour l'acquérir.

— AJC
source

C'est peut-être vrai. Chaque fois que j'ai travaillé, le personnel du «niveau projet» (l'équivalent des PO et des SM) était consacré à un seul projet, c'est donc le seul cadre de référence que j'ai. L'équipe de développement peut être affectée à plusieurs projets, mais généralement, même un développeur est affecté à un projet à plein temps et prend en charge des rôles sur un ou deux autres.

— Thomas Owens

0

Si la même personne représente l'équipe de développement et les utilisateurs / clients, le seul recours que vous avez en cas de litige est de consulter le contrat. Bien que cela puisse finir par arriver à cela, il vaut mieux qu'un représentant des deux côtés avec un pouvoir égal puisse trouver un accord.

— JeffO
source

Si le bon de commande ne provient pas de l'organisation du client (ce qui, selon moi, est souvent le cas), vous devrez toujours examiner le contrat en cas de différend entre l'organisation en développement (y compris le bon de commande) et le client.

— Thomas Owens

1

C'est vrai, mais avoir un défenseur des clients parmi le personnel peut être en mesure de gérer un désaccord avant qu'il ne revienne au client. S'ils sont tous les deux en désaccord avec le client, c'est un autre problème.

— JeffO

0

Les personnes dans les rôles Product Owner et Scrum Master peuvent avoir des désirs, des objectifs, des exigences et des contraintes contradictoires, plus que 2 programmeurs aléatoires. Les êtres humains peuvent ou non être en mesure de valoriser également des objectifs contradictoires et sont plus susceptibles de faire des erreurs de jugement lorsqu'ils sont confrontés à des objectifs contradictoires. Deux personnes ayant des objectifs ou des biais légèrement différents peuvent être moins susceptibles de commettre ensemble les mêmes erreurs ou le même degré d'erreurs de jugement.

Deux personnes peuvent également allouer plus d'heures-homme au total pour se concentrer sur chaque aspect différent du problème / projet (par exemple, les objectifs des 2 rôles différents).

— hotpaw2
source