Autonomie vs. Mission

Dans mon dernier article, j'ai écrit sur les compromis entre les différents objectifs d'autonomie et de direction externe au sein des équipes. J'ai reçu plusieurs retours indiquant que c'était un sujet majeur dans les entreprises, et certaines personnes voulaient en savoir plus – mais plutôt d'un point de vue produit et design que du côté développement. Le sujet est très vaste, c'est pourquoi j'ai pensé qu'il valait la peine de l'approfondir.

Voici quelques questions que je souhaite aborder :

• Que se passe-t-il si une équipe identifie une meilleure opportunité et décide de se concentrer sur un autre type de client ?
• Que se passe-t-il si une équipe ne veut pas effectuer le travail censé soutenir une grande initiative d'entreprise (par exemple, l'internationalisation du produit) ?
• Que faire si une équipe est convaincue de devoir changer de cap pour saisir les opportunités du marché mobile, alors qu'elle n'est responsable que d'une partie de l'ensemble ?
• Que faire si une équipe est convaincue de devoir adopter un autre design d'expérience utilisateur, même si cela la différencierait des autres équipes ?

Dans chacun de ces cas, l'équipe et la direction ont probablement des points de vue très différents. Beaucoup d'équipes affirment que – si on leur permet vraiment de travailler de manière autonome – elles peuvent prendre de telles décisions.

La problématique

Dans les équipes et organisations saines, on arrive généralement à un compromis entre ces deux visions en donnant à la direction le contrôle sur deux points clés du processus décisionnel. Le premier est la vision globale du produit et le second sont les objectifs business spécifiques assignés à chaque équipe.

Des problèmes peuvent toutefois survenir lorsque la direction ne formule pas ces deux points clés de manière suffisamment claire, car cela crée une zone grise où il n'est plus évident de savoir ce que l'équipe peut décider elle-même ou non.

La vision produit décrit la vue d'ensemble des clients cibles et les services que l'on souhaite offrir à chaque type de client. Cette vision produit doit soutenir la stratégie d'entreprise. Si vous avez par exemple une stratégie d'entreprise basée sur un modèle de vente low-touch (peu de contact client personnel), cela favorise un type très spécifique de vision produit. Si une équipe souhaite développer un produit qui s'écarte de cette vision et de ce modèle, il sera assez difficile de commercialiser le produit.

Les objectifs business spécifiques sont présentés aux équipes soit sous forme de KPI (Key Performance Indicators – indicateurs clés de performance) priorisés – également appelés Product Scorecards – soit sous forme d'OKR (Objectives and Key Results) qui aboutissent également à différents KPI. Si l'objectif de l'entreprise est par exemple de réduire significativement le taux de désabonnement des clients, c'est la mission de l'équipe.

Les équipes reçoivent la vision produit et les KPI de la direction, mais on ne leur dit pas comment les réaliser. C'est là que l'équipe peut travailler de manière autonome et flexible. J'aime décrire les équipes produit performantes comme des groupes de travail pour résoudre des problèmes difficiles. Réduire le taux de désabonnement peut définitivement représenter un défi majeur et il existe probablement d'innombrables façons d'atteindre cet objectif. Il en va de même pour l'augmentation de la "Customer Lifetime Value" (valeur qu'un client représente pour l'entreprise sur toute la durée de sa relation commerciale) ou la réduction des coûts d'acquisition client, etc.

Lorsque la vision produit et les KPI sont définis, la différence entre les équipes autonomes et les autres réside dans l'existence ou non d'une roadmap pour l'entreprise. Quand la direction ou les parties prenantes présentent à l'équipe une liste de fonctionnalités obligatoires sur lesquelles les clients et les parties prenantes comptent déjà fermement, l'équipe a peu de marge pour trouver la meilleure solution aux questions business sous-jacentes (sans parler des sujets vraiment fondamentaux).

Et c'est précisément pourquoi je suis si content du renouveau des OKR. Lorsqu'ils sont correctement appliqués, ils aident à réorienter cette situation de l'output (fonctionnalités sur les roadmaps) vers l'outcome (résultats business).

2 cas particuliers

Il y a deux cas particuliers qui méritent d'être mentionnés car ils sont très souvent source de stress dans les entreprises.

Le premier cas particulier concerne le design. Il ne fait aucun doute que c'est un grand avantage pour une équipe et les clients d'avoir un designer dans chaque équipe (qui prend en charge les fonctionnalités orientées client). Ces designers créent un lien vraiment étroit avec leur produit et les développeurs et sont des membres à part entière de l'équipe. De plus, ils n'essaient pas de travailler selon un modèle ressemblant à une agence de design interne. Mais comment s'assurer que les designers veulent améliorer l'expérience pour tous les utilisateurs et pas seulement pour les objectifs de leur propre équipe ? Les utilisateurs se moquent de votre structure d'équipe. Mais comment favoriser l'autonomie tout en assurant la cohérence ?

Il existe différentes méthodes pour cela – de la mise en place d'un "Design Manager" (ou Senior Designer) qui examine et valide le travail de tous les designers, jusqu'à une automatisation maximale avec des "Pattern Libraries", "Style Guides" et "Stylesheets".

En termes d'autonomie et de rapidité, je préfère l'automatisation, car l'équipe peut ainsi gérer le design (interaction et visuel) de manière relativement simple et efficace. Bien sûr, il y a occasionnellement de la "Design Debt", c'est-à-dire que nous constatons que le design doit être retravaillé, et on le fait dès qu'on a identifié le problème. J'aime cette approche car le Design Manager constitue toujours un groupe de bons designers mais n'a plus besoin d'être présent pour chaque détail lors de la revue (cela ralentit tout et sape l'autonomie).

Le deuxième cas particulier concerne les initiatives d'entreprise. Ce sont les projets qui impliquent toujours plusieurs équipes. Un cas assez fréquent est l'internationalisation. Un autre est le "Responsive Design". Un autre encore est de prendre le marché mobile au sérieux. Je pense que tu vois ce que je veux dire. Dans le meilleur des cas, ces initiatives correspondent bien aux KPI priorisés de chaque équipe et il y a souvent un objectif OKR concret pour cette initiative. Il faut toutefois être conscient qu'une initiative importante n'est pas toujours un gain évident pour chaque équipe individuelle. Pourtant, chaque équipe doit remplir sa mission, sinon l'initiative échouera. Je dis toujours aux équipes qu'il faut parfois simplement accomplir sa tâche en tant que partie du tout. Le bon côté, c'est que ces initiatives sont vraiment excellentes pour le produit et le client, donc nous pouvons au moins en être satisfaits.

Conclusion sur l'autonomie vs. la mission

Si vos équipes n'ont donc pas le sentiment d'avoir suffisamment d'autonomie, vous devez donner à chaque équipe une vision produit claire et des objectifs business sans ambiguïté et priorisés. Le contexte qu'ils contiennent constitue la mission de l'équipe. Assurez-vous que les équipes comprennent cette mission et donnez-leur autant de marge de manœuvre que possible pour pouvoir l'accomplir.

Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en français.

Créer une vision produit

=> Product Vision Canvas - Le guide pour créer ta vision produit.

Scrum Master Training

=> Deviens Scrum Master certifié chez Agile Academy !

Bien utiliser les métriques Agile

=> Quels indicateurs devrais-tu connaître en tant que Scrum Master ?