Je suis de plus en plus confrontée à des clients dont l’exigence première est de mener leur projet en suivant une méthode Agile. Le cadrage n’a pas encore eu lieu que “Soyons agiles” semble être leur nouveau gourou à suivre aveuglément. Et gare à ceux qui oseraient le remettre en cause: ils se retrouvent immédiatement étiquetés comme “has been” psycho-rigides attachés au vieux monde du cycle en V.
Notez que je ne parle pas uniquement de projets de systèmes d’information, mais également de tout besoin de changement, comme la redéfinition des processus métier ou l’amélioration de la gouvernance en entreprise. Eh oui, on veut tout changer, tout-de-suite, et en mode agile s’il-vous-plaît.
Si on repartait des fondamentaux? Que signifie, de nos jours, un projet agile? Je vous invite à parcourir l’excellent site L’Agiliste qui décrit parfaitement ce qu’est et ce que n’est pas une méthode agile.
Notamment ceci:
Il s’agit d’une approche utilisant une ou plusieurs méthodes qui partagent des valeurs et principes communs formalisés en 2001 dans le “Manifeste Agile”.
Ce manifeste nous dit notamment: “Nous découvrons comment mieux développer des logiciels par la pratique en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : les individus et leurs interactions plus que les processus et les outils; des logiciels opérationnels plus qu’une documentation exhaustive; la collaboration avec les clients plus que la négociation contractuelle et l’adaptation au changement plus que le suivi d’un plan. Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.”
La dernière phrase a son importance car c’est en l’ignorant qu’on bascule dans les idées reçues du genre “OK, donc sur un projet agile, il n’y a pas d’outils, de documentation, de contrat, ni de plan. Bref, c’est l’anarchie…”. Bien sûr que non.
Florent Lothon, expert en méthodes agiles (site L’Agiliste)
Il ne faut pas oublier pourquoi est apparu la méthodologie dite « Agile », dans les années 2000. Basée sur des cycles d’itération très courts, la gestion projet, auparavant calée sur le cycle en V (je spécifie, je développe, je teste, puis je livre) devenait itérative et adaptative. L’objectif était d’être flexible face à une évolution rapide des besoins du Client, tout en sécurisant le cadre contractuel du maître d’œuvre.
Mais ces méthodes ont leurs inconvénients, à l’instar de celles qui les ont précédées (cascade, cycle en V). Par exemple, la nécessité d’avoir un niveau d’implication important de la part du client, la formation impérative des équipes qui doivent gérer la pression des “sprints”, ou encore l’organisation du travail rendue de facto plus complexe. Cela conduit de nombreuses entreprises, dans leur quête sans fin de la rapidité et de l’efficacité au détriment de l’efficience, à dévoyer la pratique de l’agilité.
Agilité est devenu synonyme de rapidité, et n’est malheureusement plus un gage de qualité. A tel point que l’un des pionniers de la méthode agile, Ron Jeffries, préconise aux développeurs de l’abandonner (pour lire son article du 10 mai 2018, cliquez ici), faute de réussir à l’utiliser comme elle le devrait.
Voici ce que Ron Jeffries nous dit:
Lorsque les idées “agiles” sont mal appliquées, elles entraînent souvent plus d’interférences avec les développeurs, moins de temps pour effectuer le travail, plus de pression, et des demandes pour “aller toujours plus vite”. C’est mauvais pour les développeurs, et, en fin de compte, également mauvais pour l’entreprise. Mal travailler en “agile” conduit, le plus souvent, à développer une solution ayant beaucoup plus de défauts, et une progression beaucoup plus lente que ce qui aurait pu être réalisé.
(…) Au fil des ans, j’ai entendu de nombreux développeurs dire que “Agile, c’est nul” (…) J’ai essayé d’aider ces gens à comprendre que leur organisation applique mal les méthodes agiles : ils ne font pas ce que les auteurs du “Agile Manifesto” recommandent, ni ce que Scrum recommande, ni ce que les nombreux experts en développement logiciel Agile recommandent.
(…) Il est temps d’essayer quelque chose de nouveau, alors voilà : “Les développeurs doivent abandonner les méthodes Agile”.
Ron Jeffries, article du 10/05/2018
Gardons notre sens pratique et notre pragmatisme, prenons le temps d’étudier la méthode la plus appropriée au contexte projet, et à chaque fois que nous en sélectionnons une, prenons le temps d’en comprendre les objectifs pour en tirer le meilleur.
Enfin, attachons-nous à produire des résultats en conformité avec les besoins, sans être dogmatique. Une méthode n’est bonne que si elle produit les résultats escomptés.
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
