Description :

Vous avez surement entendu parlé des méthodes agiles ou de la méthode agile. Certains la perçoivent comme une énième méthodologie à la mode, difficilement compatible avec leur contexte. Surtout dans le cadre d’un contrat au forfait. Qu’est ce que l’approche agile au juste ? D’où vient-elle ? Comment s’applique-t-elle concrètement ? Voilà ce dont traite cette introduction aux méthodes agiles et à Scrum en particulier.

Approche Agile plutôt que méthode Agile

Si l’approche agile est nouvelle pour vous, il me semble important de partir sur de bonnes bases. Laissez moi vous dire au passage, que je suis honoré d’être votre guide vers ce nouvel horizon.

Le terme « méthode » est trop réducteur pour parler de cette façon d’aborder la gestion de projet. Il s’agit de bien plus qu’une méthode. On parle plutôt de paradigme agile, d’état d’esprit agile, de philosophie agile, de culture Agile ou encore d’approche agile, de mouvement agile, de courant agile, etc. En poursuivant votre lecture et en concentrant notamment votre attention sur le paragraphe « Le Manifeste Agile, un changement culturel », vous comprendrez mieux cette dimension cruciale.

On parle cependant de « méthodes agiles » pour définir les méthodes qui relèvent de ce courant.

Une autre approche de gestion de projet

Le terme « agile » définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V ou waterfall (en cascade). La notion même de « gestion de projet » est remise en question au profit de « gestion de produit ». De façon à raisonner davantage « produit » que « projet ». Après tout l’objectif d’un projet consiste bien à donner naissance à un produit.

Une approche dite « traditionnelle » attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu’il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l’application réalisée. On se rapporte alors aux spécifications validées et au contrat. Certains projets se terminent dans la douleur (surtout dans le cadre d’un contrat au forfait classique) au risque de compromettre la relation client. De plus il n’est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l’usage alors que d’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

Une enquête de 1994 du « Standish Group » (certes controversée, comme toutes les enquêtes qui traitent d’un sujet sensible) fait le constat suivant : « 31 % des projets informatiques sont arrêtés en cours de route, 52 % n’aboutissent qu’au prix d’un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu’il n’en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès. ».

Cette même enquête renouvelée en 2008 indique un taux de réussite de 35%, ce qui est plutôt positif mais demeure très faible. Le problème reste entier. Parmi les motifs d’échecs, arrivent en tête :

L’approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s’adapter aux changements de ce dernier. Mais pas sans un minimum de règles.

Une page du support sur la sensibilisation à l’agilité que j’ai animé chez ALTRAN.