Massyl NAÏT MOULOUD est un professionnel de l’IT qui aime se définir comme un développeur. Le code est son étoile du berger. Son amour pour le code et les mathématiques n’a d’égal que son amour pour l’élégance masculine classique. Je souhaitais l’interviewer car il a une grande connaissance de l’agile, ayant été témoin des nombreux bénéfices et failles de ces méthodes.

Quand as-tu commencé à travailler en agile ?

L’agile c’est vaste. Pour l’implémentation (le code etc…) j’ai toujours travaillé avec des méthodes telles que XP etc… Pour la gestion de projet, depuis 2005

D’après toi, l’agile aide-t-il à produire plus de valeur pour le business ? Ou est-ce une conspiration pour nous vendre des postits ?

Pour le delivery, les méthodes telles qu’XP, BDD etc… aident à produire plus de valeur et améliorent la qualité du software. Personnellement, je n’aime pas le Test Driven Development, préférant le Type Driven Development pour l’exploration. Mais je pense que le pair programming, le code review, les tests unitaires… sont largement diffusés et avec beaucoup de succès. Il est très rare de rencontrer des développeurs qui doutent de la valeur de ces méthodes.

Pour la gestion de projet (Scrum, Kanban…) je suis plus mitigé. Je pense que lorsqu’elles sont implémentées correctement, elles apportent de la valeur. Toutefois, il y a de nombreux freins qui empêchent d’en tirer tous les bénéfices. Je crois n’avoir travaillé que sur un projet réellement agile.

Seulement un en treize ans ? Quelles sont les failles les plus communes ?

On implémente un framework agile, mais on garde les anciens réflexes. Accorder la confiance à l’équipe pour qu’elle s’organise arrive rarement. J’ai vu des daily standups où participait le responsable hiérarchique : cela devenait une séance de reporting. On oublie qu’on est là pour lever les freins.

Par ailleurs, on devient parfois dogmatique. Dans l’agile, on valorise plus la production de software de qualité que la documentation exhaustive. Mais pourquoi imposer une politique « zéro doc » ? Si j’ai besoin d’écrire, si cela fluidifie la communication au sein de l’équipe, pourquoi m’en empêcher ? L’agile, c’est se concentrer sur la valeur pour le business, time boxer, communiquer plus etc… ce n’est pas inventer un process et l’ériger en loi immuable.

Je crois également qu’on a, de manière générale, un problème avec l’amélioration continue. Je n’ai que rarement vu des rétrospectives ; et encore moins des rétrospectives qui fonctionnent comme elles devraient. On les utilise trop souvent comme des outils pour désigner des coupables alors qu’elles doivent permettre de gagner en confiance au sein de l’équipe ainsi que de progresser.

Enfin, nous avons trop tendance à oublier l’engagement. C’est le meilleur moyen de créer des frustrations et, in fine, provoquer un rejet de l’agilité : on repousse constamment et on ne livre jamais. Le scope est certes notre variable d’ajustement, mais nous devons nous engager clairement et avec force sur ce que nous allons livrer.

Pourquoi ces failles sont-elles si répandues ?

Il y a un élément culturel. Le micro management est très répandu en France, et c’est anti-agile.

J’ai également constaté que lorsqu’une entreprise décide de passer en mode agile, elle recycle d’anciens profiles : un chef de projet devient Scrum Master. Pas de formation. C’est oublier que l’agilité c’est avant tout un état d’esprit, un paradigme différent. On oublie la nécessité d’accompagner la transformation culturelle.

Oublions donc l’agile, et contentons-nous de faire comme avant ?

Non, mais il nous faut aborder l’agilité avec sérieux. Nous devons utiliser les bons outils qui nous permettrons de livrer plus de valeur pour le business et réduire le time to market. Choisissons des gens qualifiés qui nous accompagnerons dans l’atteinte de nos objectifs. Aidons nos équipes à monter en compétence et à adopter de nouvelles manières de travailler. Par exemple, je suis adepte de la programmation fonctionnelle, je suis convaincu que cela permet de produire du code fiable de manière disciplinée. Nous nous plaignons du manque de ressources compétentes, soit, mais aidons nos équipes à se développer plutôt que de niveler par le bas.

Il y a souvent des tensions entre le fonctionnel et la technique. Pourquoi à ton avis ?

Tout d’abord, c’est humain de chercher un bouc émissaire. Commençons par faire notre propre analyse : qu’est-ce que j’aurai pu mieux faire, où dois-je m’améliorer, et soyons honnête.

Par ailleurs, de nombreuses organisations fonctionnent en silos. L’agile permet de les casser, mais lorsque je m’adresse à quelqu’un, je dois me mettre à sa place et parler sa langue. Trop peu le font, ce qui produit un terreau fertile aux incompréhensions et à la montée des tensions.

Penses-tu que nous puissions être agiles en travaillant sur un système legacy monolithique ?

Il est vrai que travailler sur un outil flexible permet plus facilement de livrer rapidement. Je suis toutefois convaincu que l’état d’esprit agile peut aider toute organisation qui le veut bien, car je considère que les valeurs de l’agilité sont « universelles ».

L’agile requiert des équipes réduites ainsi que de nombreuses interactions. Comment peut-on être agile en near/offshorring ?

Dans une expérience passée, nous avions une équipe à Paris, une à Toulouse, une à Toronto ainsi qu’une à Bangalore. Il n’y a pas de recette miracle dans ce cas de figure. Il faut se rencontrer l’un l’autre, surtout en début de projet. Chacun doit se déplacer. Savoir qui est derrière un ID Slack est nécessaire.

Diviser le travail par scope technique fut également très important pour réussir dans ce projet. Enfin, avec une fragmentation telle, nous avons eu besoin de recourir à une équipe dédiée à la coopération, assignée à la consolidation du travail de chacun, à la levée d’obstacle inter équipe etc…

Souhaites-tu partager quelque chose d’autre ?

JE ME DOIS de mentionner mon langage de programmation « production ready » préféré : Haskell. Je dis « production ready » car il y en a d’autres, tel qu’Agda ou Idris. Je conseille à tous les développeurs d’apprendre Haskell même s’ils préfèrent ou en utilisent un autre. C’est un langage fantastique qui vous apprendra une nouvelle manière de faire du soft.

Retrouvez l’article de Thomas NEVOA PEREIRA sur Medium