J’ai une question. Je suis sortie de ma mission « ITIL » et on m’a placé à nouveau dans une autre très grande entreprise française qui s’ouvre à l’agilité ( Ma première mission en tant que SM). Avant mon arrivée, ils ont fait appel à un coach agile externe qui a cadré l’organisation mais surprise, l’environnement n’est pas vraiment représentatif d’une équipe Scrum, avec notamment une équipe de 4 PO dans la Scrum Team qui s’avèrent être les anciens décideurs. Avez-vous déjà géré cette situation? Quels sont les risques d’une telle composition ? Merci d’avance !
The Product Owner is one person, not a committee. - Scrum Guide 2020.
Maintenant, quels sont les possibles risques d’avoir 4 PO dans une équipe Scrum ?
Des décisions plus lentes sur le produit, car besoin constant de communication et de consensus.
Une dilution des responsabilités, qui amène à des lenteurs encore et des frustrations.
Des priorités différentes pour une seule équipe, encore des lenteurs.
4 Product Backlog réels car 4 POs !
Bref ça rend lent et lourd !
Est-ce que j’ai vu une telle composition ? Jamais autant de PO. Au maximum, j’en ai vu deux, et l’intérêt était cohérent par rapport à l’architecture technique, et de plus en tant que binôme c’était « facile » pour eux de prioriser pour une seule équipe. Même si dans les faits, un des POs était le « vrai » et était celui qui prenait les décisions finales, et l’autre PO était OK avec ça.
Après : est-ce un problème pour l’équipe de fonctionner lentement et de cette manière ? Là est la question…
EDIT : Oui OK il y avait juste un seul PO !! C’était juste pour donner un os à ronger au management et liés aux fiches de salaires hahahaha
Du vécu avec un point encore plus marrant : un seul backlog pour tous les PO et mettez vous d’accord pour prioriser vos tickets entre vous… autant vous dire que ça n’avance pas…
Merci pour ta réponse Benjamin. Alors oui, la lenteur risque d’être un problème puisqu’on a une dead line imposée. Ce qui me chiffonne, c’est le transfert des directeurs/managers au rôle de PO(s) et ce pouvoir centralisé qu’il ne sera pas naturel de partager dans l’équipe.
Exemple typique de Cargo Cult. Il peut y avoir plusieurs raisons à cela:
Il est difficile de « rétrograder » un chef de projet, avec des responsabilités de produit, de management et parfois technique, à une fonction de PO. Psychologiquement c’est très dur. Les anciens chef de projets restent des personnes humaines, et ce genre de réorganisation donne une réelle impression de régresser. D’autant plus qu’en France, c’est théoriquement interdit par le code du travail. Donc cette étape n’est peut-être que transitoire.
La boite veut faire une transition Agile et a parachuté ça au middle management qui a nommé des PO pour que la direction leur fiche la paix.
La boite a seulement fait un changement de titre, mais n’est pas prête à se remettre en question sur sa manière de fonctionner.
Ce qu’il faut garder à l’esprit, c’est que Scrum et l’agilité ne sont pas une fin en soi. Ce sont des outils pour régler des problèmes. Identifie déjà ce qui ne marche pas dans l’équipe, et propose des solutions ciblées à des problèmes ciblés. Ne propose pas des solutions à priori juste parce que c’est marqué dans le Scrum Guide.
Ce que je trouve navrant c’est que Valérie parle de Scrum team, visiblement dans une organisation conçue avec l’appui d’un coach agile (sic) et dans cette équipe Scrum on a 4 PO
Alors donc pourquoi appeler Scrum ce qui n’est pas du Scrum ?
Après on s’interroge sur le pourquoi du comment Scrum c’est nul ça marche pas
Donc peu importe ce que la boîte a voulu résoudre comme problématique mais au final ils font n’importe quoi et ils utilisent des terminologies qui répondent à des cadres et objectifs bien déterminés pour des objectifs qui se veulent tout autre.
Faut arrêter de dire que l’on fait du ski alors que l’on est sur une piste en moufles et après-ski assis sur une planche en plastique
Du vécu, ce ne se sont pas des décideurs transformés en PO dans mon cas, mais vraiment des PO recrutés pour le même produit, sauf qu’après une période il était tout simplement impossible de prendre une décision résultats des courses le produit a pris du retard par rapport a la concurrence. Ce que les Scrum Master ont décidé de faire c’est d’analyser le backlog et de sortir les composantes de chaque catégorie ou Feature si on veut ce qui a considérablement réglé le problème. Il y a beaucoup de dépendance entre les différentes composantes, mais moins de conflits qu’avec un et un seul backlog.
L’équipe de développement a subi le même sort par la suite pour en faire de petite équipe par PO par composante. Je sais que ce n’est pas votre cas, mais plusieurs PO sur un seul Backlog je ne sais pas si les PO eux-mêmes sont conscient de cette situation, à mon avis les boîtes qui prennent ce genre de décision ils ne font que déplacer le problème. Par contre ce genre de moove c’est très courant chez les compagnies qui font la transition a Scrum de façon drastique sans préparation.
