Je travaille dans une entreprise qui développe à la fois du hardware et du software, et nous sommes en transition vers plus d’agilité.
Contexte
Organisation en équipes produits (une équipe par pôle de produit), chacune pilotée par un lead PM et 2-3 PMs.
Chaque équipe gère les nouveaux produits ainsi que la maintenance des produits existants.
Plusieurs équipes de développement sont impliquées sur chaque projet (back, app, web, embarqué, méca, élec…).
Forte exigence de reporting et gestion des processus groupe, souvent assurées par les leads PM.
Le rôle de PM est aujourd’hui très dense, entre discovery (trop peu), coordination technique multi-métier et reporting.
Les PM n’assistent pas aux cérémonies de sprint de chaque équipe mais organisent des weekly avec les leads de chaque métier.
Problématique
Manque de focus produit, car trop absorbé par la gestion projet.
Grosse charge de travail car scope très large.
Weekly peu efficients – une approche plus scrum avec une meilleure inclusion des PM (ou PO) auprès des équipes de développement pourrait être bénéfique.
Réflexion en cours : split PO / Chef de projet
Nous envisageons une séparation entre un Product Owner (PO) et un Chef de projet :
PO → Focus sur le produit : discovery, spécifications, priorisation produit du backlog, validation des incréments à chaque sprint.
Chef de projet → Gestion des ressources, priorités projets, milestones, deadlines, ainsi que l’industrialisation, les process et le reporting.
En résumé :
Le chef de projet définit le cadre temporel : “On doit sortir le produit à telle date, les tests utilisateurs à telle date.”
Le PO construit le produit dans ce cadre : “Avec ces contraintes, on priorise telles features.”
Nous n’avons pas encore défini l’organisation exacte des équipes avec un tel changement, ni clarifié tous les détails de cette proposition, mais nous sommes très intéressés par vos retours.
Avez-vous déjà expérimenté une telle organisation ?
Quels sont les écueils à éviter ?
Quel impact sur les équipes selon vous ?
D’autres approches vous semblent-elles plus pertinentes ?
Bienvenue sur le forum Scrum Life et merci pour ce cas d’étude très intéressant.
Tout d’abord, pour lever une ambiguïté, ce que tu nommes PM, c’est le Product Manager ou le Project Manager ?
Comment se traduit dans les faits le manque de focus produit ? Par une priorisation aléatoire qui ne tiendrait pas compte de la valeur apportée au client final ? Avez-vous une vision produit claire ?
La grosse charge de travail se traduit-elle par un fort turnover ou bien est-il contenu et les gens restent tout de même malgré le rythme soutenu ? Est-ce une charge de travail élevée ou bien une charge cognitive élevée (beaucoup de sujets différents en même temps) ?
En quoi vos weekly sont peu efficients ? Quel est le but que vous donnez à ces weekly ?
Les projets et cycle de vie produit pour la partie software et hardware partagent-ils les mêmes problématiques (contraintes réglementaires, délai du feedback, dépendances avec des tiers) qui pourraient permettre une même organisation (ou pas) ?
Quelles sont les métriques que vous souhaitez améliorer ?
En tout cas, je me garderai bien de te fournir une recette toute faite.
Quelle que soit la voie que vous choisirez, il pourrait être judicieux d’expérimenter avec une équipe pilote ayant de l’appétence pour votre démarche.
Pas suffisamment de discovery, d’interview user ou d’usage de la data. La priorisation prend compte de la valeur pour le client mais gagnerait à être vérifié par retour terrain. Pour la vision produit, je te dirai oui.
Difficile de dire si les récents départ sont liés à la charge. Pour ce qui est de la charge, je pense que c’est à la fois le travail et la charge cognitive mais cela dépend surement des personnes.
Pendant les weekly, chaque équipe énonce les avancements mais toutes les autres personnes ne sont pas forcément attentives. Aujourd’hui, c’est surtout un moment d’échange inter-équipe qui donne en même temps de la visibilité au PM.
Les deux ont des cycles différents et sont justement géré un peu différemment. Souvent, il y a un weekly Hardware et un weekly Software.
Le time to market bien sur mais aussi de gagner en efficacité (sur les échanges avec l’équipe de développement par exemple) et ainsi réduire au moins la charge mentale en apportant du focus.
Whaou même si certains points me font réagir on voit qu’il y a du travail de la réflexion de l’analyse.
Personnellement comme j’adore le principe des équipes à taille raisonnable je n’utiliserai pas le terme de chef de projet.
Retirer le mot chef parce que c’est juste quelqu’un qui est responsable ou plus spécialisé que d’autres pourquoi dire chef de projet allrs qu’on ne dit pas chef du développement ou chef du uX ou chef du testing ou chef de la db.
Retirer le mot projet puisque vous avez dit être en mode produit.
Attention de nouveau ce ne sont que des remarques pour faire réfléchir.
Je défends l’autonomie de l’équipe et la responsabilité globale de l’équipe quel que soit les compétences de ses membres toujours ce même mantra de l’équipe sportive où on a des défenseurs des attaquants un gardien dans certains sports un lanceur dans d’autres et pourtant c’est toute l’équipe qui gagne et toute l’équipe qui perd ça n’a aucun sens en dehors de l’équipe de mettre des différences entre les membres
Je vous conseille de tenter une cartographie estuarienne pour dérisquer l’action que vous voulez tenter et pour découvrir d’autres pistes à explorer en même temps.
Mon sentiment tout d’abord est que vous partez déjà d’une base organisationnelle intéressante. Vous savez déjà travailler en mode produit. Je rejoins à ce titre le point de vue de @Moosh qu’il serait dommage d’affaiblir cette culture pour l’hybrider avec du mode projet.
Ce que je comprends de ton contexte, c’est qu’il y a tout d’abord de la marge de progression méthodologique. Par exemple, vous pourriez changer l’approche de vos weekly en le refocalisant sur les objectifs d’itération (ou sprint, ou autre) à atteindre. Qu’est-ce qui doit vous permettre d’atteindre vos objectifs et qu’est-ce qui est un obstacle à ces objectifs. Même s’il y aura forcément de la revue d’avancement durant ces échanges, cela les remettra davantage en perspective.
Il y a aussi une réflexion sur l’organisation. Et à ce titre, tes interrogations sont tout à fait légitimes. Mon sentiment, avec les éléments à disposition, c’est que tu pourrais peut-être regarder du côté de Team Topologies pour voir s’il ne manquerait pas des équipes complémentaires aux équipes en charge de livrer des fonctionnalités (stream-aligned team dans le jargon de Team Topologies), comme des équipes en charge des plateformes techniques ou des équipes de facilitation, qui permettrait d’alléger à la fois la charge de travail et la charge cognitive des équipes produits.
N’hésite pas à nous tenir au courant de cette réorganisation.
Contexte
En résumé :