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.

En ce début d'année, je vous propose de prendre un peu de hauteur en nous élevant au-dessus des nuages.

En Juillet dernier, l'aéronaute suisse Bertrand Piccard était invité à la conférence TedGlobal 2009. Dans la vidéo de sa présentation récemment publiée sur le site de TED, Piccard nous raconte son tour du monde en ballon avec Brian Jones et en tire une leçon que je trouve étonnamment en phase avec les valeurs agiles.

Dans cette discipline, explique le navigateur, s'opposer frontalement à un fort vent contraire en voulant garder la même direction coûte que coûte, c'est comme résister obstinément au changement dans la vie : cela peut rapidement devenir un cauchemar.
Comment y remédier ? En comprenant que l'atmosphère est faite de couches dans lesquelles le vent circule dans des directions diverses, et qu'il faut se servir de l'axe vertical pour naviguer entre ces couches, par exemple en lâchant du lest.
Pour Piccard, les pionniers, les découvreurs ne sont donc pas ceux qui font face avec le plus d'acharnement aux difficultés rencontrées, ni même nécessairement ceux qui ont les idées les plus nombreuses ou les plus brillantes. Ce sont avant tout ceux qui osent jeter par-dessus bord leurs convictions, leurs certitudes, leurs habitudes pour accéder à des courants qui les mèneront à ce qu'ils cherchent par des voies de navigation différentes.
On apprend que c'est aussi cet esprit précurseur et un peu utopiste qui a gouverné le prochain projet de Bertrand Piccard, Solar Impulse, un avion fonctionnant uniquement à l'énergie solaire et qui pourrait bientôt prendre son envol autour du monde.

Voici la vidéo :

Voilà, je vous souhaite donc vous aussi de pouvoir lâcher tout le lest nécessaire en cette nouvelle année afin de piloter votre ballon dans la direction de vos rêves :)

Connaissez-vous la doyenne de l'agilité ? La super mamie des itérations ? La matriarche des rétrospectives ? Non ? Et bien laissez-moi vous présenter Linda Rising.

J'aime bien Linda car en plus d'être un peu barrée, elle nous emmène dans des sujets scientifiques originaux et passionnants qui restent tout de même en rapport avec une des choses qui intéressent la bande de geeks que nous sommes : les projets informatiques.

Cette fois-ci Linda revient pour nous parler des Placebos. Pas le groupe de rock, les médicaments... Il s'avère que ces traitements (en fait des non-traitements) sont employés plus souvent qu'on ne le pense par les médecins, et que leur effet se révèle dans certains cas autant voire plus efficace que celui de médicaments classiques. Un chercheur a essayé d'en savoir plus sur cet effet difficilement explicable, et en particulier sur les gens les plus susceptibles de développer un effet placebo. Il a appelé ces personnes les "moutons" (sheep). De manière assez singulière, au fil des recherches, les moutons se sont avérés être des personnes particulièrement créatives, innovantes, curieuses, ouvertes à de nouvelles idées et expériences. En somme, les plus enclins à appliquer avec enthousiasme le célèbre adage de Fox Mulder : "I want to believe".

Linda s'est alors aperçue que ce genre de bestiole constituait, entre autres, un assez bon portrait des enthousiastes de l'agilité. Et en effet le parallèle ne parait pas usurpé : les valeurs mises en avant dans les méthodes agiles sont l'ouverture d'esprit, le désir d'expérimenter en permanence, de tester et de tirer les leçons de ses actions pour s'améliorer. En y réfléchissant bien, cela relève d'une volonté primordiale de croire en ce qu'on fait, d'avoir foi en sa propre inventivité. Si nous n'y croyions pas un petit peu, nous ne mettrions pas autant d'efforts à essayer.

Mais du coup, les méthodes agiles ne seraient-elles pas elles-mêmes des placebos ?

Les équipes agiles ne fonctionneraient-elles pas uniquement parce que leurs membres, en bons moutons, s'auto-persuadent du bien fondé de la vision et de la démarche de leur méthode préférée, et avancent ainsi de manière plus sereine, plus impliquée et donc plus productive ?

Si c'était le cas, cela remettrait-il en cause l'efficacité intrinsèque de l'agilité ?

Est-ce qu'on devrait s'en inquiéter ?

La meilleure réponse à toutes ces questions consiste peut-être à se rappeler que l'effet placebo n'est pas seulement l'apanage des cachets en sucre et autres gélules remplies de farine. Même les vrais médicaments peuvent avoir un effet placebo, certaines recherches le montrent. Dans quelle proportion cet effet rentre dans le processus de guérison, cela dépend sans doute du traitement et de la personne, et le "vrai" effet est certainement très difficile à dissocier de la part de placebo.
Mais dans bien des cas, cette part existe bel et bien, et elle n'est pas forcément négligeable...

Il y a peu, j'entendais Cécile Duflot, secrétaire nationale des Verts, parler de développement durable dans une émission. Selon elle, ce terme a été dévoyé. Agréable à l'oreille, exprimant à merveille l'idée d'un système économique plus respectueux de l'environnement, il a été repris par toutes les multinationales qui se revendiquent maintenant développement durable à l'apparition de la moindre bribe de carton recyclé dans un de leurs produits. Un exemple frappant est celui du groupe Pinault-Printemps-Redoute, qui s'est royalement offert plusieurs minutes d'auto promotion un peu usurpée dans le générique d'ouverture du film Home de Yann-Arthus Bertrand.

Depuis quelques temps, on a l'impression qu'il se passe la même chose avec les méthodes agiles. Dans les plaquettes commerciales, sur les sites Web, dans les offres d'emploi des sociétés informatiques, Agile est partout, il est devenu très tendance d'être agile même si on ne comprend pas un traitre mot à ce que cela veut dire et qu'on est la société la moins bien placée du monde pour en parler. Autre marqueur inquiétant de l'inflation du buzzword, lorsqu'on discute du sujet avec certains responsables informatiques qui n'ont pas encore "sauté le pas", ceux-ci s'excusent maintenant presque de ne pas être agiles, non pas parce qu'ils regrettent de ne pas profiter de la révolution apportée par la pratique de Scrum ou XP mais juste comme on s'excuserait de ne pas être à la page, de ne pas posséder la dernière BMW ou le dernier IPhone top tendance.

Et c'est vrai que le mot Agile sonne diablement bien, trop bien diront certains. Quelle solution adopter contre cette surexploitation qui finit par lui faire perdre tout son sens ?

Pour revenir à Cécile Duflot, elle a ensuite expliqué ce qui avait émergé en réaction à ce contexte de surmédiatisation et d'aseptisation de l'écologie. Puisque tout le monde était développement durable, être développement durable ne voulait plus dire grand-chose. C'est alors que certains écolos ont repris et donné de l'écho à l'idée de décroissance - qui existait déjà depuis fort longtemps. Le mot décroissant paraissait tellement brutal, soulevait un tel nuage d'a prioris négatifs à la fois chez le grand public et chez les acteurs économiques, qu'au moins aucune multinationale ne s'amuserait à le reprendre à son compte.
Le problème avec les visions radicales, ou dont l'appellation évoque tout de suite la radicalité, est qu'elles sont condamnées à rester cloitrées au sein de petits groupes d'activistes, et garanties ne jamais voir leurs idées se diffuser dans les moeurs. Une fois la notion de décroissance expliquée au grand public par les médias, le rejet et la méfiance n'ont donc pas tardé à apparaitre, les décroissants passant pour une bande d'illuminés - ce qui est bien résumé dans cette pub, hilarante, qui les ridiculise sans les nommer.

Vous vous en doutez, un concept similaire a fait son apparition dans le monde des méthodes agiles. Il s'agit de l'ARxTA (Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism !) proposé par Brian Marick. Il va sans dire que l'acronyme imprononçable et l'explication compliquée provoqueront des réactions mêlées d'effroi et d'assoupissement chez les interlocuteurs à qui vous parlerez de ce mouvement. C'est le but, et même si ce qui se cache derrière ces termes est passionnant et pertinent, on n'a vu jusqu'ici aucun courant marketing s'emparer du concept.
Pour autant, Brian Marick qui comptait en réalité administrer à la communauté une piqûre de rappel salutaire sur ce qu'étaient les fondements de l'agilité, n'a semble-t-il malheureusement réussi qu'à prêcher des convaincus. Son action radicale n'a pour l'heure pas vraiment fait contrepoids au dépouillement de tout sens qui semble parfois aller de pair avec le succès des méthodes agiles.

Pour conclure, je pense qu'il reste toujours à trouver un juste milieu entre mode marketée qui alimente un buzz déraisonné, et concept aride connu d'un petit cercle de nerds en chemises à carreaux. Les manifestes (agile, software craftsmanship, ARxTA...), même s'ils conviennent parfaitement à l'idée qu'il ne s'agit pas de normes mais juste de philosophies qu'on peut pratiquer au quotidien, semblent bien en peine d'éviter d'être vidés d'une partie de leur substance en même temps qu'ils deviennent "grand public". Certains affirment que la constitution d'entités plus formelles et garantes des bonnes pratiques, peut-être sous la forme de certifications, serait une solution. En tout cas, vu les récentes déclarations de l'Agile Alliance, on ne semble pas en prendre le chemin...