Agilité et efficacité

Cet ouvrage est un instrument. Il a été conçu comme tel — et en vue de mener des luttes. Comme tout instrument, il faut le pratiquer. Et comme tout instrument, il devrait instruire ceux qui le pratiquent : à travers leurs pratiques, l’instrument tend à instruire un aspect du monde que ses praticiens ont en commun et surtout font en commun.

Ceux qui pratiquent le piano, par exemple (ce qui s’appelle jouer du piano), instruisent la musicalité du monde sur le registre spécifique ouvert par cette lutherie — à travers eux, le piano et son art deviennent, s’individuent et font le monde plutôt que l’immonde. Et dans la mesure où un instrument doit être pratiqué, il faut apprendre à s’en servir : jouer du piano nécessite d’apprendre la musique.

Pharmacologie du Front National, Bernard Stiegler.

Le débat pratique vs. culture qui anime la scène agiliste ces derniers temps est induit par un rapport mal accepté à l’efficacité. Beaucoup de personnes se sont lancées dans des pratiques agiles dans le but clairement affiché d’améliorer leurs performances (l’intervention d’Alain Fontaine, président de la cellule d’innovation chez Airbus à Lift France était assez caricaturale en ce sens). Et l’on peut facilement interpréter ces principes sous l’angle de la compétition et du capitalisme :

Or, je vois nombre de prescriptions dans ces principes: "en livrant rapidement et régulièrement", "satisfaire le client", "avantage compétitif au client", "Livrez fréquemment", "une préférence pour les plus courts", "quotidiennement", "plus efficace". Ces prescriptions concernent le rythme de développement ainsi que l’efficacité. Il s’agit notamment de compétitivité.

Il en ressort que l’agilité est donc une manière d’être efficace dans la course économique. Souscrire au manifeste agile revient donc à s’assujettir à cette course. Pas vraiment une libération, donc.

Software craftsmanship, agilité, Oranadoz

Pour moi le manifeste agile était un premier jet, un brouillon, et ne doit pas être suivi comme un plan mais adapté à la situation et aux personnes présentes. C’est la raison pour laquelle je ne me formalise pas de sa rédaction maladroite, il a fait son temps et a été très utile pour amorcer un changement mais il est temps de s’en affranchir et de le dépasser.

Qu’est-ce que l’on a appris en jouant la musique de l’agilité ?

Qu’il fallait du bien-être et que le curseur performance/rythme soutenable est difficile à trouver et change en fonction des personnes et de leurs contextes. Nous évoluons dans un système complexe dirait Pablo citant Edgar Morin.

Qu’il fallait du sens pour entretenir la motivation dans la durée et se sentir utile dans son travail au-delà de la technique. Les techniciens se transformant en virtuoses (artistes sans inspiration) dépérissent tôt ou tard.

Qu’il fallait du fun pour apprendre à collaborer — ou du moins à se connaître dans un premier temps — ce qui est rarement le cas dans la sphère du travail. « Connaissons-nous nous-même » aurait pu énoncer un Socrate moderne. Les jeux sérieux sont une première approche mais d’autres pratiques devraient permettre d’introduire du fun au quotidien de façon appliquée.

Qu’il fallait de la mixité pour pouvoir échanger entre domaines, entre entreprises, entre équipes, entre pays, entre cultures. La consanguinité des codeurs blancs trentenaires est malsaine et réductrice. Tous les domaines ont leurs pépites de collaboration, toutes les équipes on des moments de fun. Il suffit de savoir les raconter, les reproduire et les diffuser.

Est-ce que l’agilité est en contradiction avec l’artisanat ?

Se réclamer artisan et souscrire au manifeste pour un développement agile est alors paradoxal. L’artisan applique son savoir-faire, fait évoluer ses pratiques et ses outils notamment par une réflexion sur son métier, son activité. Utiliser un outil le prive d’une partie de son savoir-faire. Il doit donc toujours penser aux savoir-faire qu’il souhaite conserver, pour pouvoir les faire évoluer, et ceux qu’il accepte de déléguer à des outils, au risque d’en être dépendant.

Or, le rythme prescrit par le manifeste pour un développement agile encourage à gagner du temps, donc l’automatisation par laquelle le développeur perd des savoir-faire, sans forcément avoir le temps de choisir ceux qu’il veut garder ou non.

Pour moi le savoir-faire est orthogonal au savoir-collaborer, l’addition des deux pouvant mener au savoir faire ensemble. Je ne pense pas que l’on puisse arriver à une collaboration efficace à court terme et la délégation de ses outils signe la perte de son approche artisanale. Pour pouvoir combiner les deux, il faut avoir une vision à long terme. Accepter l’inefficacité, accepter la réappropriation des savoirs, tout en arrivant à survivre et à évoluer. C’est ce que l’on tente de faire avec scopyleft, expérience après expérience.