Les douze principes

Les équipes auto-organisées

Le onzième principe du Manifeste affirme que les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées. C'est l'un des principes les plus mal compris : on y lit tantôt la disparition des chefs, tantôt l'absence de tout cadre. Le texte dit autre chose, et l'article de Takeuchi et Nonaka qui a inspiré cette idée, publié en 1986, décrit avec précision le rôle que le management conserve.

Un schéma venu d'ailleurs

Un réseau de bus départemental fait développer une application qui permettra d'acheter et de valider un billet avec son téléphone. L'architecture du système est confiée à un spécialiste de la direction technique, qui suit cinq projets à la fois. Il remet un document de soixante pages. Chaque validation de billet y passe par un serveur central. L'équipe de développement reçoit le document et se réunit pour l'étudier.

« Le schéma prévoit une vérification en ligne à chaque montée, dit Nadia, une développeuse qui prend le bus tous les jours. Sur la ligne 14, il n'y a aucun réseau pendant vingt minutes. »

« Le document a été validé en comité, répond le chef de projet. Nous l'appliquons. »

Six mois plus tard, l'application échoue exactement là où Nadia l'avait prévu. Personne ne s'en estime responsable. L'architecte n'était plus là quand le système a été construit, et l'équipe a appliqué un document qu'elle n'avait pas écrit.

Dans une autre organisation, la même équipe reçoit un objectif et des contraintes : les voyageurs doivent pouvoir valider un billet partout sur le réseau, les règles de sécurité de l'entreprise s'appliquent et le budget est fixé. L'architecte travaille avec l'équipe deux jours par semaine. Le premier jour, devant le tableau, Nadia parle de la ligne 14, et la validation hors connexion entre dans la conception. L'architecte connaissait la sécurité et le système central, et Nadia connaissait le terrain. Une bonne conception avait besoin des deux, et seule l'équipe réunie les possédait.

Ce que dit le principe

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Manifeste agile, principe 11

La traduction officielle écrit « autoorganisées » en un seul mot, et l'usage courant préfère « auto-organisées ». L'auto-organisation désigne le fait, pour une équipe, de décider elle-même comment répartir et réaliser son travail afin d'atteindre un objectif qui lui est donné.

Le principe porte sur trois produits du travail intellectuel. L'architecture est la structure d'ensemble du système. Les spécifications (le texte anglais dit requirements, les exigences) sont l'expression détaillée de ce que le produit doit faire. La conception est la manière dont chaque partie est construite. Dans l'organisation classique d'un projet, ces trois activités reviennent à des spécialistes placés en amont de l'équipe, qui transmettent ensuite leurs documents. Le principe affirme que le résultat est meilleur quand il vient de l'équipe qui réalise.

Le verbe « émergent » a son importance. Il décrit des solutions qui apparaissent peu à peu, à mesure que l'équipe travaille et discute, au lieu d'être arrêtées d'avance par une personne extérieure.

Le principe ne dit rien de plus. Il n'affirme pas que l'équipe choisit ses objectifs, qu'elle n'a pas de responsable ou qu'elle fixe son budget. Ces lectures lui ont été ajoutées.

La source : Takeuchi et Nonaka, 1986

L'expression vient d'un article de Hirotaka Takeuchi et Ikujiro Nonaka, « The New New Product Development Game », paru dans la Harvard Business Review en 1986. Les deux chercheurs japonais y étudient la mise au point de six produits, parmi lesquels un photocopieur de Fuji-Xerox, une voiture de Honda, un ordinateur de NEC et deux appareils photo de Canon. Aucun n'est un logiciel.

Ils opposent deux manières de développer un produit. Dans la course de relais, chaque service de spécialistes termine sa phase et passe le témoin au suivant. Dans l'approche qu'ils comparent au rugby, une équipe réunissant tous les métiers avance d'un bloc en se passant le ballon. Ils relèvent six caractéristiques de cette seconde approche, dont deux nous intéressent ici : des équipes de projet auto-organisées et un « contrôle subtil » exercé par la direction.

Selon eux, une équipe devient capable de s'organiser elle-même quand trois conditions sont réunies. La première est l'autonomie : la direction apporte au départ une orientation, de l'argent et un soutien moral, puis intervient rarement au quotidien. La deuxième est le dépassement de soi : partie des consignes de la direction, l'équipe se fixe ses propres buts et les relève en cours de route. La troisième est la fertilisation croisée : l'équipe réunit des métiers et des personnalités différents, souvent dans une même grande salle.

La direction donne le cap, et il est exigeant. Chez Fuji-Xerox, l'équipe du photocopieur FX-3500 a reçu deux ans pour concevoir une machine qui coûterait deux fois moins cher à produire que le haut de gamme, à performances égales. La liberté laissée à l'équipe porte sur la manière d'y parvenir.

Cet article a aussi donné son nom à Scrum, le mot désignant la mêlée au rugby (voir Scrum en bref). L'idée elle-même est plus ancienne. Dès 1951, Eric Trist et Ken Bamforth, du Tavistock Institute de Londres, avaient décrit dans les mines de charbon britanniques des groupes de mineurs qui se répartissaient eux-mêmes le travail.

Ce que l'auto-organisation n'est pas

Elle n'est pas l'absence de contrôle

Takeuchi et Nonaka sont explicites : les équipes qu'ils ont observées étaient largement livrées à elles-mêmes, mais elles n'étaient pas sans contrôle. La direction posait assez de points de contrôle pour que l'incertitude ne tourne pas au chaos. Ce « contrôle subtil » passait notamment par le choix des membres de l'équipe, par un espace de travail ouvert, par l'encouragement à aller écouter les clients sur le terrain, par une évaluation fondée sur le résultat du groupe et par la tolérance aux erreurs.

Elle n'est pas l'absence de cadre

Le psychologue Richard Hackman a proposé, dans Leading Teams (2002), une grille utile. Il distingue quatre fonctions : exécuter le travail, piloter la manière de le faire, concevoir l'équipe et son environnement, et fixer la direction générale. Une équipe dirigée par un manager n'assure que la première. Une équipe autogérée assure les deux premières. Une équipe qui choisit en plus sa composition va plus loin, et seule une équipe « autogouvernée » fixe aussi ses propres buts.

Les équipes agiles se situent au deuxième niveau. Le guide Scrum de 2020 a d'ailleurs remplacé « auto-organisée » par « autogérée » (self-managing), en précisant que l'équipe décide en interne qui fait quoi, quand et comment. La répartition la plus courante est la suivante.

DécisionQui la prend le plus souvent
L'objectif du produit et l'ordre des prioritésLe commanditaire ou son représentant (le Product Owner dans Scrum)
La composition de l'équipe, le budget et les règles communes de l'entrepriseLe management
La quantité de travail que l'équipe prend pour une itération (une période de travail courte et de durée fixe)L'équipe
La répartition des tâches et la solution techniqueL'équipe
La manière de travailler et de l'améliorerL'équipe

Le rôle du management

Le management ne disparaît donc pas, et son travail change de nature. Il lui revient de donner un objectif clair et de dire pourquoi il compte. Il compose une équipe qui possède toutes les compétences nécessaires, faute de quoi elle dépendra sans cesse de l'extérieur. Il fixe les limites qui ne se discutent pas, comme les règles de sécurité ou les obligations légales. Il protège l'équipe des demandes concurrentes et des interruptions. Il traite enfin ce qui la dépasse : les désaccords entre équipes, les carrières et les salaires. Ce rôle rejoint celui que décrit le cinquième principe (voir Des personnes motivées et la confiance).

Hors du logiciel : les infirmières de Buurtzorg

Limites et pièges

Une équipe sans structure déclarée n'est pas une équipe sans pouvoir. Jo Freeman l'a décrit dans « The Tyranny of Structurelessness », un texte issu d'une conférence de 1970 sur les groupes militants : quand un groupe prétend n'avoir aucune structure, une structure informelle s'installe, et ceux qui la tiennent n'ont de comptes à rendre à personne. Dans une équipe dite auto-organisée, la décision revient alors au plus ancien ou à celui qui parle le plus fort. Des règles explicites sur la façon de décider protègent mieux les membres discrets que l'absence de règles.

L'auto-organisation ne se décrète pas davantage. Nils Brede Moe, Torgeir Dingsøyr et Tore Dybå ont suivi pendant plusieurs mois une équipe qui adoptait Scrum (étude publiée en 2010). Ils ont relevé des obstacles tenaces : des compétences très spécialisées, qui conduisaient chacun à rester dans son domaine, et des difficultés de coordination et de direction au sein de l'équipe. Ils concluent que le passage à l'équipe autogérée demande un changement d'attitude des développeurs et du management.

Le principe suppose aussi la compétence. Une équipe de débutants laissée seule ne produira pas la meilleure architecture par la seule vertu de son autonomie. Le onzième principe se lit avec le cinquième, sur le soutien, et avec le neuvième, sur l'excellence technique.

À plusieurs équipes, une autre difficulté apparaît. Chacune peut concevoir une solution cohérente pour elle-même et incompatible avec celle des voisines. La cohérence d'ensemble demande une coordination que le principe ne décrit pas (voir L'agilité à l'échelle).

Il existe par ailleurs une auto-organisation de façade. Certaines directions déclarent leurs équipes autonomes tout en leur imposant les solutions et les délais. D'autres se retirent entièrement, puis reprochent à l'équipe ses résultats.

Il faut enfin lire Takeuchi et Nonaka jusqu'au bout. Ils signalent eux-mêmes que leur approche exige un effort extraordinaire : dans l'un des projets étudiés, selon eux, les membres de l'équipe ont fait jusqu'à cent heures supplémentaires par mois pendant les périodes de pointe. Cela contredit directement le huitième principe (voir Le rythme soutenable). Ils reconnaissent aussi que l'approche convient mal à certains cas, comme les projets de très grande taille. Leur étude porte par ailleurs sur six produits d'entreprises japonaises. Le superlatif du principe, « les meilleures », exprime donc une conviction des signataires. La recherche sur les équipes autogérées donne des résultats variables selon les contextes (voir Que valent les preuves ?).

Pour aller plus loin

Sources principales : Manifeste pour le développement agile de logiciels (2001), agilemanifesto.org ; Hirotaka Takeuchi et Ikujiro Nonaka, « The New New Product Development Game », Harvard Business Review (janvier-février 1986) ; J. Richard Hackman, Leading Teams (2002) ; Eric L. Trist et Ken W. Bamforth, « Some Social and Psychological Consequences of the Longwall Method of Coal-Getting », Human Relations (1951) ; Jo Freeman, « The Tyranny of Structurelessness » (conférence de 1970, publiée en 1972) ; Nils Brede Moe, Torgeir Dingsøyr et Tore Dybå, « A teamwork model for understanding an agile team: A case study of a Scrum project », Information and Software Technology (2010) ; Ken Schwaber et Jeff Sutherland, The Scrum Guide (2020) ; Frédéric Laloux, Reinventing Organizations (2014).