Gestion multi-projets : ai-je besoin d’un backlog global?

Communauté Scrum Life
1

Bonjour à toutes et à tous,

Je viens de joindre une nouvelle équipe à titre de PO et j’aimerais vous lire au sujet de la gestion des projets/produits multiples avec une seule équipe, soit 4 développeurs, sans scrum master.

Je suis en charge de deux plateformes. Je travaille actuellement sur la refonte d’une de ses plateformes et je devrai m’assurer de conserver de la capacité pour les opérations et la maintenance pour l’autre.

Le hic, hormis la taille de l’équipe pour livrer les nombreux projets, c’est que nous travaillons sur 2 backlogs différents et un 3e sera bientôt crée pour un nouveau produit. C’est bien quand on a 1 équipe par backlog, mais vous aurez compris que ce n’est pas le cas. Je songe à créer un grand backlog global dans lequel on créera nos sprints, ce qui je crois permettrait une meilleure organisation du travail, mais cela impliquera sans doute plus de travail de ma part afin de mettre à jour les backlogs de produit.

Qu’en pensez-vous?

Je vous remercie d’avance pour vos lumières!

2

Bonjour et bienvenue

Pour scrum, 1 produit = 1 backlog
Ne pas faire ça c’est amener du gaspillage avec du context switching dans le sprint, ne pas être focus, ne pas dégager un objectif de sprint unique et j’en passe.

Votre rôle semble biaisé du fait de l’absence de SM, en effet, gérer « la capacité pour les opérations et la maintenance », c’est plus le rôle d’un chef de projet qu’un PO.

Comme dans beaucoup d’organisation il va falloir trouver un fonctionnement adapté à votre contexte, probablement inspiré de scrum, mais sans en être vraiment. Je pense que plein d’expert ici peuvent amener leur propositions :grinning:

2 « J'aime »
3

Bonjour, je vais aller dans le même sens que Nicolas. Je dirais que je me suis accroché les pieds avec le

Citation ClaudiaB
« …sans scrum master »

Citation

Sans Scum master, a mon avis on n’est plus en SCRUM. On ne peut enlever aucune rôle si on veut faire du Scrum. Ils ont tous très important.

Pour cité

Citation Nicolas BIOT
Pour scrum, 1 produit = 1 backlog

1 ProductBacklog par ProductBacklog.

Suivre plusieurs Backlog de produits. c’est beaucoup changement de focus inutile.

Une stratégie que j’ai réfléchie pour une problème similaire. C’est d’avoir un productBacklog unique. Nous avons une dizaine d’application en entretien et maintenant, dont 2 ou 3 qui demandent régulièrement des efforts.

Mais, tes items dans une seule backlog. je pense leur ajouter des « Tag » pour le classement et la filtration dans le Board (dans mon cas Azure DevOps. Mais je pense Jira offre quelque choses de similaires).

Cette solution peut-être viable si individuellement vos ProductBacklog ne contient pas des milliers d’items. si plus de 200 item. Là c’est sur, Un product Owner par productBacklog. Impliquer aussi vos développeur dans construction de l’outils de gestion du ou des Backuplog.

J’aimerais revenir sur le rôle du product Owner, est un « maximiseur de valeurs » pas un chargé de projet. Il faut nommer un chat, un chat. Pas une boule de poils à quatre pattes. P.S. Ce n’est pas une critique. C’est peut-être que votre titre ou rôle qui est mal définit.

Quant à Scrum, dans votre contexte, est-ce possible ? Peut-être, mais sans jamais l’ajout de Scrum Master dédié et d’une bonne feuille de route. Ça va être difficile.

Avez vous pensé à jeter un œil du coté de Kanbans, c’est pour ma part que j’étudie présentement.

Les méthodologies Agiles ne sont jamais des solutions miracles à tous les mots.

Bon courage, la montagne risque d’être longue à monte.

Bruno Larouche

1 « J'aime »
4

Je pense qu’il faut revenir à ce qu’est un backlog et à quoi ça sert.

Un backlog produit liste l’ensemble des nouveaux services à fournir aux utilisateurs, ou amélioration des services existants. Il permet de visualiser l’ensemble des opportunités identifiées pour améliorer le produit, c’est à dire améliorer l’adéquation du produit aux besoin des utilisateurs. En priorisant le backlog et en concentrant les efforts sur les fonctionnalités les plus attendues par les utilisateurs, on maximise le flux de valeur du produit pour l’utilisateur. Le backlog produit est donc organisé de manière cohérente par rapport au produit, car son rôle est marketing et non pas organisationnel.

Le fait d’avoir une seule équipe de développement pour plusieurs produits est un challenge, dans la mesure où les produits sont donc en concurrence sur l’accès à la ressource critique que constitue le développeur. Dans ce contexte, un aspect déterminant est la stratégie que l’organisation décide de mettre en place pour arbitrer la répartition de l’effort de développement entre les produits. Par exemple, si l’organisation décide d’arbitrer cela manière équilibrée (chaque produit recevant 1/N de la capacité de travail), disposer d’un backlog commun ne présente pas spécialement d’intérêt.

A contrario, si l’effort de développement est réparti de manière équitable (en fonction des espérances business), alors disposer d’un backlog commun est intéressant puisqu’il permet de prioriser les items de backlog des différents produits entre eux, et donc ensuite de déterminer une répartition du temps de travail dédié à chaque produit. Cette situation est toutefois assez suboptimale, car elle nécessite que les développeurs maintiennent des compétences cohérentes avec l’ensemble des produits, ce qui peut constituer un charge mentale significative et avoir des répercussions néfastes sur la productivité.

Par ailleurs le backlog est détourné de son rôle purement marketing au profit d’un rôle managerial (qui travaille sur quoi). Cela pose diverses questions sur la manière dont l’arbitrage est réalisé de manière effective : par qui, quand, et dans quel but.

Petite remarque en aparté, il faut dissocier backlog de l’outil dans lequel on range les items. Disposer d’un outil unique, centralisant l’ensemble des items de tous les produits, et requêtable produit par produit, ne constitue pas nécessairement un backlog global. Un backlog global c’est quand on pilote l’activité en priorisant les items d’un produit par rapport à ceux d’un autre.

3 « J'aime »
5

Cette situation est curieuse. 4 devs pour 3 produits me semble être la bonne recette pour du surmenage. A moins que ces produits soient minuscules, ce qui arrive.

Je te conseille de t’appuyer sur le trio Team Topologies, Domain-Driven Design et Wardley Map. Suzanne Kaiser a fait une présentation là-dessus : https://youtu.be/Lfzph_5wb9c. C’est une question de flow et de complexité des produits. Si les produits sont peu complexes et les technos peu différentes, alors les changements de contexte sont peut-être peu problématiques.

3 « J'aime »
6

Merci pour cette réponse très éclairante. En effet, je pense que le backlog global pourrait à terme m’aider à piloter l’activité en priorisant le travail sur un produit par rapport à un autre, surtout que la refonte d’une des plateformes vise à uniformiser nos technologies. Mais c’est peut-être pas la priorité pour améliorer notre fonctionnement à court terme.

1 « J'aime »
7

Attention, cependant, le backlog global ça scale mal.

Pour l’instant, cette approche t’évite les phénomènes de quantization. Mais le jour où tu montes à des effectifs et un nombre de produits plus importants, tu devras basculer sur une approche capacitaire. Il faudra donc repenser l’organisation du backlog séparément du pilotage managerial et revoir les outils mis en place. Il serait dangereux de ne pas anticiper les risques associés à ce pivot. L’uniformisation technologique n’est pas forcément un atout non plus. Ca veut dire que le choix de la technologie sous-jacente à chaque produit est réfléchie d’abord par le prisme managérial et pas par celui de l’adéquation au besoin de l’utilisateur. A terme, il semble souhaitable d’équilibrer les deux. On ne peut jamais vraiment maîtriser toutes les technos possibles et imaginables sauf peut-être dans une multinationale, mais d’un autre côté c’est dommage de se verrouiller alors qu’on pourrait s’ouvrir à quelques technos différentes pour se simplifier le travail.

J’aurais donc tendance à dire qu’aller sur un backlog global est donc un choix favorisant le court terme au détriment du long terme. A toi de voir si ça fait sens par rapport aux objectifs et ambitions de l’organisation.

Au passage, c’est une question plus organisationnelle/managériale que marketing, donc « normalement » pas trop dans les mains d’un PO. Mais bon, c’est aussi pas très « by the book » d’avoir 3 produits à maintenir. Ce qui m’amène à une dernière question : est-ce que ces 3 produits en sont vraiment ou n’est-ce finalement qu’un découpage technique d’un produit unique ? Pour y répondre, le meilleur moyen est de se demander si chacun peut adresser le marché séparément (avec des utilisateurs/besoins différents pour chaque produit) ?

Si la réponse est négative, alors peut-être que c’est cohérent de créer un backlog unique avec un PO unique puisqu’on n’a - en fait - qu’un seul produit.