Bonjour la communauté,
J’ai 2 équipes Scrum (B2B et B2C) de 6 personnes représentant le service P&T (Product & Tech).
Nous envisageons de fusionner ces équipes avec leurs équivalents B2B et B2C du service client qui ne sont pas du tout Scrum.
Cela monterait l’effectif à 10-11 personnes max.
Qu’en pensez-vous ?
Est-ce une bonne idée ?
Avez-vous un retour d’expérience à partager ?
Merci d’avance.
Mickael
Quel est le problème que vous essayez de résoudre ?
Faire émerger 2 verticales qui seraient responsables du périmètre applicatif de bout en bout (ownership complet).
J’entends la stratégie que vous souhaitez employer, mais je ne vois toujours pas le problème que vous souhaitez résoudre. Est-ce que ce sont des problèmes logistiques ? De communication ? Hiérarchiques ?
Je me montre insistant parce que ce contexte est, comme souvent, très important.
Pour avoir un alignement des équipes et permettre d’avoir une conception produit plus ronde/complète.
Aujourd’hui on note un décalage entre les équipes P&T (Scrum) et les équipes « non Scrum » et surtout un produit qui pourrait gagner en valeur/efficacité si la sensibilité « support » était intégrée à l’équipe.
J’y vois aussi des facilités dans la partie QA.
Ok ! Je commence à percevoir un manque de communication et de clarté des enjeux de chacun.
De manière générale, plus l’équipe est grosse, moins elle est efficace dans sa communication, et on préfère s’arrêter à 7 ou 8 personnes max :
D’autre part, il faut aussi se demander si le rythme de travail de l’équipe « support » (que fait elle d’ailleurs ?) bénéficie à être calé sur celui des équipes P&T. Peut être que ces rythmes ne sont pas compatibles, et l’opération pourrait être plus néfaste que bénéfique. Y aurait-il des obstacles tel que celui ci en vu ?
Comment se passe la relation entre les 2 Po des équipes P&T et les équipes supports ?
A première vue je dirais que la fusion peut s’orienter vers un problème de focus sur l’objectif des sprints. Que ferait le support au quotidien par rapport à l’objectif défini en sprint planning ?
@Samuel_Abiassi, j’avais bien en tête les conséquences d’avoir plus de monde dans l’équipe.
C’est un des points d’attention et de discussion que j’ai soulevé avec l"équipe de management.
@nicobiot la relation est très bonne cependant il subsiste des incompréhensions sur certaines priorités des équipe P&T qui peut s’expliquer par un manque de contexte sur certains sujets et malgré des points de synchro réguliers tenus par les PO respectifs avec les manageurs des équipes supports.
Je n’ai pas toutes les réponses quant à l’organisation future au quotidien car il y a un « run » important côté service client qui pourrait rendre compliquer la mise en place de scrum.
Mais le fonctionnement actuel de l’équipe support est issu d’une organisation « historique ».
Intuitivement je serais tenter de croire (à tord ?) que dans une organisation scrum, une nouvelle façon de travailler se mettrait en place même si j’ai conscience que cela pourrait être un sacré changement pour les équipes support.
Encore une fois, sans savoir ce que fait l’équipe « support » au quotidien, c’est un peu difficile de répondre. Est-ce du service après vente ? De la correction de bug ? De l’upgrade de feature ?
onboarding de client, gestion de commande, modération, assistance utilisateur…
A la vue de ta réponse, je me dirais que ce serait une mauvaise idée d’inclure ces activités dans une équipe Scrum. L’équipe support ne tirerait d’après moi pas grand chose d’un travail en Sprint. Cependant, elle doit être partie prenante dans le design du produit, et avoir une très forte communication avec l’équipe Scrum, et le·a product owner·euse en premier lieu. Cette équipe est après tout un canal très important de récupération de feedback de l’utilisation du produit, autant dans ses bons que mauvais aspects. Si tu ne connais pas l’ouvrage Team Topologies, je t’invite à t’y intéresser, tu pourras sûrement y trouver des réponses. Un premier pas dans la bonne direction :
Ça marche je vais creuser les concepts de Team Topologies et voir comment ils pourraient s’appliquer / aider.
Je ne suis pas sure de comprendre tout le contexte mais j’ai surtout l’impression que le PO a un champ d’activité trop restreint ou une méconnaissance des métiers du service client.
Le rôle de PO est très particulier dans l’équipe scrum parce qu’il est à la charnière entre les tech et les autres services. S’il penche trop côté tech, l’équipe vit dans sa bulle sans prendre en compte les retours utilisateurs et métiers, s’il penche trop métier, il a tendance à moins bien prioriser et ça finit par désorganiser et pressuriser l’équipe tech.
J’ai l’impression que dans votre organisation le PO n’a pas (ou pas assez) ses entrées dans les services métiers. Il faut donc l’appuyer au niveau managérial, l’aider à bien comprendre le service metier et l’encourager à déjeuner avec les gens du métier pour qu’il ait ses entrées, les infos utiles et les enjeux des autres services pour pouvoir apporter des solutions qui conviennent à tous. C’est un rôle très relationnel, qui demande du réseau en interne et de l’expérience.
A mon sens, s’il y a rapprochement des équipes (pas sûr que ce soit nécessaire), ce serait surtout pour permettre au PO de rentrer dans le service client s’il y a un blocage managérial à ce niveau. Mais attention, plus l’équipe est grosse, plus c’est compliqué de communiquer et plus le PO est surchargé.
Merci @ALO pour ton retour.
Les PO ont bien leurs entrées au service client.
Pas de soucis de ce côté là.
En creusant le sujet j’ai l’impression qu’il y aurait un intérêt à ce que l’équipe « customer » adopte scrum afin d’avoir plus « d’atomes crochus » avec P&T.
Un peu comme ce que est décrit dans ce case study et cet article
Cela permettrait de conserver des équipes avec un nombre de personnes réduit évitant les soucis de communication mentionnés @Samuel_Abiassi.
Est-que le nombre sera de taille d’échange et interaction « raisonnable » ? ( max 12)
Est-ce que ça sera bien une équipe et pas juste un groupe d’individu.
Une équipe, c’est un « organisme vivant atomique, composé de plusieurs humains » qui agit dans le même but, avec les mêmes valeurs.
Un groupe, c’est un "ensemble d’individus qui cohabitent, collaborent, du latin « travailler ensemble ».
Donc la question n’est pas « ce qu’ils vont faire » mais bien "est-ce qu’ils arriveront à le faire en tant qu’équipe et pas en tant que groupe.
L’'équipe agit comem un corp humain, le bras, pied, le coeur, le cerveau, le ventre, … tous avec leur spécificité agissent dans un but commun.
Si je modifie l’équipe, c’est comme modifier le corps humain. Une greffe ça peut prendre, ça peut provoquer un rejet.
Généralement, on greffe un organe à la fois. Greffer un bassin à un tronc, c’est plus osé…
Mais comme en médecine humaine, si aujourd’hui les greffes, ça marche… C’est parce qu’un jour quelqu’un a essayé
