InfOsaurus

« The best architectures, requirements, and designs emerge from self-organizing teams. »

Cet extrait du Manifeste agile met en lumière un des points importants de la réussite d'une démarche agile : la capacité d'une équipe projet informatique à s'organiser elle-même. Mais même si la notion est connue et souvent évoquée comme qualité première d'une équipe agile, qu'entend-on précisément par auto-organisation et quelles peuvent être ses limites ?

Un phénomène émergent

Voici la définition que donne Wikipedia de l'auto-organisation dans le domaine des sciences physiques et de la systémique :

« Le terme auto-organisation fait référence à un processus dans lequel l'organisation interne d'un système, habituellement un système hors équilibre, augmente automatiquement sans être dirigée par une source extérieure. Typiquement, les systèmes auto-organisées ont des propriétés émergentes (bien que cela ne soit pas toujours le cas). »

Il est amusant de constater une certaine ressemblance avec la définition agile de l'auto-organisation, bien qu'elle recouvre d'autres réalités. L'auto-organisation n'est pas une valeur, ni une pratique ou même une compétence. Le manifeste agile la classe parmi les principes, mais on peut aussi parler de phénomène d'auto-organisation car c'est en réalité le résultat de plusieurs façons de fonctionner qui se mettent en place progressivement au sein d'une équipe :

Répartition collective des tâches. Alors que dans un système hiérarchisé traditionnel de type command and control c'est le plus souvent le chef de projet qui assigne individuellement les tâches aux développeurs, les équipes agiles se répartissent le travail de manière collective. Plus exactement, il s'agit d'une auto-attribution libre du travail avec accord tacite du collectif : le membre de l'équipe choisit lui-même sa prochaine tâche mais il le fait en présence et avec l'approbation de tous ses coéquipiers. Le moment précis pour cette attribution est celui du standup meeting / daily scrum dont la fréquence journalière permet un ajustement du partage du travail au plus près de la réalité du moment. Effet collatéral : exit les diagrammes de Gantt planifiés des semaines à l'avance ; une partie importante des prérogatives du chef de projet disparait, ce qui n'est pas sans poser problème à certains comme nous le verrons plus loin.

Engagement collectif. Dans un mode de fonctionnement agile, l'équipe s'engage auprès du client à produire au cours de l'itération suivante un certain nombre de fonctionnalités représentant une valeur métier pour ce dernier. C'est un des moments importants où l'équipe en tant que bloc solidaire prend ses responsabilités vis-à-vis de l'extérieur. Cela contraste fortement avec la gestion de projet classique où la responsabilité est plutôt individuelle, chaque développeur s'engageant à respecter l'estimation qu'il a chiffré (ou que quelqu'un d'autre a chiffré pour lui !) et des "fusibles" hiérarchiques successifs sont en place : si quelque chose dysfonctionne, c'est d'abord le chef de projet qui est responsable puis il va chercher le membre de l'équipe qui a fauté pour en tirer les conséquences.

Appropriation collective du projet. Une équipe auto-organisée se caractérise ensuite par une cohésion interne forte assortie d'une réelle prise en main des enjeux du projet, obligatoire du moment où l'équipe ne reçoit plus d'ordres extérieurs directs sur la façon de faire. Ce sentiment d'appartenance à la une même tribu, d'adhésion à une même cause est renforcé par les "rituels" agiles tels le daily standup (et qui gravitent autour du task board, comme le décrit très bien Tobias Mayer) ainsi que des pratiques comme le pair programming qui permettent de propager la connaissance du logiciel efficacement parmi les membres de l'équipe.

Amélioration collective. Ce point rejoint la deuxième partie de la définition scientifique de l'auto-organisation : "Typiquement, les systèmes auto-organisées ont des propriétés émergentes". En effet, un système auto-organisé ne naît pas avec un fonctionnement parfait, il l'adapte et l'améliore au fil du temps. En agilité, ce sont bien sûr les rétrospectives et autres dispositifs inspect & adapt qui jouent ce rôle en vue d'une évolution continue.

Les raisons du débat

Voilà pour les traits principaux d'une équipe auto-organisée, mais force est de constater que le concept est loin de faire l'unanimité parmi les acteurs de l'informatique et suscite beaucoup de réticences. Pourquoi cette subversivité alors que les méthodes agiles se veulent être de plus en plus courantes ? Je pense que cela tient essentiellement à trois raisons :

• Comme je l'ai dit plus haut, le déplacement vers l'équipe de beaucoup des prérogatives du chef de projet (pouvoir d'assigner et de planifier les tâches de développement comme bon lui semble, interface avec le client...) fait grincer des dents, en particulier chez les premiers concernés. On peut les comprendre, d'autant plus qu'en étant tout à fait honnête, il reste quand même aujourd'hui un gros flou autour de ce qui se passe une fois que la méthode a dit "le Scrum Master/coach n'est pas un chef de projet", voire "il n'y a plus de chef de projet du tout". A qui reviennent les responsabilités comme le suivi budgétaire et comptable, les aspects administratifs, les procédures internes, le recrutement... ?
  Piste intéressante : dans un récent billet, Laurent Bossavit, fondateur de l'Institut agile, fait appel à une théorie de l'économiste Ricardo sur la spécialisation du travail pour apporter un début de réponse à cette crainte. Il pose la question suivante : dans un environnement agile, est-il obligatoire de conserver des rôles personnels rigides regroupant un cortège de responsabilités bien fixées, ou s'il ne serait pas plus judicieux de les éclater en répartissant les responsabilités en fonction des compétences de chacun ?

• Deuxième crainte soulevée par l'auto-organisation : le renversement de paradigme que cela implique. Aplatissement de la hiérarchie, bouleversement des canons de l'organisation du travail et des rôles de chacun, et pas seulement à l'intérieur des équipes de développement... C'est tout le problème de la douloureuse transition d'une structure pyramidale de type command & control à un contexte agile où l'encadrement s'apparente plus à du servant leadership, ce qui touche uniquement les équipes projets dans un premier temps mais a vocation à être assez viral dans toute l'entreprise. A ce propos je vous recommande la très bonne présentation de Roman Pichler sur le changement de rôle des managers dans Scrum.

• En dernier ressort, inutile de se le cacher, l'idée d'auto-organisation déclenche chez beaucoup et surtout les anglo-saxons, par un réflexe quasi-psychologique, un rapprochement avec des concepts revendiqués par des mouvements d'extrême-gauche : pouvoir au peuple, anarchisme, libertarisme... et aussi l'auto-gestion, cousine lointaine de l'auto-organisation. La crainte implicite sous-jacente est que l'équipe devienne un électron libre, hors de contrôle de l'entreprise, ou, pire, que le rapport de contrôle s'inverse.

Le spectre de l'auto-gestion

Apparu à la fin du XIXème siècle, le concept d'auto-gestion caractérise un groupe, souvent producteur de biens ou services en petite quantité, dont le principe est justement d'être un électron libre. Les décisions se prennent exclusivement parmi ses membres qui sont en général sur un pied d'égalité. Au cours de l'histoire, l'auto-gestion a été expérimentée dans des environnements multiples : coopératives ouvrières, agricoles, jardins partagés, regroupements de salariés... Certaines entreprises d'ingénierie informatique s'y essaient même de nos jours.
Malgré le succès d'un certain nombre de ces entreprises, on retient souvent les mésententes fréquentes entre membres de l'organisme auto-géré ou l'embourbement dans des pourparlers interminables qui peuvent paralyser l'activité du groupe et faire avorter l'initiative. Souvent qualifiés d'utopistes, de doux rêveurs, les participants de ce type d'aventure n'ont malheureusement pas une grande réputation de sérieux. Et c'est précisément cela que craignent les managers : remettre un pouvoir de décision entre les mains de l'équipe ne revient-il pas à le confier à des personnes peu habituées à la responsabilité et trop nombreuses pour trancher, résultant en un "grand n'importe quoi" ? Quels que soient les termes, la question mérite d'être posée.

Dans la même mouvance sociale, il est aussi intéressant de voir que certains agilistes se définissent explicitement comme anarchistes et contribuent activement à porter les méthodes agiles à d'autres domaines que l'informatique, comme par exemple Tobias Mayer (oui, encore lui). Ils restent pourtant rares.

Pour finir

Revenons à la définition de l'auto-organisation en agilité : il est utile de noter que le manifeste agile ne s'aventure pas à la prôner en-dehors de l'équipe projet et des "architectures, requirements, and designs". Pas de volonté affichée de révolution sociale à l'échelle de l'entreprise toute entière de la part des "pères fondateurs", donc. Mais essayer de faire fonctionner le phénomène auto-organisation au niveau développement ne serait déjà pas si mal. Si davantage d'entreprises engagées dans une démarche agile faisaient preuve de confiance et de lâcher-prise vis-à-vis de leurs équipes et abandonnaient pour de bon le sacro-saint besoin de contrôle et de pilotage individuel, sans doute ferait-on un grand pas dans la réussite des projets, la qualité du logiciel livré et le bien-être des collaborateurs.