Press "Enter" to skip to content

Comment gérer plusieurs produits en parallèle ?

Comment gérer plusieurs produits en parallèle ?

C’est un problème assez courant : comment faire quand les produits se multiplient mais pas les équipes ? Comment gérer tous ces produits ? Je me permet de partager un échange autour de cette problématique…

Une ou plusieurs équipes ?

J’ai un problème majeur que je ne sais pas vraiment régler : le multi produits… Notre CEO est quelqu’un qui a beaucoup d’idées, et cela nous amène à enchaîner les développements. Là où une startup capitalise sur un seul produit, nous allons en sortir 2, 3, 4… et nous n’avons pas forcément la possibilité de faire grossir l’équipe de développement en conséquence !

Je suis donc à un carrefour où il faudrait mener 2 projets de front, dont un sur lequel nous avons peu d’expérience. Le choix:

– Garder l’équipe de 4 personnes et induire du délai, ou

– Séparer l’équipe en deux, avancer moins vite, ne pas partager complètement la connaissance produit, etc…

Pas facile 🙂

Un backlog global inter-produits

Pour les questions de multi-projets/multi-produits, je recommande d’introduire un backlog global entre toutes les US/Epics/Features/expérimentations projets/produits et de ne travailler que sur un seul sujet à la fois, le plus prioritaire.

À la suite plutôt qu’en parallèle

En schématisant, en faisant 2 sujets en parallèles, les deux seront longs.

On fait les deux sujets en parallèle : ils avancent chacun à 50% de la vitesse maximale. C’est une hypothèse idéale : en réalité on est souvent à moins de 50% car on perd du temps à gérer plusieurs sujets en parallèle.

En faisant l’un, puis l’autre, le premier va sortir plus vite et le second sortira à la même date que si les deux avaient été faits en parallèle. On gagne donc sur le délai moyen.

On fait les deux sujets en parallèle : ils avancent chacun à 50% de la vitesse maximale. C’est une hypothèse idéale : en réalité on est souvent à moins de 50% car on perd du temps à gérer plusieurs sujets en parallèle.

Et cet effet s’amplifie si la prioritisation des sujets est bonne : c’est le sujet qui apporte le plus de valeur qui sort le plus vite.

On fait les deux sujets en parallèle : ils avancent chacun à 50% de la vitesse maximale. C’est une hypothèse idéale : en réalité on est souvent à moins de 50% car on perd du temps à gérer plusieurs sujets en parallèle.
On fait les deux sujets en parallèle : ils avancent chacun à 50% de la vitesse maximale. C’est une hypothèse idéale : en réalité on est souvent à moins de 50% car on perd du temps à gérer plusieurs sujets en parallèle.

En conclusion, garder une seule équipe n’induit pas du délai. C’est plutôt tout le contraire.

Un seul but à la fois

Une équipe de 4 personnes, c’est déjà une petite équipe. Il ne sera pas réellement possible de faire les choses en parallèle.

Le but est donc bien qu’à tout moment l’équipe n’ait qu’un seul et unique but à accomplir, qu’une seule chose en tête.

L’équipe donne son maximum et une fois que c’est sorti elle change de sujet et s’y donne à nouveau à fond.

Le découpage

Et au final, la clé dans tout ça, c’est… Le découpage. En découpant les sujets, justement, on arrive à livrer le maximum de valeur pour le minimum d’effort.

Au niveau du backlog global, les éléments doivent être le plus petit possible, tout en restant pertinent d’un point de vue business. Je ne parle pas là du découpage en vue de sprint qui permettra un déroulé fluide pendant les itérations, et où chaque US ne représente pas toujours unitairement un sujet à mettre entre les mains du client. Je parle d’un découpage de haut niveau, très axé produit, où chaque incrément correspond à une valeur forte mise entre les mains du client, ou à une expérience où un apprentissage est manifeste.

Arrêter les itérations de durée fixe

Vous pourriez même pousser l’idée encore plus loin et faire des itérations de durée variable vu que les sujets n’ont pas une durée uniforme. C’est une approche complètement non-orthodoxe mais cela fait sens sur le papier.

Une manière plus classique de mettre cela en place est de faire du Kanban plutôt que du Scrum, c’est à dire de ne plus avoir du tout d’itération. Par contre l’équipe n’a qu’un seul sujet en cours, donc gros focus.

Quant aux rituels, vous pouvez décider de les mettre en place par rapport à ces changements de sujet plutôt que par rapport aux rythmes d’itérations qui ne feraient pas sens dans ce mode de fonctionnement.

Le Lean Startup

Un point important : faites du Lean Startup ! Vous n’avez pas les ressources de construire des usines à gaz. Faites-en votre atout, vous êtes obligé de travailler intelligemment.

Pour aller plus loin

Itérations de durée variable et autres réflexions par John Cutler

Qu’est-ce que le Lean Startup ?

On fait les deux sujets en parallèle : ils avancent chacun à 50% de la vitesse maximale. C’est une hypothèse idéale : en réalité on est souvent à moins de 50% car on perd du temps à gérer plusieurs sujets en parallèle.

J’apprécierais vraiment si vous pouviez me laisser un commentaire pour me dire ce que vous appréciez ou ce qui pourrait être amélioré dans cet article.

Et si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

À bientôt 😊

Top