Ce qui m’a amené à devenir agile

En 2021, les méthodes agiles font partie de notre quotidien. Il existe à ce jour pléthore d’articles expliquant l’approche agile (les valeurs) ainsi que les différentes approches de développement qui la composent.

Dans cet article je vous expliquerai ce qui m’a amené à devenir agile, ou pourquoi être agile aujourd’hui, plus que le comment devenir agile, en m’appuyant sur mon parcours professionnel et la réalité du terrain. J’essaierai d’extraire de mon parcours les points-clés qui m’ont amené à choisir ce chemin, et à intervenir aujourd’hui sur des projets en tant que Scrum Master.

Certains s’offusqueront de l’utilisation du terme méthode agile ou méthodologie agile car stricto sensu ce n’est pas une méthode. Il m’arrivera d’utiliser ces termes car on les retrouve dans la littérature. Je m’efforcerais de les mettre au pluriel car il n’existe pas une seule et unique approche agile.

Avant les années 2000, très peu d’entreprises appliquaient les démarches agiles et peu de personnes en connaissaient l’existence.
On voyait surgir ponctuellement des approches comme l’XP ou RAD mais elles restaient cantonnées à un cercle restreint de connaisseurs.
Ce n’est qu’après les années 2000 que la démarche a commencé à percer pour être complément adoptée par tous dans les années 2010.

Aujourd’hui, peu de personnes contestent leur efficacité mais il reste encore du chemin pour que l’organisation complète de l’entreprise y adhère efficacement (sujet d’ampleur qui pourrait d’ailleurs faire l’objet d’un futur article !)

Une formation classique, sans notions d’agilité

J’ai eu mon bac en l’an 2000 et suivi une formation en IUT de 2 ans puis en école d’ingénieur de 3 ans.

Ma formation en IUT était focalisée sur la pratique. Nous avions essentiellement des cours de programmation fonctionnelle puis orientée objet, des cours réseaux et systèmes.
Grâce à mon DUT j’ai pu acquérir toutes les bases techniques qui me servent encore aujourd’hui.

Mon passage par l’école d’ingénieur était au contraire très théorique. Nous devions résoudre différents problèmes mathématiques par la démonstration. La visualisation des solutions mathématiques à ses problèmes étaient mis en pratique avec l’outil informatique. Quelques exemples qui me viennent en tête sont l’optimisation des flux dans un graphe, le voyageur de commerce, la reconnaissance vocale et la reconnaissance d’images.

Lors de mes études, je n’ai reçu qu’une maigre formation en gestion de projet. Elle favorisait les aspects de conception et de développement. Et bien évidemment, à aucun moment la démarche agile ne fut abordée. Ce n’est qu’après, dans le monde professionnel, que je suis devenu agile !

Mon premier projet informatique

J’ai commencé ma carrière dans une petite ESN. Je faisais partie d’une petite équipe (5-10 consultants selon les projets) dédiée au développement web au forfait. J’étais accompagné d’un chef de projet et d’un architecte/développeur senior qui m’ont beaucoup appris.

Pour mon premier projet, je devais développer une site intranet dont le rôle était de récolter des informations sur l’efficacité énergétique de maisons ou appartements afin d’en donner une note (A, B, C…). L’équivalent de la classe énergétique dans l’électroménager. On était une petite équipe, un développeur senior, un chef de projet et moi-même en tant que développeur junior.

Les projets étaient menés en cycle en V. Le choix de l’agilité ne se posait pas à cette époque. L’ensemble des spécifications étaient rédigées avant les développements, avec ponctuellement des besoins mal définis ou mal compris. Ce qui d’ailleurs amenait des changements réguliers. Enfin la phase de test, en queue de projet, venait confirmer que le « livrable » correspondait à la « commande ».
Les projets étaient menés dans un esprit administratif ou contractuel plutôt que de valeur client.
J’insiste également sur le fait que le demandeur, en sous-traitant la réalisation, se retirait du projet pour n’y revenir qu’en fin de projet pour valider sa demande. C’était la démarche habituelle et on la rencontre encore de nos jours.

Dans son ensemble le projet s’est bien déroulé, nous avons livré le périmètre attendu dans le temps et le budget imparti. Pour faire face aux difficultés, on s’adaptait sans méthode particulière. La réussite était en grande partie due à la simplicité du projet. Celui-ci a duré environ 5 mois. En définitive les facteurs de réussite ont été les individus et l’adaptation.

Première étape de mon parcours, cette expérience m’a permis de prendre conscience d’une valeur primordiale contribuant au succès de projets informatiques : les individus et les interactions améliorent la réussite plus que les processus et les outils.

Les projets au forfait, l’anti-pattern agile

Je voudrais m’attarder sur le concept de développement au forfait car je l’ai pratiqué très régulièrement à mes débuts. Il est important d’en comprendre les tenants et aboutissants pour comprendre pourquoi je me suis tourné vers l’agilité.

L’approche au forfait consiste à analyser le besoin émis par le client, sous forme de cahier des charges et d’y répondre avec une démarche accompagnée d’un coût et d’un délai. Que l’on peut comparer à un devis. Si le devis convient au client, celui-ci contractualise la démarche avant de démarrer le projet.
Périmètre, délai et budget… C’est le principe du « triangle de fer » !
En résumé, la qualité d’un produit est définie par le budget, le délai (temps) et le périmètre définis pour le projet. Ainsi dans un forfait « classique », ces 3 paramètres – temps, argent et fonctionnalités – sont figés contractuellement.

Lors des mes différentes expériences dans les projets menés au forfait, j’ai ressenti une forte pression afin de tenir les délais. C’était le cas notamment lors d’un projet pour une startup d’import/export. Nous avions pour mission de créer un site de saisie des produits, achats/ventes, factures, stocks, etc. Nous avions 6 mois pour le mettre en place. Chaque jour de retard faisait perdre la marge du contrat (forfait) à notre société.

Le client n’était pas impliqué/présent durant la phase de développement. Celui-ci ne découvrait le produit qu’en fin de projet, lors de sa livraison. Les échanges se transformaient alors en négociation commerciale de part et d’autre afin d’imposer ses choix plutôt qu’en compromis.
Ce projet n’a pas échappé à la règle et lors de la livraison, le client n’a pas été complément satisfait des fonctionnalités. Certaines n’étaient pas assez abouties, d’autres mal adaptées à leur quotidien.

Evidemment au lieu de trouver une alternative commune afin de corriger ces problèmes, nous justifions que le produit livré était bien conforme aux spécifications. Le client de son côté, revendiquait que le produit n’était pas conforme à sa vision.

C’est en partie suite à ces difficultés que des démarches agiles ont émergé.

C’est donc pour moi une nouvelle prise de conscience de l’importance de l’implication du client et des utilisateurs dans un projet : la collaboration avec le client facteur de succès dominant sur la contractualisation des relations client/fournisseur.

Être agile, c’est savoir accepter le changement

Mon deuxième projet avait pour nom Cytogest. C’était un site intranet développé pour un startup de recherche scientifique dans lequel les utilisateurs rentraient différentes molécules correspondant à leurs travaux de recherche (formule, image et diverses informations…). Une sorte de base de données de molécules avec en sus des fonctionnalités spécifiques.

Malheureusement ce projet n’a jamais pris fin ! Il a démarré avec un périmètre figé mais le besoin ne cessait d’évoluer ! Un cycle de création de nouvelles fonctionnalités puis de corrections ou améliorations s’est mis en place.

Le projet au forfait et de surcroit en cycle en V était inadapté à la situation. Nous développions et améliorions des fonctionnalités en continu. Alors que le forfait par nature impose un périmètre et un délai figé.

Chaque modification devait être classé soit comme une demande nouvelle ou une erreur nous incombant. Dans le premier cas nous établissions un avenant au contrat, dans le second cela faisait partie du périmètre initial. Pour empirer les choses, la même modification de code pouvait dans certains cas être imputée aux deux. Des efforts de suivi contractuel et projet au détriment de la qualité du produit.

Dans l’approche traditionnelle, les spécifications sont très détaillés et on s’empêche toute modification de celles-ci. Le contrat au forfait est en théorie une bonne option. Mais dans la pratique c’est rarement le cas. Un constat s’imposait, l’approche n’était tout simplement pas adaptée.

C’est ainsi que j’acquis une notion fondamentale pour la réussite d’un projet : l’acceptation du changement plutôt que la conformité aux plans.
Lors que les parties prenantes intègrent ensemble les divers changements dans la vie du projet, cela amènera à livrer in fine plus de valeur.

L’agilité prône la notion de MVP

Concrètement, l’agilité répond au besoin d’adaptation par la création d’une vision minimale du produit (MVP = Minimum Viable Product), puis son amélioration par incréments.

La pratique consiste à restreindre à son strict minimum la première version du produit livré. Ce n’est qu’après qu’on intégrera de nouvelles fonctionnalités. Les demandes seront d’autant plus légitimes car constatées comme manquantes dans l’usage du produit au quotidien. A l’inverse, dans le cycle en V, on s’oblige à décrire très précisément un besoin assez vague qui au final ne correspondra que partiellement à l’activité effectivement constatée.

Adopter la démarche itérative présente les avantages suivants :

• Produit rapidement opérationnel
• Progression transparente pour le client
• Demandes concrètes et utiles: on évite l’effet pervers de devoir tout exprimer en amont pour au final se retrouver avec un outil sous utilisé.

Je vous invite également à lire l’article « 28 statistiques sur la gestion de projet qui vont vous surprendre« ¹ pour réaliser les avantages de la méthode MVP.
Mon parcours m’a permis d’intégrer la maxime « Plus la complexité et la taille d’un projet sont importantes, plus le risque d’échec est fort« 

La communication

La communication est clé de la réussite dans un projet, car :

• Elle amène les parties à s’impliquer et collaborer.
• Evite le stress de l’incertitude: « mieux vaut une mauvaise nouvelle que pas de nouvelle du tout ».
• Permet de lever les incompréhensions de l’écrit.
  Selon le principe de « la déperdition de l’information », l’interlocuteur retient moins de 10% du message initial. L’écrit n’arrange rien puisqu’il n’y a pas de feedback possible.

Tout informaticien a forcément vécu l’illustration. Nombre de projets échouent par manque de communication à divers niveaux. Recueil du besoin, spécifications techniques, documentation d’exploitation, etc. Afin de combler ces manquantes, l’implication des parties est primordiale. A mes débuts, j’étais plusieurs fois surpris de constater l’écart entre les efforts mis dans une fonctionnalité et le peu d’utilité pour le client et inversement.
Un exemple, nous avions mis bcp d’efforts dans la simulation d’un devis dentaire dans l’espace client qui au final s’avérait peu utilisée. Inversement, de simples liens entre les différentes rubriques du site pour améliorer la navigabilité était très prisés !

La proximité et l’implication sont des valeurs clés pour améliorer la communication et ainsi optimiser les efforts et la valeur livrée.

Les difficultés du cycle en V

A mes débuts, pratiquement tous les projets informatiques étaient conduits par une approche type cycle en V. Cette méthode est fortement inspiré des projets de construction.
On commence par définir le besoin / faisabilité. Ensuite on défini le plan qui va servir de base pour bâtir l’œuvre. Enfin le client réceptionne et valide le bon de livraison.

La démarche est cohérente mais présente un certain nombre de lacunes en pratique :

• La planification initiale est souvent erronée (estimation souvent optimiste). C’est également le cas dans le bâtiment, où on constate régulièrement des retards…
• Les changements ne sont pas permis, une fois le plan validé contractuellement, on le construit.
• Le cloisonnement des parties prenantes amène à une mauvaise communication, ce qui conduit à de nombreux reworks.
• Une déviation de la trajectoire n’est constatée qu’en fin de projet (durant la phase de tests). Le retour à la normale est souvent très difficile. Il faut modifier tous les développements réalisés sur une base erronée.

Une mauvaise définition du besoin, la déformation du message client par les intermédiaires ou encore une adaptation au marché constamment en évolution amène de nombreux reworks. Ces reworks étaient gérés par improvisation, selon la maturité des équipes. Ils généraient des retards et surcoûts.

Je vivais ces difficultés comme une fatalité. J’étais persuadé que c’était inhérent à tout projet informatique. C’est l’expérience des membres de l’équipe qui nous aidait à nous prémunir de ces écueils, au travers d’actions, de précautions, qui se retrouvent aujourd’hui naturellement au sein des principes agiles.

L’agilité telle qu’elle a été modélisée pour les projets informatiques n’est qu’une structuration opportune des bonnes pratiques de terrain ! C’est cette prise de conscience à un point de ma carrière qui m’a poussé à m’intéresser de plus près à la méthode Scrum, et à m’orienter vers le rôle de Scrum Master.

En résumé: l’approche agile donne un cadre aux pratiques de terrain

Ces déboires, toutes les équipes les ont connus, c’est pour cela qu’une nouvelle approche, appelée par la suite « agilité » a émergé.
Ce n’est pas une méthode théorique mais une approche pragmatique créée empiriquement. Elle va à l’encontre du cycle en V qui impose un respect de l’ensemble des étapes auquel cas le projet s’effondre.

Il n’y a donc pas un processus figé mais des « valeurs », c’est à dire des principes que doivent adopter les participants afin de réussir les projets. Ces valeurs sont les suivantes :

• Individus et interactions, plutôt que processus et les outils
• Fonctionnalités opérationnelles, plutôt que documentation exhaustive
• Collaboration avec le client, plutôt que la contractualisation des relations
• Acceptation du changement, plutôt que la conformité aux plans

Ces valeurs et la démarche, je les ai mises en pratique à partir de 2012. J’ai découvert la méthodologie Scrum et plus tard Kanban.
Elles m’ont permis de lever les difficultés des mes débuts, mais tout n’a pas été rose. Le poids des habitudes et les organisations en place ne facilitent pas le changement. Mais c’est ce qui rend mon métier passionnant 🙂

Je reviendrais plus en détails sur l’application de la méthode agile dans mon prochain article : Recueil des pratiques agiles sur le terrain.