Vous avez dit agiles ?

Rassurez-vous chers clients et futurs clients, les consultants OPAL Consulting sont agiles ! Combien de fois nous a-t-on demandé si nous connaissions et pratiquions la méthode agile, prérequis à une collaboration fructueuse. Eh bien la réponse est oui !

Nous travaillons à 80% sur des projets « agiles » car c’est bien évidemment la tendance, que les méthodes ont fait leur preuve, et que nous comptons parmi nos clients des pure players qui se sont très tôt organisés en fonctionnement agile, sinon nés dans l’agilité. Nous n’avons d’ailleurs pas peur de dire que nous avons acquis la culture agile souvent avec nos clients, avec les premiers projets que nous avons menés il y a un peu moins de 10 ans, et que les méthodologies, bien qu’ayant des bases communes, sont appliquées de manières très différentes suivant les contextes des projets et la culture des entreprises. A noter que nombre d’entreprises étaient accompagnées par des coachs agiles intégrés au lancement de chaque projet qui contribuaient (et contribuent) grandement à ancrer le changement et à la réussite des projets.

Nous cautionnons donc ces démarches et les organisations qui en découlent, tout en émettant quelques réserves et posant des gardes fous au niveau des modes opératoires à mettre en place. Car si la méthodologie agile a apporté beaucoup dans la manière de gérer les projets, elle a également conduit à des dérives qui déclenchent encore quelques levées de boucliers dans les rangs des sceptiques.

Méfions-nous également de la course à l’agilité qui peut conduire certaines sociétés à proposer l’agile à toutes les sauces ou à s’improviser experts en maniant des termes et de grands principes très théoriques, qui s’avèrent bien vite vides de sens et de concret. Attention donc, à ne pas considérer l’appropriation de ces méthodologies et de ces manières de faire comme évidente, car le changement est profond aussi bien dans les entreprises que nous conseillons qu’au sein de nos propres organisations.
Nous vous proposons donc de nous suivre dans cet article, et de poser des principes fondamentaux sur le chemin qui mène à des projets réussis, des directions comblées, des équipes fières d’elles et, last but not least, des clients finaux satisfaits !

Les bénéfices de la méthode Agile

La méthode Agile permet avant tout une plus forte proximité entre les équipes : le métier, les maîtrises d’ouvrage et les équipes techniques travaillent main dans la main tout au long du projet, afin de délivrer un produit fini en phase avec les besoins exprimés. Cette proximité permet une meilleure réactivité, et une pleine implication des équipes fonctionnelles, à chaque étape de développement, et surtout de la transparence entre l’ensemble des parties prenantes au projet.

La collaboration entre les équipes est facilitée par des instances régulières. Les « daily meetings » réunissent quotidiennement les développeurs et le Product Owner du projet ; ils sont le lieu de partage des avancées de développements, et de précision des besoins exprimés. Côté technique, ces instances permettent également d’échanger entre développeurs ; ainsi en cas de blocage sur une fonctionnalité, un développeur hors du périmètre peut suggérer une solution de développement. Un comité projet hebdomadaire vient compléter ces instances quotidiennes, afin de prendre de la hauteur sur le projet et de faire le point sur la trajectoire attendue.
Les développements étant progressifs et itératifs, le produit créé est soumis à plusieurs phases de recettes intermédiaires à chaque fin de sprint. Ainsi les bugs sont corrigés au fur et à mesure et non pas à la fin des développements comme dans les organisations projet classiques.

A l’issue de chaque sprint, des phases de démo de l’outil sont organisées, afin de présenter aux différentes parties prenantes l’avancée des développements. Le client/utilisateur final peut ainsi avoir rapidement un premier aperçu de ce qu’il a demandé et donner son aval sur les phases suivantes.

L’agilité donne également la possibilité de s’adapter plus facilement à un changement d’orientation du besoin. Ainsi, si le produit présenté en démo ne répond plus à la problématique métier initiale, les équipes techniques peuvent adapter leurs développements avec une forte réactivité. Cette flexibilité permet au projet de coller au mieux à l’objectif final, sans rester bloqué sur le besoin exprimé à l’origine s’il ne fait plus sens.

Enfin, la méthode Agile donne l’opportunité au projet de construire un « MVP » (« produit » minimum viable), soit une première version du produit offrant un niveau minimum de fonctionnalités permettant au produit de fonctionner. Les évolutions suivantes permettent d’ajuster le produit en livrant régulièrement de nouvelles fonctionnalités ou optimisations des fonctionnalités initiales. Ce principe est fondamental car il permet de livrer le plus rapidement possible des éléments prioritaires qui seront réellement utilisés.

Enfin, l’agilité repose sur le principe fondamental d’amélioration continue dont la vertu est incontestable et nécessaire dans tous les projets.

En synthèse, l’intégration de la culture agile au sein des organisations et des projets présente des bénéfices qui ne sont pas à remettre en cause. Cependant, attention à certaines dérives, ou interprétations raccourcies de l’agile, qui mènent certains projets à l’échec.

Agile ne veut pas dire…

Finis les cycles en « V »…
Certains projets ne seront pas immédiatement compatibles avec une approche agile dans la mesure où il arrive qu’un socle soit nécessaire avant de rentrer dans des sprints de développement standards (1 à 3 semaines). Cela concerne notamment les projets liés à la mise en place d’outils CRM, de gestion des campagnes où plus généralement de systèmes informationnels qui requièrent une infrastructure et des bases techniques à partir desquelles les fonctionnalités plus métier seront construites. Les travaux à réaliser dans ces cas relèveront principalement de sprints techniques qu’il est idéalement important de cadencer suivant le rythme cible du projet, mais qui peuvent s’avérer plus longs au démarrage.

Pas de planning et d’échéance projet…
C’est LE cheval de bataille de nos équipes dans le cadre des projets d’intégration que nous pilotons. Avoir un planning est la base de tout projet, et une navigation à vue, conduisant souvent à des décalages planning, n’est pas acceptable. Combien de fois nous a-t-on dit « ne prenez pas cela comme un retard, considérez que nous construisons une trajectoire ». Une trajectoire se construit dès le démarrage, s’ajuste avec l’équipe constituée, mais dans tous les cas les équipes doivent rester focalisées sur une échéance partagée (et accessoirement un budget…). Et ce, même si le principe de l’agile impose une approche sur la durée de la construction et de l’évolution du produit final.

Des besoins en constante évolution…
Il arrive également que la promesse de flexibilité laisse croire aux équipes fonctionnelles qu’elles ont un passe-droit, leur permettant de revenir sur des besoins exprimés en début de projet ou de caser de nouveaux besoins en cours de sprint. Dans la majorité des projets sur lesquels nous accompagnons nos clients, les besoins évoluent en cours de projet et il est nécessaire de pouvoir s’y adapter. Il faut en revanche éviter de redéfinir complètement le besoin, sous peine d’induire un retard planning conséquent. Ceci implique un cadrage solide en amont du démarrage projet et un principe d’instruction et d’évaluation des nouveaux besoins, avant de les intégrer dans le backlog projet et de les prioriser.

Pas de spécifications / documentation
L’un des dangers de l’agilité est le manque de spécifications et de documentation. Les développements étant itératifs et le périmètre mouvant, les équipes techniques ne prennent pas toujours la peine de documenter les règles de gestion mises en place. Or, sans spécifications, la reprise du projet ou sa maintenance n’est pas optimisée et risque de faire perdre le temps gagné lors des développements en Agile.
Il faut donc non seulement une conception générale indispensable à la constitution initiale du backlog, au chiffrage et à l’organisation des sprints, mais également une documentation précise des développements qui doit être intégrée au titre d’une User Story du sprint. Ce dernier n’étant pas validé si la documentation n’est pas produite.

Pas de recette de bout en bout avec des User Stories globale…
Les recettes unitaires tout au long du projet permettent de valider des fonctionnalités précises, de corriger les bugs isolés, et d’avoir ainsi une grande réactivité dans l’optimisation des développements. En revanche cela ne doit pas empêcher une recette de bout en bout au niveau de grands jalons des projets sur des use cases globaux, afin de vérifier la rigueur et le fonctionnement de bout en bout du produit global fourni.

Nos recommandations :

Nous avons évoqué tous les bénéfices de la méthode Agile dont nous sommes convaincus. Cependant, pour mener à bien un projet Agile, il est nécessaire de prendre quelques précautions afin de ne pas tomber dans les pièges de la méthode :

• Veiller à bien ancrer la culture agile au sein de l’entreprise en s’assurant que la Direction est le premier relai de cette approche et que sa diffusion soit bien accompagnée et comprise au niveau des équipes opérationnelles ;
• Clarifier dès le démarrage les contenus des livraisons des premiers sprints, pour limiter le fameux effet tunnel (rien de visible par les métiers avant mise en place d’un socle technique par exemple) ;
• S’assurer d’une implication du « client » interne tout au long du projet. Il doit être disponible et prêt à s’impliquer à tout moment, selon les besoins des équipes techniques, pour un suivi au fil de l’eau du projet, et pour réaliser les recettes unitaires à chaque fin de sprint. La présence continue d’un Product Owner, en relation permanente avec les métiers et utilisateurs finaux, est essentielle sur toute la durée du projet ;
• Rédiger une Conception Générale, source du backlog, donnant lieu à un planning et des échéances projet. On acceptera par ailleurs que le périmètre évolue et que le planning soit décalé, sous réserve d’une validation conjointe des nouvelles priorisations ;
• Profiter des instances régulières pour garantir l’implication de tous les intervenants ;
• Fournir une documentation détaillée des développements finaux réalisés et intégrer leur validation dans les sprints ;
• Et enfin, réaliser une recette bout en bout en fin de projet, basée sur des user stories définies, afin de valider le bon fonctionnement de l’outil livré.