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 :
l’équipe, en l’aidant à trouver les clés de l’auto-organisation, supprimer les obstacles, organiser les événements d’équipes, aider dans le delivery (techniques de flow, dod, dor etc.)
le PO, en l’aidant dans sa relation avec les parties-prenantes, la qualité de communication au niveau vision, product goals, product backlog, product planning et product backlog items
l’organisation, en distillant la culture agile, organisant des formations, acculturant les décisionnaires et les parties prenantes aux principes agiles
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 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
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 !!