Nous menons des missions de transformation à l’ère du digital. Nous sommes parfois amenés à piloter une mise en œuvre en mode Agile (voir nos articles sur les méthodes agiles, là, là, là ou encore là). Dans certains cas, il arrive que les entreprises soient tentées (obligées ?) de nommer plusieurs Product Owners (P.O.). Cela peut être dû au contexte du projet, à la culture intrinsèque de l’entreprise ou à ses contraintes organisationnelles.
Obligation ou pas, cela peut amener des difficultés et générer des couacs pour le projet. Comment les éviter ? Voici un tour d’horizon.
Pourquoi le P.O. est-il la cheville ouvrière du projet en mode agile ? (Piqûre de rappel)
Pour l’avoir un tant soit peu vécu, il faut admettre que le P.O. est vraiment au four et au moulin, au cœur de la méthode agile. Certes il n’est pas le seul mais il est incontestablement un des rouages essentiels si on veut que la machine (du projet en mode agile) fonctionne correctement. Entre construire le backlog projet, prioriser/affiner les users stories à embarquer dans les prochains sprints de développement, répondre quotidiennement aux sollicitations de l’équipe de développement, interagir si nécessaire avec le sponsor projet pour réaliser les arbitrages, préparer les comités de pilotage… Être P.O. est un engagement intense.
Pourquoi plusieurs P.O. sont-ils parfois nommés ?
Plusieurs raisons peuvent être à l’origine d’un tel choix. Nous ne citerons ici que les situations les plus souvent rencontrées, cette liste n’est donc pas exhaustive :
- L’impossibilité de dégager un temps plein
Comme rappelé plus haut, être P.O., c’est un engagement à temps plein. Au vu de la valeur ajoutée attendue du P.O. les profils idéaux sont souvent des personnes clés de l’entreprise, donc déjà très occupés par ailleurs. Donc dégager une telle personne clé à temps plein pour un projet peut s’avérer compliqué pour l’organisation. Cela est d’autant plus vrai quand, au niveau métier le niveau de charge est déjà très élevé. Cela peut mener au choix de nommer un P.O. Proxy (plus d’informations dans cet article).
- La volonté de ne pas quitter le métier
La résistance peut se manifester du côté des principaux intéressés par le rôle. Quitter son poste actuel pour se consacrer à un projet de transformation sur deux, trois ou même cinq ans est une belle opportunité en soi, mais quid du retour à la fin du projet ? Quel nouveau positionnement ? Bref quelle place au retour à la réalité du métier ? Cette incertitude peut pousser les intéressés à vouloir ne pas se déconnecter complètement du métier donc à ne pas prendre le rôle de P.O. à plein temps. Proposer des perspectives claires en sortie de projet aux acteurs qui s’y engagent est une vraie question à adresser (mais ce n’est pas l’objet de cet article).
- Le contexte organisationnel
Lorsque l’entreprise est organisée en business units faisant le même métier sur des secteurs différents, il peut y avoir une tendance naturelle à vouloir mettre en place une équipe pluridisciplinaire plutôt qu’un seul P.O. Cette tendance se justifie par le fait qu’un unique P.O. censé représenter le métier (de façon globale) ne connaît pas toujours très bien le fonctionnement des autres business units du fait de leurs spécificités. En substance, la justification est : « on fait le même métier différemment… car nos clients sont différents ».
Quels sont les risques d’une telle configuration ?
Les risques de cette configuration vont différer selon le nombre de projets en jeu. Deux cas peuvent se présenter :
- Cas 1 : plusieurs P.O. / une équipe de développement / un projet
Ce type d’organisation risque d’une part de faire émerger des difficultés d’alignement entre les P.O. et d’autre part de complexifier la priorisation. Cela aura pour conséquences une potentielle confusion pour l’équipe de développement, des difficultés à l’alimenter, faisant prendre du retard au projet.
Ce cas de figure est révélateur d’une équipe de développement trop grande pour être alimentée par un seul P.O. Cela pourrait signifier que le projet a un périmètre trop large et/ou nécessite des compétences / expertises métiers pointues.
Dans ces conditions il est souvent nécessaire de remettre en cause soit la taille de l’équipe de développement, soit le périmètre du projet et d’envisager un découpage en plusieurs sous-projets voire sous-équipes (voir notre article sur la taille idéale d’une équipe agile).
- Cas 2 : plusieurs P.O. / une équipe de développement / plusieurs projets
Dans ce type d’organisation, il risque d’y avoir beaucoup d’arbitrages et/ou de frustration en ce qui concerne la bande passante (en termes de volume de développement) allouée à chaque projet à chaque sprint planning. Chaque P.O. voulant que son projet aboutisse le plus vite possible, l’exercice de priorisation est difficile.
Ce cas de figure peut sembler logique : un P.O. par projet, quoi de plus normal ? Attention, il ne faut pas se tromper, le juge de paix n’est pas le nombre de projets mais bien le nombre d’équipes de développement qui constitue la ressource critique. C’est autour de cette ressource qu’il faut construire son organisation pour délivrer les projets de la manière la plus efficiente possible. Pour rappel, les méthodes agiles préconisent un P.O. pour une équipe de développement (pour en savoir plus sur la taille idéale d’une équipe agile, cliquez ici).
Vous l’aurez peut-être deviné, l’équipe de développement subit les conséquences de cette organisation et les impacts peuvent être de divers ordres : défaut de qualité, tension / frustration, usure des membres de l’équipe…
Comment faire en sorte que ça marche ?
Si l’organisation est constituée et que les choses sont lancées, il peut être difficile voire risqué de faire machine arrière. De plus les leviers de changement organisationnels sont rarement dans les mains des membres de l’équipe agile. Il faut donc faire avec !
Sans nécessairement révolutionner l’organisation, il faut mettre l’accent sur le management visuel, en particulier sur les éléments prêts à être embarqués dans les sprints plannings. Dans un cas comme dans l’autre (cités plus haut), cela contribuera à réduire les problèmes d’alignements entre les différents P.O. Le travail restant pour les P.O. consistera en un exercice de priorisation pour que l’équipe de développement puisse être efficace dans le traitement des sujets.
Pour le cas de figure ou l’équipe agile gère un seul projet (ie. Cas 1), une instance d’alignement des P.O. en amont des sprint planning (avec un tiers « arbitre », en général hiérarchique, en cas de besoin) peut s’avérer en plus nécessaire.
Pour le cas de figure où l’équipe agile doit gérer plusieurs projets (ie. Cas 2), il faut obligatoirement fixer la voilure. Deux options peuvent être envisageables :
- Allouer une charge de développement à chaque projet en fonction du poids de chaque projet. L’avantage de cette option est que le P.O. est dans un certain cadre et n’a à son niveau qu’à préparer les users stories à développer et les prioriser en fonction de l’avancement. L’exercice de priorisation en sprint planning se fait donc efficacement.
- Décaler les périodes de développement des projets pour concentrer les efforts sur un ou deux sujets à la fois. Cette option a pour avantage de permettre à l’équipe de ne pas s’éparpiller sur plusieurs sujets et concentrer ses forces vives pour les faire aboutir un par un. L’inconvénient principal est que la charge, qui était lissée dans le temps pour chacun des PO se retrouve concentrée sur une courte période. Cette nouvelle répartition n’est pas forcément compatible avec la charge induite par le reste de ses activités.
Conclusion
En synthèse, si vous devez mettre en oeuvre des projets en mode agile, construisez votre organisation en fonction du nombre d’équipe que vous souhaitez mettre en place et pas du nombre de projets à réaliser. La recommandation est un P.O. pour une équipe agile. Si vous n’avez pas le choix ou que vous êtes déjà dans les cas cités plus haut, revenez aux fondamentaux (créez des instances d’alignement des différents acteurs) et/ou découpez (soit la bande passante de l’équipe de développement, soit le calendrier de réalisation des développement).
