J’ai rejoint récemment une entreprise qui propose plusieurs produits dans l’environnement RH/ recrutement dans le rôle de Product Manager. Ces produits sont indépendants. Ils sont vendus actuellement séparément. À terme, ils vont devenir des options activable sur la même plateforme.
Pour vous donner le contexte :
Nous avons une seule équipe technique (5 personnes) qui travaille sur l’ensemble des produits. En fonction des enjeux business du moment donné que nous donnons la priorité à l’un ou l’autre produit.
Historiquement, il n’y a pas de responsable de backlog.
Chaque Epic correspond à un produit ou un client (quand le client nous demande de développer des choses spécifiques pour eux).
Pas de Scrum mais des sprint . tous les 2 semaines, ils se réunissent pour discuter sur la priorité et puis chaque dev doit mettre eux même leur tâche dans le backlog. C’est lui qui décide s’il l’ajoute dans un Epic existant ou créer un nouveau, ainsi que la façon qu’il le rédige. Cela ne concerne que lui pour se retrouver, personne vérifie dernière.
Tous les 2 semaines, ils changent de sprint en récupérant la totalité des US non terminé dans le suivant mais personne regarde ce qui reste. Il y a des US qui passent de sprint en sprint depuis des mois, assigné aux collaborateurs qui ont déjà quitté l’entreprise depuis longtemps.
Sachant que j’ai plusieurs autres responsabilités qui ont plus de priorité aux yeux de la direction, mais aussi aux miens et jusqu’à là, l’organisation du backlog n’est pas considéré comme quelque chose qui mérite de passer un temps dessus.
( Je suis départagé. D’un côté, le backlog actuel me donne pas envie de mettre la main dedans et j’aurai pas de temps pour consacrer sur le nettoyage. D’autre côté, ça me pique aux yeux de laisser trainer un backlog aussi désordonné. Quel faites vous à ma place ? )
En cas où je m’y mets, je pense supprimer les sprint qui n’ont pas vraiment de sens (on n’a pas des cérémonies, pas d’objectif de sprints et on ajoute tous les jours des urgences venant de tous parts…) et mettre du kanban à la place pour bien prioriser les sujets.
Donc mes questions:
À votre avis, comment je dois organiser le backlog dans ce contexte multi produits, chaque produit a lui-même des épics et des US avec une seule équipe technique comme ça.
Et que faire / comment faire pour ne pas trop bousculer l’équipe étant donné les habitudes qu’ils ont jusqu’à là ?
J’ai une tendance à ne rien jeter « au cas où ».
Mais du coup j’arrive souvent à avoir des « grosses listes d’éléments probablement/potentiellement périmés obsolètes »
Ma solution : j’en fais une collection d’éléments qui sont là pour ce qu’ils sont : « une boite à idées/challenges/souvenir ».
C’est-à-dire que je ne les jette pas, mais je les retire du « backlog apparent ».
Ce ne sont plus des éléments à « envisager de faire » mais une boite à éléments à relire, si dans mon backlog actuel je travaille sur des éléments similaires.
Et donc si dans mon backlog « actuel » je prends un élément à travailler, j’irais voir s’il y en a des similaires dans ce bac à souvenir comment j’avais vu les choses à l’époque, comment j’y avais réfléchi.
J’essaye de mettre en évidence ce qui a changé pour alimenter la discussion.
Crédit : cette façon de faire m’est inspirée du concept des « bacs » de Claude Aubry,. Mon bac à Souvenir, c’est un peu son bac à glace.
C’est qui nous ?
1 équipe = 1 Backlog => le PO de l’équipe ordonne le backlog (pas prioriser, plus depuis 2013, sorry je ne trouve plus la ref, mais c’est lié au scrum guide de l’époque)
J’ai pas tout tout compris le fonctionnement mais voici mon avis sur la question :
organiser le backlog c’est une solution qui vient de ta réflexion, c’est peut-être pas forcément la priorité
isoler le problème que vit ton équipe c’est plus ça l’objectif il me semble
Tu pourrais leur proposer ton constat de la situation observée sans forcément juger de ce qui est bon ou mal mais les laisser te faire un retour sur ce qu’ils ressentent
Si l’équipe avance que tout est normal car ils ont toujours fait comme ça, tu pourrais leur présenter des cas concrets qui te semblent être des anti-pattern à l’agilité ou du moins à l’efficacité.
Je pense qu’il y a plein de questions à débattre avec eux :
Quid des tickets qui passent d’un sprint à l’autre ? (=> comment on peut les terminer en un sprint ?)
Quid des tickets non assignés ? (=> les supprimer ?)
Quid de la vision du ou des produits ? (=> le backlog reflète-t-il cette vision ?)
Quid du backlog ? (=> ils le regardent un peu, le comprennent ?)
Etc, etc.
Si tu peux être l’impulsion pour débattre de tout ça en équipe ça permettra de vous aligner j’espère sur les priorités à mener sans qu’ils sentent des injonctions à faire des choses dont ils ne verraient pas l’intérêt.
Peut importe la taille du produit ou le nombre d’équipes qui travaillent dessus : si c’est 1 Produit(pas équipe) = 1 Backlog = 1 PO
Il faut s’aligner sur c’est quoi ici LE Produit, là je suppose que c’est la plateforme et les options activables sont des features(à découper en épics, puis en US) dans le produit.
L’idée maintenant sera d’ordonner ces features(ex A B C) soit:
chaque feature comme un Product Goal(PG), donc 3 PG(A, B et C) et de travail sur 1 PG à la fois(le PG actif comme dit Scrum) et de remplir le Backlog qu’avec les US permettant d’atteindre cet objectif sur long terme(selon la roadmap Produit, par exemple sur 3 - 6 mois) avant de passer au PG suivant.
d’avoir un seul PG avec toutes les features/Epics/US à ordonner et prioriser pour qu’à chaque Sprint qu’il y ai: un peu de A, un peu de B et un peu de C
On a souvent tendance à tripatouiller les concepts pour ne les utiliser que comme ça nous arrange.
Un produit ce n’est pas la transposition d’un logiciel. Si j’ai trois logiciels ou plateforme ou site web ça veut dire que j’ai 3 produits. Non. D’un point de vue marketing, c’est surement le domaine le mieux placé pour parler de produit, le produit répond aux attentes des consommateurs : la cible est définie, le prix, le support, l’expérience globale du consommateur.
Ici Hanh nous explique qu’il y a plusieurs produits bien indépendants, donc il devrait y avoir un PB par produit. Si la première idée qui émerge est de dire : un produit → un backlog, très bien !
Ca apportera de la clarté et transparence à tout le monde
La problématique de la refonte des produits en un seul c’est autre chose, autre chose qui nécessitera de fusionner les backlogs en un seul et unique pour le produit unique et qui englobera les features des futurs-ex-produits
Ce sujet m’interresse beaucoup voire m’interpelle beaucoup car reflète une experience passée et que ci s’était à revivre je dirais merci à Scrum Life de proposer ces questions.
Pour mon cas il s’agissait plutôt d’UN produit n périmètres pour n équipe DEVrs.
On l’aura compris, il s’agit là pour moi d’un management support applicatif qui m’était attitré. Le contexte n’est pas le même c’est fort probable mais la problématique s’en rapproche de manière implicite. La réponse de @Moosh me parle alors et serait amené à considérer cet avis.
En effet si la correction ou évolution (feature) à apporter était certes à traiter en vue d’une livraison donnée (non nommé sprint à l’époque).
Maintenant, ce qui m’a beaucoup manqué est une sprint goal regroupant un ensemble de n tickets, pour :
En définir la priorité
Tenir compte des tickets existants ou à supprimer pour obsolescence et surtout tenir compte des points communs les liant pour une meilleure visibilité et surtout partage inter équipes DEVrs surtout si le même produits concerne n périmètres.
J’espère ne pas embrouiller le débat mais cette situation était fréquemment rencontré dans mon poste en 2010.
Pour être honnête je suis curieux de connaître les différents échanges concernant la proposition 1PG proposée par @Moosh
Si ce n’est pas considéré comme quelque chose qui mérite de passer du temps dessus (ni par toi, ni par la direction, ni par l’équipe), il faut probablement … ne pas passer du temps dessus. S’il n’y a pas de problème à résoudre, alors il n’y aura pas d’objectif à atteindre et il sera impossible de piloter la transformation.
Ca reviendrait à faire de l’agile pour faire de l’agile.
J’utilise (aussi grâce au même livre référence de Claude Aubry) dans tous les projets pour aider à l’organisation du Backlog, le système bacs:
bac à sable: pour les idées nouveaux besoins (le PO s’aligne d’abord avec la personnes qui a émise le besoin jusqu’à ce que ce soit assez mature pour être présenté et affiner avec le reste de l’équipe)
bac à glace: pour les besoin suspendus ou lesquels l’équipe ne va pas travailler sur le court voire moyen terme
bac à R&D / refactoring / bugs…etc
bac d’affinage
bac de prêt
et enfin le sprint Backlog
Dans tout les cas, je rappelle toujours que c’est un seul Backlog(une seule liste) et doit refléter les priorités du moment du PO sur le Produit(il faut déjà un alignement sur la Vision du Produit) notamment le PG actif(donc tout le reste devrait rester chez le PO en arrière plan).
C’est encore un start-up qui s’ajuste pour se développer. Je pense que l’équipe dans l’ensemble est ouverte au changement. Cependant le temps est notre principal adversaire. L’équipe est peu nombreuse et On a des journées de dingue à jongler entre les tâches techniques qui rendent les produits plus stables, des nouvelles fonctionnalités et la corrections des bugs.
J’ai vu le backlog actuel comme un registre des choses faites (très peu de chose « à faire », on ajoute des nouvelles choses chaque jour, un US ressemble à « X a corrigé tel bug pendant 3h », rien d’autre), pas de vision, ni roadmap.
Je prévois de faire des workshop pour établir un roadmap dans les prochains jours mais je doute que quelqu’un aura temps à consacrer au backlog, rien que pour faire des réflexions
La fusion des produits ne crée pas de nouvelles fonctionnalités pour les produits eux-mêmes et ça ne change pas de roadmap ni de backlog de chacun (s’il y en a).
Je suis d’accord du fait que un PB par produit est la solution la plus simple et propre mais pour faire avancer les produits en parallèle n’est pas simple. Nous sommes une petite start-up et chaque produit a encore besoin de développement pour être compétitive sur le plan commercial, on ne peut pas focus pendant x temps sur un seul puis passer à l’autre, sauf pour un qui a déjà toutes les fonctionnalités minima
C’est un choix à faire, tu as plusieurs options pour éviter les gaspillages, des sprints très courts sur des petits changements sur un seul produit. Soit tu parallelises avec 2 produits à la fois. Faut trouver le bon rythme, mais avant il faut de donner de la visibilité en sachant ce qu’il y a à faire et pourquoi.
Qu’est ce qui peut être plus important que le backlog de vos produits?
Ca me fait penser à cette idée : GIGO garbage in, garbage out.
C’est compliqué d’avoir un backlog bien maintenu mais à mon avis ca vaut le coup. Car si on veut pouvoir inspecter et s’adapter il faut d’abord que ce backlog soit transparent.
J’ai mis plusieurs mois à nettoyer le backlog du produit sur lequel je travail, et oui il faut du courage pour s’y mettre et il vaut mieux s’y mettre le plus tot possible
Je me permets d’insister, mais je pense vraiment que vous mettez la charrue avant les bœufs.
Pour mener un changement, il faut une bonne raison et un objectif à atteindre.
S’il n’y a pas de problème à résoudre, il n’y a pas de raison de proposer une solution.
Du coup, vraiment, pourquoi chercher à changer l’organisation ?
Qu’est-ce qui ne fonctionne pas dans le fonctionnement actuel ?
Qu’est-ce qui ne satisfait pas et qu’on veut améliorer ?
Quels indicateurs permettent de mesurer et objectiver le fonctionnement actuel ?
Identifier le problème c’est l’avoir déjà quasiment résolu.
Quelques autres remarques :
Le fait que les différents produits soient proposés sur la même plateforme n’en fait pas forcément une fusion. C’est peut-être simplement une factorisation de certains besoins communs aux produits. Si c’est le cas, il est important de réfléchir rapidement à la manière dont les produits vont interagir avec la plateforme, et s’assurer qu’on est bien en train de factoriser un service rendu à l’équipe produits, et pas en train de revenir à une organisation traditionnelle en couches, voire pire … matricielle.
Le fait de mettre les PBI de tous les produits dans le même outil n’en fait pas une fusion. Si vous étiez face à une fusion, vous seriez dans une situation où chaque PBI sera catégorisé comme « produit = non applicable » ou « produit = global », et vous demanderiez la suppression pure et simple de l’information. Si vous pouvez catégoriser les PBI par produit, c’est ça qui fait que ce sont bien des produits.
D’autre part, c’est l’ensemble des PBI associé à un produit qui forment le backlog produit, et non pas l’outil dans lequel on les range. Au contraire, c’est toujours un enfer d’avoir les backlogs dispersés chacun dans leur outil. Avoir les PBI de tous les produits dans le même outil est certainement un gain de temps pour toute personne qui cherche à avoir une vision globale, commerciale et stratégique.
Attention toutefois à ce que l’outil soit d’abord au service des équipes produit et pas un énième reporting.
Je suis à la fois d’accord et pas d’accord avec toi.
D’accord que ce n’est pas une priorité. J’ai d’autres sujets à traiter en priorité et comme tu dis, jusqu’à là, ça fonctionne donc on peut encore laisser comme ça (pour l’instant)
Cependant, je ne suis pas d’accord de le laisser comme ça sur le longue terme. Pourquoi : parce que nous n’avons pas de vision, pas de roadmap. Pour l’instant, c’est une approche bottom up (on ajoute des US en fonction des besoins du jour / des demandes des commerciaux ou des bugs) et le fait que chacun écrite des US à sa sauce, on s’y perd. À mon avis, il faut un minimum de vision pour qu’on puisse voir clairement vers où on y va, et ça passe par un backlog ordonné, avec un management visuel associé.
Donc, c’est une changement que je souhaite pour un futur proche. Et je me questionne, du fait qu’on a plusieurs produits et 1 seule équipe, c’est mieux à faire plusieurs PB ou un seul
Et je suis la seule personne de « l’équipe Product ». Nous n’avons pas de Scrum Master, ni PO.
Tout le potentiel changement ne concerne que moi et l’équipe dev. Nous sommes une petite équipe et les choses peuvent aller très vite
L’envie de changement est aussi motivé de mon côté par la fait qu’à date, nous n’avons plus de DOR, ni DOD et certains US durent 6 mois (ça aurait pu être un epic mais la personne qui est en charge a rédigé en juste une phrase et pendant tout ce temps on ne sait pas comment le sujet avance / l’avancement est partagé oralement mais c’est écrit nul part)… Beaucoup de pratiques très différentes de ce que je connais !
C’est « l’architecture » des produits qui fait les backlogs et non l’inverse. Tant que tu associe les PBI à un produit actuel, tu auras plusieurs backlogs au sens logique. Ensuite, tout mettre dans un seul outil (par exemple un projet Jira unique) pour éviter de passer d’une liste à l’autre c’est juste du pragmatisme.
Tant que tu as un outil qui te permet de filtrer par produit, tu as le meilleure des 2 mondes :
Une vision globale de tout le travail sur tous les produits (vision stratégique)
Une liste des choses à accomplir dans le contexte d’un produit (vision tactique)
Personnellement je fais toujours la distinction entre la personne et le rôle. S’il y a plusieurs produits, ils ont chacun leur PO. Ce qui est « interdit » en Scrum c’est d’avoir plusieurs personnes sur le même rôle de PO ; mais une seule personne physique peut tout à fait tenir plusieurs rôles de PO.
Un avantage c’est que ça simplifie la coordination entre produits. La principale limite c’est la disponibilité de la personne pour les différents produits. Mais s’il n’y a pas plusieurs équipes de dev derrière, ça devrait le faire, jusqu’à ce que l’entreprise ait besoin de plus de « puissance humaine ».
Je vais faire un parallèle avec la gestion multitâche en programmation logicielle ; c’est un peu technique mais à mon avis très parlant dans ton cas. On a dû attendre 2005/2006 pour la commercialisation des premiers processeurs multicœurs grand public. Pourtant, dès les années 50 on avait besoin de permettre à un ordinateur avec un processeur monocore de réaliser plusieurs tâches « en parallèle ».
Malheureusement ce n’était pas techniquement possible de faire en sorte que les activités soient menées « vraiment en même temps », à cause de la façon dont fonctionne un processeur monocore. On a donc eu l’idée de faire du multiplexage, c’est à dire de découper les traitements en plusieurs petites tâches qu’on réalise les unes à la suite des autres, de manière tellement rapide qu’on donne l’illusion qu’elles sont réalisées en même temps.
Deux modèles ont émergé au cours de l’histoire :
Un modèle de multitâche « coopératif ». Le principe c’est que le programme qui s’exécute envoie un signal (appelé yield) au système d’exploitation pour lui dire qu’il a terminé une série d’actions et qu’il peut donner l’accès au processeur à un autre programme s’il le souhaite. Le modèle est dit coopératif car la parallélisation repose sur la coopération des programmes entre eux pour laisser du temps d’exécution aux autres. Si un logiciel ne coopère pas, il s’accapare le processeur ;
Un modèle multitâche « préemptif ». Cette fois c’est le système d’exploitation qui décide du temps alloué au traitement de chaque programme. Il peut interrompre le traitement de n’importe quel programme pour donner du temps d’exécution à un autre et éviter un monopole. On l’appelle préemptif car même si un processus veut s’accaparer le processeur, le système d’exploitation peut fait droit de préemption et accorder du temps de traitement à un autre programme. Il y a un surcoût au fait de basculer d’un programme à l’autre (appelé changement de contexte) qu’on assume pour éviter un blocage du système causé par un programme compétitif ;
Si tu as des US qui sont traitées en effet tunnel pendant 6 mois, on est clairement en multiplexage coopératif. Au début du fil, tu parles d’embrasser Kanban, à mon avis c’est une mauvaise approche dans ton contexte qui va renforcer ce phénomène. En effet, Kanban est focalisé sur la tâche, qui est considérée comme atomique. Su tu veux réduire le TTM et l’effet tunnel, il faudrait alors morceler la tâche en sous-tâches plus petites (et faire des yield plus souvent). Cependant, cela fait porter au marketing (qui rédige les US) l’effort de morcellement, alors que ce découpage se fait généralement sur le plan technique.
Au contraire, Scrum conseille une approche préemptive : on s’accorde X jours ou X semaines pour se concentrer sur une fonctionnalité. Une fois le temps écoulé, on inspecte le résultat pour décider si on réitère ou si on préempte vers une autre story. Si on a plusieurs groupes de devs qui bossent chacun sur leur fonctionnalité, on n’est plus en train de faire un scrum mais plusieurs. Et si en plus ils bossent chacun sur un produit différent, bah c’est là qu’on en arrive à se poser la question de spécialiser chaque petit groupe sur un produit et qu’on finit par avoir plusieurs équipes avec leur PO et leur backlog. C’est ce que j’appelle mitose organisationnelle.
Adopter une approche préemptive implique un changement culturel à un peu tous les étages, car il faut alors accepter de fournir aux utilisateurs une fonctionnalité utilisable au lieu d’une fonctionnalité complète. On cherche donc à ne surtout pas être exhaustif sur les tâches à accomplir, mais au contraire à en faire le moins possible, le produit minimum utilisable. L’atteinte de ce minimum doit être crédible dans la durée du sprint, y compris en cas d’aléa. Si on a le temps de faire plus, peaufiner l’esthétique, ajouter des points d’entrée supplémentaires, ajouter des fonctionnalités, on ne va pas se priver de faire mieux, bien sûr. En revanche, l’équipe doit être confiante dans son aptitude à fournir aux utilisateurs des fonctionnalités incomplètes, en gros une « beta » (mais de la fonctionnalité, pas de l’application).
Il y a des techniques pour aider à fournir des fonctionnalités incomplètes aux utilisateurs, comme:
le dark launching: seules les personnes qui savent comment y accéder le peuvent ;
les feature flags: le marketing décide qui peut y accéder, quand, et à quelle condition ;
les user toggles: les utilisateurs peuvent l’activer ou la désactiver à l’envi.
et il vaut mieux s’y mettre le plus tot possible 