InfOsaurus

Aller au contenu | Aller au menu | Aller à la recherche

mardi 5 octobre 2010

L'auto-organisation : analyse d'un concept subversif

« 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 ?

Auto-organisation 3

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.


Auto-organisation4

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.

Auto-organisation2

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.

mercredi 16 septembre 2009

L'épanouissement tribal, promesse des méthodes agiles ?

Totem

Le bonheur est à la mode. C'est un saint Graal que tout le monde, y compris notre président, cherche à toucher du doigt en ces temps difficiles. La France va mal, et il faut se doter des outils nécessaires pour mesurer et améliorer le bien-être de ses citoyens.
Les récents cas de suicides au sein d'une célèbre entreprise de télécoms témoignent plus précisément d'une zone sensible où beaucoup reste à faire en matière de bonheur et d'épanouissement personnel : l'entreprise. En effet, peu de salariés - même parmi les plus qualifiés comme les ingénieurs en développement logiciel - peuvent se vanter de s'accomplir pleinement à travers leur travail quotidien.

Quelle réponse les méthodes agiles, et Scrum en particulier, peuvent-elles apporter à ce douloureux problème ? En d'autres termes, quelle vision du bonheur en entreprise avons-nous en mettant nos lunettes Scrum, comme diraient certains ;) ?

Tobias Mayer, scrum master et coach agile, a publié le mois dernier un billet fort intéressant sur le sujet. A première vue, il semble y être question du task board, parfois plus connu sous le pseudonyme de Kanban : un objet qui, selon Tobias, est au coeur de la petite communauté formée par l'équipe de développement. On peut même comparer le task board à un lieu de culte sacré tant les fidèles se pressent aux rituels (les daily scrums) qui s'y tiennent.
Mais le constat ne s'arrête pas là. Tobias file la métaphore et dévoile que les méthodes agiles créent une organisation sociale similaire à celle d'une tribu, car elles permettent à chaque membre de l'équipe de satisfaire pleinement son besoin primaire de conversation, de débat, d'interaction. Et car la sensation d'appartenance au groupe, la formation de codes et de valeurs communes qui résultent du fonctionnement agile permettent de tirer le meilleur de chacun et contribuent à mettre en mouvement une force vitale au sein du groupe auto-organisé :

Scrum is about tribes, it is about building community. Each tribal member needs a sense of belonging, a personal quest. Whole tribes need gathering places, they need sacred objects, they need focus and they need pulse. Scrum supports that way of being. The task board, and its emergent environment provides the central life-force from which these things are born.

En somme, là où les méthodes de management de projet traditionnelles s'acharneraient à brider nos instincts par la division des troupes, par une bureaucratie implacable et l'introduction de nombreux tampons documentaires et humains empêchant la communication (l'archétype étant les collaborateurs séparés par des cubicles et ne communiquant que par fiches de suivi interposées), les méthodes agiles seraient un retour au naturel salutaire. L'agilité serait le meilleur moyen de respecter nos gènes et ainsi d'obtenir des résultats qu'aucun contremaître muni d'un fouet ou d'un dossier de spécifications de 500 pages n'atteindrait à moyen terme.

Je ne vois qu'une faille dans ce raisonnement ambitieux et brillant, et c'est aussi celle qui me fait parfois douter que les méthodes agiles prendront un jour le pouvoir sur la planète. Comment donner à tout le monde la possibilité d'appliquer l'agilité ? Comment faire du type qui assure seul la maintenance corrective d'une appli Cobol, une tribu Scrum ou XP ? Comment insuffler cette force collective à l'équipe d'intérimaires qui assure, micro-casques vissés sur les oreilles, le support technique niveau 1 d'une plateforme applicative et ne communique que par l'intermédiaire de tickets avec les gens du dessus ? Comment la batterie de développeurs chinois recopiant 3000 lignes de code à la minute peut-elle accéder à cette satisfaction professionnelle ?

L'épanouissement tribal est sans doute accessible, mais peut-être pas pour tout le monde...