InfOsaurus

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

Méthodes et Entreprise

Réflexions sur les méthodes agiles, ou comment les nouvelles façons de créer des logiciels peuvent révolutionner le monde du travail.

Fil des billets - Fil des commentaires

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.

vendredi 30 octobre 2009

Agile Tour Bordeaux 2009

Agile Tour 2009 Bordeaux

Jeudi 29 Octobre 2009, l'Agile Tour faisait étape à Bordeaux, au LaBRI. J'étais de la partie et ma foi, le bilan est plus que réjouissant. Au cours de la journée, les 150 participants ont pu apprécier :

  • Des petites viennoiseries et du café pour bien entamer la journée.
  • L'accueil des gentils organisateurs aux brassards roses très seyants ;-)

Mais surtout,

  • Une foule de présentations et ateliers intéressants et instructifs... on aurait parfois aimé pouvoir se dédoubler pour être dans plusieurs salles à la fois.

Du côté des coups de coeur, j'ai été bluffé par le retour d'expérience Scrum de Philippe Launay de la société Agfa. Réussir à introduire l'agilité dans un projet avec des équipes multi-localisées sur plusieurs pays, des milliers d'utilisateurs, un périmètre tentaculaire et en partant avec de sévères handicaps techniques et organisationnels relève du tour de force. L'amélioration continue des équipes permise par la méthode est assez spectaculaire, et les leçons à en tirer très instructives.


Badge Agile Tour

J'ai cependant regretté :

  • Ne pas avoir pu participer à la session TDD donnée par C. Couillard et J-B Dusseaut tellement c'était blindé de monde...
  • Certains ateliers alléchants (dont le "bateau ivre" animé entre autres par Raphaël Pierquin) très limités en nombre de places. Dommage, mais je n'ai pas perdu au change avec le retour d'expérience de Philippe Launay.
  • Un vidéoprojecteur rebelle a décidé de saboter la présentation "Contractualisation agile" qui du coup a pris du plomb dans l'aile malgré toute la bonne volonté de l'orateur...


Le mot de la fin

Au final, cet Agile Tour fut pour moi très instructif et enrichissant. Bravo aux organisateurs qui ont su rassembler autant de talents et favoriser rencontres et échanges d'expériences tout au long de cette journée très réussie !

mardi 27 octobre 2009

Tous des moutons ! Peut-être, et alors ?

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".


Bande de curieux

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...

mercredi 30 septembre 2009

Formation Scrum Master par Pyxis

Formation Scrum Master Pyxis

Il y a quelques jours, j'ai eu la chance de suivre la formation Certified Scrum Master donnée par François Beauregard, fondateur de la société Pyxis. Le tout se déroulait dans un bel endroit, le Centre culturel canadien situé à deux pas des Invalides.

Au programme de ces deux jours très remplis, théorie (rôles, cérémonies, artefacts, 4 piliers de Scrum), bonnes pratiques, ateliers, séances de questions/réponses avec le formateur... Du forfait agile au sprint zéro en passant par les équipes distribuées, de multiples débats ont été soulevés. J'en aborderai peut-être quelques uns ici.

Au-delà de l'aspect formation certifiante (que François a d'ailleurs beaucoup mitigé), je suis surtout reparti tel un gamin après une récréation fructueuse, avec un sac de billes Scrum bien rempli !

Centre culturel canadien La salle de formation Atelier Product Backlog Atelier Product Backlog Les post-its de clôture

mardi 22 septembre 2009

Agilité et développement durable, victimes de leur trop bel emballage ?

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.

Packaging

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...

samedi 19 septembre 2009

Le mouton noir des pratiques d'ingéniérie

Un mouton noir parmi les brebis vertueuses

Il est en ce moment un nom qui provoque des frissons d'indignation chez les DSI et les managers. Une pratique qui, même dans certaines organisations ayant adopté intégration continue et TDD au sein de leurs équipes de développement, reste un tabou autour duquel gravitent beaucoup d'idées reçues. Cette pratique mal-aimée, du moins en France, c'est le Pair Programming.

Qui n'a jamais entendu la réflexion suivante : "La programmation en binôme, c'est payer deux développeurs pour faire le travail d'un seul. Ma direction n'acceptera jamais ça." Il y a peu j'ai même entendu de la part d'une société qui pratique pourtant d'autres techniques d'ingénierie agiles au quotidien : "Nous ne sommes que quatre développeurs, vous comprenez qu'on ne peut pas se permettre ce genre de façon de travailler !"

Pourtant, les études montrant l'efficacité du Pair Programming ne manquent pas. Le chiffre habituellement donné est celui d'un développement 15% plus lent qu'avec deux développeurs séparés mais qui produit 15% de bugs en moins. Quand on sait que le temps de debug et de test est souvent bien plus long que le temps de développement initial, un tel gain de qualité n'est pas négligeable. Des études plus récentes vont plus loin, affirmant que pour des logiciels complexes, le Pair Programming apporte en moyenne un gain de qualité de 48% sans qu'il y ait de différence significative au niveau des délais.

Au-delà des chiffres, il y a le constat d'amélioration omniprésent lorsqu'on pratique le Pair Programming sur une période de temps significative. Pour l'avoir expérimenté entre autres en tant que membre d'une équipe à la fois nombreuse (10 à 15 développeurs) et hétérogène en termes de maturité sur le projet et d'expertise technique, les effets constatés sont assez spectaculaires :

  • Diffusion rapide de la connaissance du domaine à tous les membres de l'équipe
  • Montée en compétence technique favorisée par le binomage expert-novice (le novice ne se contentant pas d'écouter, il agit aussi, lorsqu'il a le clavier)
  • Choix de conception et d'implémentation de meilleure qualité, fruits de la réflexion conjointe et de la confrontation d'idées des deux coéquipiers
  • Moins de perte de temps et de déconcentration, le copilote servant de barrière de sécurité pour rester dans les rails de l'objectif fixé
  • Emulation au sein de chaque binôme et de l'équipe entière

Bien sûr, il ne s'agit pas de partir la fleur au fusil pour une colocation à durée indéterminée avec le collègue avec qui on se marrera le mieux. Il y a une rigueur à adopter et certaines règles de conduite nous y aident. Par exemple, le fait de timeboxer systématiquement les scéances de pairing, et de changer de coéquipier régulièrement (toutes les semaines, tous les jours, toutes les demi-journées, à l'équipe de trouver son rythme).

Je ne suis pas non plus partisan du 100% Pair Programming. Il y a certaines tâches de codage, parmi celles les plus répétitives et nécessitant le moins de réflexion et d'arbitrages, qu'un développeur peut, avec autant de qualité et plus d'efficacité, assurer seul.
En revanche, le binomage me parait être d'un bénéfice tellement évident pour certaines autres activités que je ne vois pas bien comment s'en passer. Par exemple, lorsqu'il s'agit d'intégrer un nouveau membre dans l'équipe ou pour le transfert de compétences entre un développeur partant et son remplaçant.

Enfin, un des avantages du Pair Programming qu'on ne cite jamais, mais qui serait pourtant de nature à rassurer les responsables, est le gain de rigueur et de focalisation dans le travail accompli. Un développeur qui paire sera moins tenté d'aller consulter son facebook ou lire ses mails perso toutes les cinq minutes. D'une part par respect pour son coéquipier, parce qu'il n'a peut être pas envie d'étaler sa vie privée, et d'autre part parce que programmer en binôme, c'est fixer mutuellement un cap et s'y tenir. C'est toujours beaucoup plus engageant de se promettre conjointement avec un autre développeur d'arriver au bout de cette fonctionnalité avant la pause déjeuner, que de se le promettre juste à soi-même.

Dans ces conditions, on peut se demander pourquoi tant de structures, même celles qui se revendiquent agiles, n'adoptent pas le Pair Programming. Sans doute est-ce une aberration dans un système encore dirigé par la sacro-sainte mesure de la performance individuelle par rapport au temps de travail. Sans doute aussi les décideurs voient-ils inconsciemment dans des coéquipiers des gamins qui se font plaisir plutôt que des travailleurs.

Au moins pourraient-ils, comme le préconise Martin Fowler, se donner la peine de l'essayer :

My view is that you should try it and the team should reflect on whether they feel they are more effective with pairing that without. As with any new practice make sure you allow enough time so you have a good chance of crossing the ImprovementRavine.

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...