Autonomie vs. Hétéronomie

Pratiquement toutes les grandes entreprises technologiques ont désormais adopté le modèle d'équipes produit autonomes, engagées, pluridisciplinaires et collaboratives – et je pense que c'est une bonne chose. On voit rarement encore des entreprises utiliser les anciens modèles (principalement le modèle de pool). Cependant, trouver le bon équilibre entre autonomie et directives imposées n'est pas toujours simple.

Les résultats parlent d'eux-mêmes, mais j'attribue la plupart des avantages à la motivation accrue et au véritable sentiment d'appropriation qui émerge lorsque les équipes ont l'impression de pouvoir décider elles-mêmes de leur travail.

Même si les responsables d'équipe me disent généralement que leurs équipes sont autonomes et auto-organisées, de nombreux membres d'équipe voient les choses différemment. Quand c'est le cas, j'essaie de comprendre ce que l'équipe ne peut pas décider seule ou ce qui la fait se sentir limitée.

Où se situe la frontière entre autonomie et directives imposées ?

La plupart du temps, cela se résume à l'une des deux réponses suivantes :

Soit l'équipe ne bénéficie pas encore pleinement de la confiance de la direction, et celle-ci ne veut donc pas vraiment lui laisser carte blanche.

Soit l'équipe souhaite changer quelque chose que la direction considère comme faisant partie des fondamentaux.

Fondamentalement, toutes les équipes s'accorderaient à dire qu'il existe certaines choses qu'elles peuvent décider librement, et d'autres domaines qui font partie des prérequis communs à toutes les équipes.

Un exemple

Dans ce dernier cas, il serait par exemple très inhabituel que chaque équipe choisisse son propre outil de gestion de versions. Si l'équipe de développement a défini GitHub comme standard, cela est généralement considéré comme faisant partie des prérequis fondamentaux. Même si une équipe préférait fortement un autre outil, les coûts dépasseraient largement les avantages pour l'entreprise.

Cet exemple est assez évident, mais il en existe beaucoup d'autres où ce n'est pas aussi clair.

Chaque équipe devrait-elle par exemple pouvoir aborder l'automatisation des tests à sa façon ? Les équipes devraient-elles pouvoir choisir individuellement leur langage de programmation ? Et le framework pour les interfaces utilisateur ? La compatibilité navigateur ? Les fonctionnalités coûteuses comme le « support hors ligne » ? Devraient-elles pouvoir décider elles-mêmes de leur degré d'« agilité » ? Et chaque équipe doit-elle vraiment être impliquée dans plusieurs initiatives produit de l'entreprise ?

Comme c'est souvent le cas avec les produits, tout se résume finalement à un compromis – dans ce cas, un compromis entre autonomie et respect des fondamentaux établis.

Même si je soutiens fortement le principe des équipes autonomes et indépendantes, j'avoue être aussi un grand partisan d'investir dans de bons fondamentaux. Avec une base solide et commune, les équipes peuvent créer des produits et des expériences exceptionnels beaucoup plus rapidement.

Je voudrais approfondir ce compromis. Mais je tiens aussi à souligner que je ne prétends pas qu'il n'existe qu'une seule réponse à cette question – cela peut varier selon chaque entreprise et chaque équipe. Tout dépend de différents facteurs que je vais expliquer ici :

Points à prendre en compte :

– La compétence de l'équipe :

Il existe globalement trois situations différentes :

Équipe A – une équipe expérimentée composée de personnes intelligentes et créatives, à qui on peut faire entièrement confiance pour prendre de bonnes décisions.

Équipe B – ces personnes ont les bonnes intentions mais dans de nombreux cas n'ont pas encore l'expérience nécessaire pour prendre de bonnes décisions, elles ont donc encore besoin d'un peu d'accompagnement.

Équipe C – une équipe junior qui ne sait peut-être même pas ce qu'elle ignore. Sans un encadrement intensif, ces équipes peuvent involontairement créer de gros problèmes.

– La rapidité :

L'un des principaux arguments en faveur des directives établies est la vitesse. La logique veut que les équipes puissent s'appuyer sur le travail de leurs collègues pour ne pas perdre de temps à réinventer la roue. Cependant, dans certains cas, il est généralement accepté de permettre aux équipes de travailler plus lentement et éventuellement de faire des doublons si cela favorise leur autonomie. Parfois, respecter les directives est essentiel pour l'entreprise.

– L'importance de l'intégration :

Dans certaines entreprises, le portefeuille se compose de produits apparentés mais largement indépendants, où l'intégration et les directives ne sont pas particulièrement importantes. Dans d'autres, le portefeuille concerne des produits fortement intégrés où certaines directives communes sont indispensables. Au final, tout dépend de si une équipe doit se concentrer sur une solution unique et spécifique ou trouver une solution optimale pour l'ensemble de l'entreprise.

– La source d'innovation :

Si les principales sources d'innovations futures se trouvent déjà dans les fondamentaux, les équipes devraient avoir plus de liberté pour repenser ces éléments fondamentaux. Cependant, si les origines de l'innovation se situent au niveau des solutions, l'équipe devrait moins se concentrer sur les fondamentaux et davantage sur les innovations créatives au niveau applicatif.

– Taille et implantation de l'entreprise :

L'autonomie devient souvent difficile lorsque des problèmes de mise à l'échelle surviennent. Quand les entreprises grandissent et que leurs équipes sont réparties sur différents sites, il devient plus difficile mais aussi plus important d'établir certaines directives fondamentales. Certaines entreprises tentent de résoudre ce problème avec le concept de « Centre d'Excellence », où l'on rassemble une équipe travaillant ensemble sur une tâche en un lieu précis. D'autres essaient avec des rôles plus transversaux. Et d'autres encore ajoutent des processus.

– La culture d'entreprise :

La culture d'équipe joue également un rôle important dans le rapport entre autonomie et directives imposées. Plus une entreprise impose de directives, plus les équipes ont le sentiment d'être limitées dans leur autonomie. Pour les équipes B et C, cela peut encore être acceptable, mais pour les équipes A, c'est déjà plus problématique.

– La maturité technologique :

Vouloir établir trop tôt une base commune pour tous est un problème fréquent. Si la base n'est pas encore mature, elle ne peut pas offrir le soutien pour lequel elle était prévue. Insister trop sur le respect des directives avant que les fondamentaux ne soient vraiment prêts peut vraiment nuire aux équipes qui doivent s'appuyer dessus. C'est comme vouloir construire quelque chose sur un château de cartes instable.

– L'importance commerciale :

Si nous partons du principe que la base est solide, il y a plus de risques avec une équipe qui n'utilise pas ces fondamentaux. Dans certains cas, ce n'est pas grave. Mais quand il s'agit de produits ou d'initiatives cruciales pour l'entreprise, il faut bien réfléchir à ce sur quoi se concentrer.

– Le degré de responsabilité :

Un autre facteur est le degré de responsabilité qui accompagne l'autodétermination et l'indépendance. Si les équipes n'ont pas de responsabilité propre – et surtout s'il n'y a pas d'équipes A solides – elles n'ont pas de véritable raison d'accorder une attention particulière à ce compromis. Or, on veut que les équipes réfléchissent à ce compromis. Quand je sais qu'une équipe est forte et pleinement consciente des risques et des conséquences, et qu'elle souhaite néanmoins ignorer ou remplacer un élément essentiel des fondamentaux, alors je soutiens les membres de l'équipe dans cette décision.

Résumé

Comme tu le vois, il y a de nombreux points à prendre en compte. À mon avis, la plupart des équipes sont cependant très raisonnables lorsqu'on aborde ces sujets ouvertement. Parfois, quelques questions fondamentales sur les impacts suffisent à aider l'équipe à prendre de meilleures décisions concernant ce compromis.

Cependant, si les équipes prennent constamment de mauvaises décisions à ce sujet, tu devrais reconsidérer le niveau d'expérience de l'équipe et peut-être investir plus de temps pour t'assurer que les membres de l'équipe comprennent vraiment tous les enjeux commerciaux.

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