Bonjour,
Dans le cadre de ma réorientation actuelle, je souhaiterais devenir PO (avec un bagage de project manager plutôt waterfall).
De nombreuses offres sont publiées mais certaines demandent que le PO joue également le rôle de scrum master.
Ceci est-il envisageable ? N’y-a-t-il pas de conflit interne entre les deux positions ?
D’avance, un grand merci pour tous vos commentaires 
À mes yeux, de toutes les combinaisons possibles, c’est potentiellement la plus nocive. Pouvoir mettre en avant le côté productiviste du cadre Scrum sans donner les cartes aux devs qui peuvent ne pas connaître les tenants et aboutissants de cette façon de travailler, c’est transformer tout le processus en mega feature factory…
Bonjour Samuel, merci pour votre réaction. Vous voulez dire qu’en tant que dans ce cas, le PO/SC serait un peu ‹ juge et partie › car il induirait un cadre en fonction de ses priorités en tant que PO ? C’est bien ça ?
C’est ça, mais ça va un peu plus loin.ca peut également être néfaste dans le sens où l’équipe de dev sera exposé, comme souvent, à quelque chose qui reflète très peu un processus tourné vers les changements de comportement et plus tourné vers le changement de forme du système. C’est comme ça qu’on crée des générations de développeur.euses dégoûté.es du mouvement pour l’agilité simplement parce qu’exposées à des process toxiques.
Quel est l’objectif ? SI supposé être une situation permanente c’est clairement une mauvaise idée. Si l’objectif est d’accompagner une équipe qui n’a jamais travaillé en Scrum alors que le PO a une expérience dans le domaine, mieux vaut alors responsabiliser un des membres de l’équipe de développement sur un rôle SM, quitte à ce que le PO, non pas en tant que PO mais plus en tant que personne ayant une expérience de l’approche Scrum, l’accompagne. C’est un peu l’inverse de ce qui se fait d’habitude mais pourquoi pas si le PO a le bon mindset et l’expérience, et qu’il n’y a pas d’alternative plus satisfaisante envisageable.
Un scrum master est sensé aider (servant leader) 3 pans de l’organisation :
Samuel a raison par rapport à l’impact sur l’équipe de développement : c’est comme donner les clés du camion au PO sans aucun garde-fou car les devs se diront qu’ils n’ont aucun moyen de négocier les objectifs, tâches, puisque le PO a « forcément » raison
Et puis au niveau organisation, quelle sera la légitimité du PO avec les parties prenantes si il doit aller chercher la valeur mais que dans un coin de sa tête il doit se freiner ou négocier avec lui-même constamment ? Et comment trouverait-il le temps de gérer d’éventuels conflits ?
Enfin tout ça pour dire que c’est un peu utopique, ça pourrait fonctionner dans une organisation qui est déjà bien agile, qui n’aurait pas forcément besoin d’un scrum master et dans ce cas ce serait plus un PO avec une très forte culture agile qui serait demandé, mais pas deux rôles à la fois
Merci pour la précision et pour le partage Samuel ! Bonne journée
Merci pour le commentaire et les pistes de solution.
Comme il s’agissait d’un poste pour lequel j’hésitais, je pense que je vais simplement ne pas me porter candidate
Merci Nicolas, vous confirmez ce que je pensais et ce que Samuel décrivait également !
Merci pour l’attention portée à la question !
Petite histoire :
Les rôles de PO et SM ont été inspiré du « Chief Engineer » à Toyota, chargé d’avoir une petite équipe produit et a des compétences en technique et process fortes.
C’est généralement un rôle très senior.
Et c’est pour ça que PO et SM ont été séparés en deux : il est quasiment impossible d’avoir des Chief Engineer partout… !
Donc à part si en tant que PO / SM tu as 20 ans d’xp et créés déjà des produits innovants, vaut vraiment mieux les séparer !!
Bonsoir à tous-tes !
Ce sujet m’intéresse, alors je le déterre
Mais je n’ai pas compris grand chose de vos explications les uns et les autres, désolée ! 
Un argument que j’ai compris, c’est celui que @Julie a évoqué du « juge et partie ».
Concrètement, les dév. n’auront personne vers qui se tourner si les demandes de la P.O. leur semblent abusives, par exemple.
Un autre, c’est celui du temps (que le PO/SM n’aura pas pour résoudre d’éventuels conflits, par exemple). OK.
Mais dans le cas d’un petit projet avec une petite équipe (mettons 2 ou 3 dév), est-ce que ce serait vraiment problématique ?
@Samuel_Abiassi, si tu as le temps et le courage, peux-tu me traduire ce passage (peut-être avec des exemples concrets?)
ça va un peu plus loin.ca peut également être néfaste dans le sens où l’équipe de dev sera exposé, comme souvent, à quelque chose qui reflète très peu un processus tourné vers les changements de comportement et plus tourné vers le changement de forme du système.
et @nicobiot, même prière qu’à Samuel : si tu as le temps et le courage, pourraist-tu expliquer ce passage, stp ?
Et puis au niveau organisation, quelle sera la légitimité du PO avec les parties prenantes si il doit aller chercher la valeur mais que dans un coin de sa tête il doit se freiner ou négocier avec lui-même constamment ?
Sur quoi la PO/SM serait-il amené à négocier avec lui-même ?
Merci d’avance à tous-tes pour vos éclaircissements ! 
PO et SM apportent un équilibre : l’un orienté recherche de la valeur business, l’autre efficacité de la réalisation de la valeur business
Si tu portes les 2 rôles, à moins d’être très expérimenté, tu vas minimiser le valeur pour réussir à délivrer et te concentrer sur le process ou au contraire privilégier tes clients et ne pas assumer ton rôle de servant leader coach pour l’équipe et mettre la pression…
C’est pour ça que j’emploie le mot négociation avec soi même : en tant que PO/SM je sers qui en priorité ?
Pour comprendre ma remarque, il faut comprendre la différence entre output et outcome. (attention, je vais caricaturer un peu)
Une output, c’est quelque chose qu’on livre, quoi que ça puisse être. C’est un élément qui est aujourd’hui l’unité de mesure standard pour les équipes souhaitant fliquer ce que font les devs et qui « savent ce qu’il faut livrer parce qu’on est trop intelligent.es #bigbrain ».
Une outcome, c’est un « but à atteindre ». Généralement, ça se matérialise par des objectifs comme une amélioration du temps qu’un process prend, ou une augmentation du taux de rétention, ou pleins d’autres sujets.
Le problème d’une approche orientée « output », c’est qu’on part donc vers une dynamique où la solution à un besoin est « unique » et identifiée. Elle entraine généralement une remise en question quasi-nulle une fois l’élément livré (ou alors très timide) et surtout une exploration du domaine du problème souvent à la main de la PO.
Une approche orientée « outcome » va lancer l’équipe dans une toute autre direction. Si je te donne un objectif d’augmenter le taux de conversion des prospects de 5%, tu te doutes que la/les solutions ne sont ni toutes égales, ni toutes souhaitables. Mais ce qui est surtout sûr, c’est que peu importe de qui la solution viendra, elle ne sera « validée » qu’une fois le résultat observé de manière empirique et mesurée.
Et là, on peut commencer à apercevoir un nœud.
On peut d’une part avoir une liste de courses drivée par des prises d’infos nébuleuses auprès d’utilisateur.rices vaguement identifié.es et se dire que si ça marche pas, c’est la faute du marché, ou la faute à pas de chance, quand les ordres ne viennent tout simplement pas de plus haut dans la hiérarchie. C’est généralement ce qui arrivera avec un.e PO débutant.e qui n’aurait pas compris le pourquoi du comment.
On peut d’un autre côté être drivé.es par des objectifs business clairement identifiés en équipe et se démener pour les atteindre (ça demande par contre que ces objectifs aient du sens pour tout le monde, mais ça c’est un autre sujet), ce qu’un.e PO expérimenté.e finira souvent par mettre sous la table.
La différence entre les deux, c’est l’expérience, et l’appui du SM qui aura fait comprendre à la PO le bien fondé d’une approche vis à vis de l’autre.
Ca reste 2 métiers et 2 postures différentes, si ce n’est antagonistes.
Pour des petites équipes, se pose d’abord la question de la matrice de compétence. S’il y a peu de devs, est-ce qu’on a quand même bien toutes les compétences pour fournir des incréments de qualité aux utilisateurs ? Et pour éviter la schizophrénie SM+PO, certaines organisations préfèrent maintenir 2 personnes à temps partiel mais les affecter à 2/3 petits produits en parallèle.
Avec 2 membres dev un sm c’est probablement du gaspillage. Avec 3 c’est du luxe.