Episode 1 : Est-il toujours possible de mettre en place une équipe produit ?

La mise en place d’une approche produit est généralement réalisée pour les équipes de développement logiciel. Lors d’un accompagnement agile pour transformer une équipe de développement en une équipe produit, on se concentre sur la typologie de l’équipe et le périmètre technique de la solution logicielle. « Team topologies » propose différentes formes d’équipes qui peuvent devenir des équipes produits, comme les équipes « feature team », « component team », « subsystem team » ou des « enabling team ». Les équipes doivent répondre à certains critères pour être considérées comme des équipes produits. Les frameworks d’agilité à l’échelle, tels que Safe, Nexus, Less, DAD, Unfix, Scrum of scrum, peuvent également être utilisés pour mettre en place ces équipes produits. Il est important que les équipes répondent aux critères nécessaires. Il y a toutefois des organisations IT ou non-IT et sans équipes de développement logiciel.

Ces différents critères sont comme de bons ingrédients à avoir pour faire un bon plat. Comment faire pour avoir un bon plat si un ingrédient manque !

Quelles sont les conditions nécessaires pour obtenir des équipes produits ? Quels bénéfices en résultent ? Que faire lorsque ces conditions ne sont pas réunies ? Ces questions se posent lors de la mise en place d’équipes produits dans une organisation en transformation.

Pour tous ceux familiers au concept de l’équipe produit je vous invite à vous rendre directement au chapitre qui traite des difficultés et des solutions de contournement.

Rappel de définitions possibles d’un Produit

Un produit peut être défini de différentes manières en fonction du contexte. De manière générale, il s’agit d’un bien ou d’un service offert sur le marché pour satisfaire un besoin ou une demande des consommateurs (clients ou utilisateurs finaux). Quelques définitions plus détaillées selon le contexte :

Dans le contexte commercial : Un produit est un bien matériel fabriqué en vue d’être vendu. Il peut également désigner un service, une idée ou une expérience offerte sur le marché.
Dans le contexte du développement logiciel : Un produit peut être un logiciel, une application ou une solution informatique. Il peut inclure des fonctionnalités, des services.
Dans le contexte du marketing : Un produit peut être considéré comme une offre complète comprenant des caractéristiques tangibles (caractéristiques physiques) et intangibles (services associés).

Un produit est le résultat d’une production ou d’une activité réalisée par une équipe. Il est fabriqué dans un but précis et utilisé selon les besoins des utilisateurs. La complexité du produit peut nécessiter la mobilisation de plusieurs équipes. Les enjeux, objectifs et critères de succès déterminent les priorités des fonctionnalités pour les utilisateurs. D’autres facteurs tels que les risques techniques, les risques commerciaux, l’innovation, la connaissance des utilisateurs et les nouveaux marchés peuvent également influencer ces priorités. Pour obtenir un produit de qualité, il est important de fournir des fonctionnalités utiles et utilisables aux utilisateurs.

L’équipe produit

Une équipe produit est un collectif d’experts travaillant ensemble pour concevoir, développer et améliorer un produit tout au long de son cycle de vie. Elle est généralement pluridisciplinaire et rassemble les expertises nécessaires pour couvrir toutes les activités liées au produit. Les trois rôles clés au sein d’une équipe produit sont le Product Owner, le Tech-lead et les Développeurs. Le Product Owner est responsable de la vision globale du produit, le Tech-lead est le référent technique et de la qualité technique de l’équipe, et les Développeurs sont responsables de la réalisation du produit.

Conditions de mise en place d’une équipe produit

Les ingrédients nécessaires à une équipe produit sont :

Un travail préalable à la phase de réalisation, à minima un pré-cadrage, et au mieux un cadrage (pré-cadrage et cadrage feront l’objet d’un article ultérieur):
1. Qualifier les utilisateurs et leurs besoins et leurs difficultés avant arrivée du produit,
2. Définir les objectifs à atteindre, les critères de succès et les indicateurs de mesure qui jalonneront la vie du produit,
3. L’identification de toutes les expertises nécessaires au sein de l’équipe,
4. Identifier toutes les équipes en dépendances dans le cadre des activités de réalisation,
5. Tous les sujets technologiques (dont les risques) ont été identifiés,
6. Avoir pu définir son organisation d’équipe.
La mise en place d’un rôle de Product Owner légitime vis-à-vis de l’organisation (direction, managers, clients internes qui expriment des besoins, …). Il est légitime pour agir sur :
1. Les activités avant la réalisation pour faire émerger et exprimer des besoins qui ont le plus de valeur et prioriser leur réalisation avec l’équipe. Il s’assure que ces besoins soient compréhensibles pour l’équipe pour réaliser la meilleure solution.
2. Se mettre à disposition de ceux qui réalisent pour clarifier les incompréhensions des équipiers sur les besoins exprimés et aussi, identifier ce qui ne pourra pas être terminé et le déprioriser.
3. S’assurer de montrer aux clients ou utilisateurs les fonctionnalités terminées régulièrement et recueillir des feedbacks. Cela passe aussi par la mise à jour régulière des informations qui factualisent l’avancement du delivery et des résultats à atteindre pour le produit.
4. Ce rôle doit être occupé à 100% par la personne qui opère ces activités-là en raison de la densité des activités à réaliser.
La mise en place du rôle de tech-lead avec pour principales responsabilités :
1. Garant de la qualité du delivery (pratiques de qualité de développement, pratiques de binôme, …).
2. S’assure de l’onboarding des nouveaux équipiers sur les activités technologiques ainsi que la continuité d’activité du delivery des équipiers.
3. S’assure de la pluridisciplinarité en mettant en œuvre les pratiques qui font monter en compétences les équipiers.
4. Suit et utilise des indicateurs de qualités techniques (cf. indicateurs accelerate : taux de débit ou de rétablissement).
Le périmètre des fonctionnalités de la solution technique ou de composants techniques est clairement identifié (clients, consommateurs, équipes de dév, collaborateurs, recrutés, …).
L’équipe est autonome sur son périmètre de la solution technique.
Lorsqu’il y a plusieurs solutions techniques et/ou plusieurs technologies utilisées, cela doit correspondre à une solution commune auprès des utilisateurs.
Des responsabilités BUILD et RUN de la solution technique.

Les apports de valeur d’une équipe en mode produit !

Ils sont au-delà de l’équipe elle-même, et voici quelques perspectives possibles :

Pour les utilisateurs finaux, une réduction du gaspillage et une meilleure adhésion à la solution proposée qui se traduit par :
1. Focus sur la valeur ou faire des choses utiles pour eux.
2. Focus sur l’impact et leurs satisfactions plutôt que la quantité de delivery réalisée.
Pour l’organisation :
1. Une meilleure gestion des risques et des incertitudes rencontrées par l’équipe.
2. Une réduction des dépendances entre équipes produits.
3. Un focus accru sur les résultats et la possibilité de décider d’arrêter le delivery lorsqu’on a atteint soit les critères de succès soit suffisamment de résultats.
4. Les discussions directes entre une gouvernance produit et un product owner, qui porte la vision de son produit, permet une prise de décision rapide et efficace (continuer, arrêter ou démarrer) sur la base d’informations factuelles. De plus, l’organisation peut envisager la stratégie moyen et long terme produit et technologique.
5. Les rôles de product owner, tech-lead introduit dans l’organisation (fiche de rôle ou poste) offrent des perspectives d’évolution et de responsabilisation pour les collaborateurs qui peuvent s’épanouir. Cela rend attractif et attire de nouveaux talents.
6. A travers une organisation produit, l’organisation peut développer de nouveaux rôles d’experts (product manager, CPO, CTO, VP engineering, …). L’organisation produit réaligne les enjeux de l’organisation avec le sens de chacune des équipes. De plus, cela concourra aussi à la promesse de parcours carrière pour les product owners ou tech-lead.
7. Recentrer les efforts des managers et la direction sur les aspects opérationnels et RH à forte valeur ajoutée plutôt que contrôler voir micro-contrôler. Cela permet de renforcer la confiance dans la relation manager / collaborateur. Parfois, voyons nous des initiatives d’innovations managériale ou RH et centré sur une approche collaborateur-centric.
Pour la phase de réalisation ou de delivery : le product owner a cette obsession de recueillir un besoin qui a de la “valeur” et développe l’expertise d’une rédaction d’une demande de la meilleure qualité possible. Il n’est pas focus documentation coute que coute, son attention porte en permanence sur mon besoin est-il de valeur et compréhensible par les équipiers. Cela le rend stratège de la priorisation.
La collaboration avec les demandeurs internes à l’organisation permet d’accroître confiance et relation paritaire. C’est souvent l’opportunité de renforcer les liens entre les métiers et l’IT et sortir des relations clients / fournisseurs si douloureuses.
Et, pour l’équipe produit :
1. Du sens, une motivation accrue et un engagement parce que tous les équipiers savent pourquoi ils réalisent.
2. L’amélioration continue est amplifiée, et parfois l’erreur est encouragée pour favoriser une prise d’initiative dès lors qu’elle se retrouve au cœur des pratiques d’amélioration continue.

Difficultés dans la mise en place d’une équipe produit

Différents évènements ou facteurs peuvent entraver la réussite quant à la mise en place d’une équipe produit :

La gestion des priorités : lorsque plusieurs demandes sont en concurrence dans la réalisation et que les critères de priorisation se basent sur des critères peu clairs (ex: le premier servi est le premier arrivé ou celui qui crie le plus fort ou bien celui qui a le plus de pouvoir, …),
Les compétences nécessaires : il n’est pas toujours aisé d’avoir toutes les compétences dans l’équipe sans parfois revoir ou challenger l’organisation établie. Cela à pour première conséquence des expertises en dehors de l’équipe entraînant des dépendances,
La mesure des résultats : les habitudes de suivre l’avancement du delivery et avoir trop longtemps oublié de regarder les résultats que l’on souhaitait atteindre, rend difficile la mise en place des indicateurs de résultats. C’est un défi de mesurer le succès du produit ou si il faut arrêter de continuer le delivery,
La résistance au changement
1. au sein de l’équipe dans la mise en place des nouvelles méthodes de travail,
2. autour de l’équipe avec des managers en contradiction : ils doivent encouragés tout en n’étant pas convaincu,
3. Au-delà de l’équipe lorsque les modes de fonctionnement ou de décision sont contradictoires au fonctionnement de l’équipe
L’évolution de processus nécessaires au bon fonctionnement de l’équipe (gestion de la demande, gestion d’entrants, …). Il s’agit parfois d’ajustements assez importants dans l’organisation qui peuvent entraîner une forte résistance au changement,
La communication entre l’équipe et les clients ou utilisateurs : il n’est pas toujours facile pour le Product Owner de cette équipe d’avoir accès au client ou mieux aux utilisateurs. Un accès qui lui permettrait de challenger les besoins par la valeur. Cette communication, dès lors qu’elle prend la forme de spécifications détaillées en amont, d’emails, de processus de validation de besoins, …, favorise les quiproquos et les malentendus et sont souvent générateurs de difficultés attribuées au nouveau mode d’organisation de l’équipe.
La gestion des talents ou l’attractivité : retrouver, embaucher et retenir les talents nécessaires peut être un défi, surtout dans des domaines compétitifs et d’autant plus lorsque l’organisation n’est pas congruente dans ce qu’elle demande aux équipes pour devenir une équipe produit et comment elle agit vis-à-vis de l’équipe.

Retour d’expériences sur cette mise en place dans l’environnement OPS

Pour des zones de l’organisation ou des organisations qui ne font pas de développement logiciel, les critères nécessaires à la mise en place n’existent pas forcément. Par exemple, dans l’univers des OPS (infrastructure, production, …), ces critères ne sont pas toujours accessibles pour les équipes. En effet, nous constatons souvent que ces équipes ont généralement une multitude d’activités qui ne permettent pas de les regrouper autour d’un “produit”. Une difficulté majeure est l’impossibilité de toucher à l’organisation lorsqu’elle est organisée autour de silos métiers.

Une autre difficulté, plutôt une conséquence de la mise en œuvre d’”équipe produit” est le focus par l’organisation sur la notion de produit au détriment de la composante “tech”. Trop souvent on observe des carences sur la prise en compte de toutes les pratiques de qualités tech mais aussi les réflexions de la vision tech à moyen et long terme avec des exigences de durabilité ou d’éco-conception.

Des premières pistes pour contourner les difficultés de mise en place

Pour préparer le terrain de la mise en place de ces équipes, cela suppose un travail sur la principale difficulté : les résistances au changement. Parmi celles-ci, la principale est la résistance du sponsorship (capacité à décider, à être convaincu ou concerné par cette mise en œuvre) que sont le DG et son comité exécutif. Tout d’abord, pour les embarquer, nous avons testé par le passé 3 activités :

L’acculturation, présentation au format court d’une heure, orienté sur les bénéfices et les prérequis au niveau de l’organisation en étant centré sur les bénéfices. Cela nécessite d’itérer plusieurs fois pour être en mesure d’approfondir et d’échanger. Cette activité nous a permis d’enclencher une continuité dans l’approfondissement du sujet de la transformation agile de l’organisation.
Un séminaire, au vert, d’une journée en dehors d’une activité survoltée. Ce type de séminaire est propice pour approfondir les échanges sur les impacts, les bénéfices et les efforts de mise en œuvre d’équipes produit. Dans notre cas, nous avons aussi effectué un travail collectif de l’Ex-Co autour d’une pratique de rétrospective après avoir préalablement échangé sur ce besoin là compte tenu de leurs difficultés. Cette journée de séminaire nous a permis :
1. Ancrer pour de bon les notions de la culture produit auprès de chacun et déclencheur du lancement d’une initiative auprès de projets stratégiques de l’entreprise à accompagner
2. Demander à expérimenter pour eux-même comment leur Ex-Co pourrait s’inspirer de pratiques agiles pour rendre plus efficient leur Ex-Co. La co-construction d’un nouvel Ex-Co a mis en place le DG comme PO qui priorise les sujets du backlog qui seront abordés, informés ou décidés. Des affinages préalables entre membres de l’Ex-Co. Toutes ces pratiques en amont du PO de l’équipe produit futur leur a permis de mieux toucher du doigt les bénéfices. Ce fut un moyen de fabriquer nos sponsors sur qui s’appuyer. Sponsor et ambassadeur, ils ont tous eu un impact dans leur direction et auprès de leurs collaborateurs-managers. De plus, tous convaincus maintenant, ils en témoignent encore récemment lors d’événements d’entreprise. Récemment le DG et des membres de l’Ex-Co ont souligné l’importance de la rétrospective en tant qu’événement essentiel pour l’équipe et encouragé toutes les équipes à la mettre en place. L’amélioration continue est au cœur de l’agilité et de l’équipe produit.
Le coaching individuel de leader d’une direction ou d’un écosystème souhaitant se transformer et mettre en œuvre des équipes produits. Nous avons fait cela à 2 reprises :
1. Le leader d’une direction (groupe média) se transformant selon les principes de la culture produit. L’alliance nous a permis d’être partenaire, de déjouer toutes les résistances fortes de tous ses managers à la mise en place des fiches de poste de Product Owner, CTO et CPO ainsi que l’identification des bonnes personnes à ces postes. Aujourd’hui, ce leader est reconnu comme un ambassadeur dans le groupe et est sollicité auprès des directions souhaitant se transformer.
2. Le leader d’une digital factory (groupe retail français) avec qui nous avons défini le Target Operating Model et l’avons déployé. Dans ce cas là, transformer le leader a permis qu’il se sente concerné plutôt que d’attendre d’avoir des équipes produits en place.

Concernant les résistances au changement des équipiers et des managers nous avons testé différentes activités :

Mettre en place un dispositif de formations adaptées aux différents niveaux hiérarchiques (influenceurs) avant d’implémenter des changements au sein des équipes. Ce dispositif a pris en compte le contexte et a favorisé compréhension et adhésion des participants. Le langage commun a été l’opportunité de conditions favorables établies pour l’accompagnement dans un second temps.
Un accompagnement d’équipes avec un contrat de coaching clair. Le contrat de coaching établit dès le départ ce qu’on fait. Ce discours de vérité vis-à-vis de l’équipe et du management permet de poser cadre et alliance dans cette mise en œuvre. Nous anticipons les risques et les adaptations de l’accompagnement à réaliser.

Concernant les difficultés rencontrées dans la mise en œuvre d’équipe produit car les pré requis n’étaient pas là, nous avons testé récemment la mise en place d’équipe centrée sur l’impact. Dans l’univers des OPS, lors d’une mission de transformation d’une organisation, quasiment aucune équipe ne pouvait prétendre à devenir une équipe produit. Nous développerons au cours d’un nouvel article, l’épisode 2, ce que nous entendons par équipe centrée sur l’impact versus l’ébauche d’un nouveau framework d’équipe impact qui aurait aussi été intéressant de déployer dès le départ.

Concernant la difficulté de mettre en œuvre la mesure des résultats, nous nous sommes appuyés récemment sur un DG et l’Ex-Co totalement embarqués pour co-construire avec eux à la fois un nouveau support de pilotage et les différents “indicateurs produits” demandés. Ce support a d’abord été déployé et demandé aux Products Owner pour des sujets stratégiques suivis par l’Ex-Co avant de devenir le support demandé à toutes les équipes transformées.

Une priorisation légitimée et réalisée par le Product Owner reste une difficulté. Pour cela nous avons mis en place des ateliers de délégations des activités que le PO doit faire versus la chaîne managériale. Nous nous sommes appuyés sur une chaîne managériale prise en étau par un Ex-Co le demandant et des coachs agiles le prônant.

Que ce soit les processus type gestion de la demande (pré-cadrage, cadrage, delivery, ROI) ou les briques d’agilités à l’échelle utiles et nécessaires pour la réussite à la mise en oeuvre d’équipe produit mais difficile à mettre en oeuvre dans une organisation, nous avons testé la mise en place d’un nouveau dispositif d’accompagnement se basant sur des binômes de coach agile orga et des coach scrum master. Ce type de dispositif nous a permis d’intégrer les CoDirs de directions et obtenir la décision pour lancer une expérimentation de type gestion de la demande sur une sous-direction de 100 personnes. Cette expérimentation sur-mesure et co-construite a été fortement appréciée et le processus en place répond au-delà des attentes comme témoigné par le directeur et son CoDir après 3 mois d’utilisation.

Conclusion et take-away

On se focalise souvent sur la mise en œuvre d’équipes produits dans les organisations comme étant la meilleure façon de répondre aux enjeux de celle-ci (TTM, qualité, efficacité organisationnelle, etc…). Mais il n’est pas toujours possible de mettre en place cela. L’univers OPS comme d’autres environnements ne le permettent pas, comme on a pu le constater chez de nombreux clients.

Dans ce 1er épisode, nous questionnons l’excellence du plat sans toutefois avoir tous les ingrédients nécessaires à la recette. On verra dans le second épisode qu’il est possible de concocter un excellent plat malgré tout et pourquoi pas meilleur !

Dans le prochain épisode, nous vous proposons d’aborder la façon de mettre en place une “équipe impact” lorsque nous ne pouvons pas mettre en place une équipe produit. Nous aborderons aussi que cela peut être le moyen d’esquisser les prérequis nécessaires à l’arrivée de l’IA et peut-être nous amener vers des méthodes “beyond agility”.

A venir prochainement les épisodes suivants :

Manager par l’impact,
Pilotage par l’impact,
Pré-cadrage et cadrage impact,
Focus sur vision canevas par l’impact versus vision canevas produit,
Gestion de la demande par l’impact,
Accompagnement par l’impact,
Évaluer l’impact (performance d’un product owner, d’un tech-lead, d’une équipe, …),
GenIA et culture de l’impact,

Retrouvez-nous prochainement.

***