Quand Alain rencontre un coach agile

Avec les miracles de la technologie, le mois dernier, nous avions interrogé Albert Camus sur le management et les organisations.

Ce mois-ci, c'est avec Alain que nous allons évoquer la création de logiciels.

Dans "Avec Balzac", tu as écris que "l’erreur propre aux artistes est de croire qu’ils trouveront mieux en méditant qu’en essayant ; mais le métier et la necessité les détournent d’une voie où il n’y a rien. Ce qu’on voulait faire, c'est en le faisant qu’on le découvre.", les créateurs de logiciels ne font-ils pas presque toujours cette même erreur ?

Ah, cher interlocuteur, je vois là une question pertinente qui transpose l’expérience artistique au domaine du logiciel, ce qui n’est pas sans finesse. Les créateurs de logiciels, comme les artistes, semblent bien souvent croire que la réflexion pure – ce moment de contemplation où l'on imagine la perfection du produit fini – suffira à produire l'œuvre. Pourtant, le logiciel, tout comme l'art ou la littérature, est une œuvre qui se découvre dans l'acte même de sa création.

Quand j'écrivais que "ce qu'on voulait faire, c'est en le faisant qu'on le découvre", je soulignais cette vérité essentielle : l'idée abstraite n'est rien sans l'effort concret qui la transforme, la polit et parfois même la contredit. Dans le domaine du logiciel, n'est-il pas évident que c'est le prototype, l'échec du code mal écrit, l'inattendu des tests qui mènent à l'amélioration ?

Prenons l'exemple de l'erreur. L'erreur en programmation, comme en peinture, est un guide précieux. Elle révèle des failles que la méditation seule aurait été incapable de prévoir. Les tests d'un logiciel jouent un rôle analogue à celui de l'exécution chez un peintre ou un musicien : ils confrontent l'idée à la matière. Et cette matière – les lignes de code, les données manipulées – résiste, force l'esprit à plier, à s'adapter, et parfois même à changer de direction.

La grande erreur des concepteurs de logiciels – et peut-être la plus "moderne" – est de croire que les outils sophistiqués ou les méthodologies "parfaites" pourraient remplacer le tâtonnement créatif. Les "sprints" agiles ou les "mind maps" préalables ne sont que des moyens ; ils ne dispensent pas de se heurter à la réalité, de corriger, d'essayer encore.

En somme, le logiciel, comme toute création humaine, se réalise dans l’effort. Et, je dirais même, ce n'est pas un mal : c'est précisément là que réside le plaisir créateur, celui de voir naître une idée qui n’était pas tout à fait celle qu’on avait imaginée.

Que pourrait en penser un coach agile ?

Analyse la réponse d'Albert Camus en te référant aux valeurs et principes des méthodes agiles. Explique les enseignements que l'on peut en tirer.

La réponse d'Alain, bien que formulée dans un langage philosophique, résonne profondément avec les valeurs et principes fondamentaux des méthodes agiles. Voyons cela point par point.

1. "Ce qu'on voulait faire, c'est en le faisant qu'on le découvre"

Cela fait directement écho au principe agile de livrer fréquemment un produit fonctionnel et à l'idée que les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées. En agile, on reconnaît que les besoins et solutions évoluent au fil du travail. C'est pourquoi les itérations courtes permettent de tester rapidement une idée, de recueillir des retours, et d'ajuster en conséquence.

Enseignement :
La création logicielle n'est pas un processus linéaire ; elle est exploratoire. Cela nous rappelle que la planification excessive en début de projet est souvent vaine. Ce qui compte, c'est de produire rapidement une version "vivante" du logiciel pour apprendre par la pratique.

2. "L'erreur en programmation est un guide précieux"

Alain met en lumière la valeur des erreurs, une idée qui s'inscrit dans le principe agile suivant : "accueillir favorablement les changements de besoins, même tard dans le développement". Les erreurs ou les imprévus dans le code ne sont pas des échecs, mais des opportunités d'apprentissage. En agile, les rétrospectives régulières permettent d'intégrer ces leçons pour améliorer les pratiques et le produit.

Enseignement :
Adopter une culture de l'apprentissage continu. Cela implique de ne pas blâmer les erreurs, mais de les traiter comme des jalons vers un meilleur résultat. Par exemple, l'utilisation d'intégrations continues et de tests automatisés permet de détecter les erreurs tôt et de s'ajuster rapidement.

3. "L'idée abstraite n'est rien sans l'effort concret"

C'est une observation cruciale : en agile, on privilégie l'interaction avec un produit tangible plutôt que de rester dans le domaine des idées ou des spéculations. Cela se reflète dans la valeur agile : "Un logiciel opérationnel plus qu'une documentation exhaustive". Prototyper, tester et montrer un produit en fonctionnement, même incomplet, a bien plus de valeur que de peaufiner des documents ou des modèles théoriques.

Enseignement :
Livrer rapidement un produit minimal viable (MVP) pour le confronter à la réalité. Cela réduit les risques liés aux hypothèses erronées et donne aux parties prenantes un aperçu concret de l'avancée du projet.

4. "Les outils ne dispensent pas de se heurter à la réalité"

Alain souligne un écueil fréquent : la survalorisation des méthodologies et outils. Dans les valeurs agiles, on dit explicitement : "Les individus et leurs interactions plus que les processus et les outils". Bien que les frameworks comme Scrum ou les outils comme Jira soient utiles, ils ne doivent pas devenir des fins en soi. La création logicielle reste avant tout une aventure humaine.

Enseignement :
Rester centré sur les interactions au sein de l'équipe, sur le dialogue avec les utilisateurs, et sur les retours concrets. Les outils doivent rester des moyens pour atteindre un objectif, et non des contraintes rigides.

Synthèse et Conclusion

La réflexion d'Alain nous invite à adopter une posture fondamentale de l'agilité : accepter l'imperfection et l'incertitude comme moteurs du progrès. Elle nous rappelle également que la clé du succès réside dans l'action, dans l'adaptation continue, et dans la reconnaissance que le produit final sera toujours un peu différent de ce que l'on imaginait au départ.

Pour un coach agile, cela se traduit par ces conseils :

1. Encouragez les équipes à produire quelque chose d'utilisable dès les premières itérations.
2. Favorisez une culture qui valorise les apprentissages issus des erreurs.
3. Placez les interactions humaines et le travail collaboratif au centre des priorités.
4. Rappelez-vous que l'agilité, comme la philosophie d'Alain, est un art qui s'apprend en le pratiquant.