Les 8 points essentiels de la réussite d’un projet avec les méthodes agiles

Résumé de la publication

Petit rappel concernant les méthodes agiles avant de se plonger dans la mêlée de Scrum : les méthodes agiles sont issues du manifeste agile, publié en 2001 par un panel d’experts en informatique. Ce manifeste se constitue de quatre attributs essentiels à respecter et de douze principes sous-jacents qui définissent l’approche nécessaire pour se considérer “agile”. Les méthodes agiles en pratique sont très simplement des méthodes pour piloter et réaliser des projets, et il en existe quatorze à l’heure actuelle. Pour plus d’informations, nous vous invitons à consulter notre premier dossier sur le sujet pour comprendre les méthodes agiles dans leur globalité. Dans cet article nous listerons les 8 principaux points importants dans une réflexion méthodologique agile.

Objectifs de la publication

  • Lister les principaux points d’intérêt de la méthode Agile
  • Comprendre les principaux axes de fonctionnement d’une méthodologie Agile

Introduction

Il existe de très bons livres permettant de se former à la gestion de projet agile et au cadre méthodologique Scrum en particulier.

Rares sont ceux qui abordent cette discipline sous l’angle de la réussite. Pourtant, on fait rarement un projet pour le plaisir d’en faire un et encore moins pour le voir échouer. La vocation de ce petit texte synthétique, allant « droit au but », consiste à combler ce vide. Après l’avoir lu, vous aurez en tête les leviers de la gestion de projet agile qui permettent de démultiplier les chances de réussite. Ce qui constituera pour vous un atout dans votre découverte, apprentissage ou pratique de la discipline.

Après une brève introduction à l’approche agile s’appuyant sur une métaphore, puis une proposition de définition d’un projet réussi, vous découvrirez les 8 leviers de la gestion de projet agile permettant de démultiplier les chances de réussite.

Qu’est-ce qu’une approche agile ?

Qu’est-ce qu’une approche agile ? C’est à cette question que je propose de répondre dans ce chapitre.

Et pour commencer, je vous propose d’écarter ce que N’EST PAS une approche agile. Car au risque, peut-être de vous décevoir, ce n’est malheureusement pas une baguette magique permettant de réussir un projet à coup sûr. En revanche, ça ne l’empêche pas d’offrir des leviers permettant de démultiplier les chances de réussite de ce dernier. Surtout si ce projet est complexe. Ce qui est souvent le cas, puisque le simple fait de faire travailler des êtres humains ensemble peut s’avérer complexe.

Alors qu’est ce qu’une approche agile ? En fait, 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 et 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’outil, de documentation, de contrat, ni de plan. Bref, c’est l’anarchie ». Bien sûr que non.

Ces 4 valeurs s’appuient sur 12 principes que je vous invite à découvrir par vous-même. Voici un lien qui y mène : http://goo.gl/loiFSS.

Ce manifeste illustre finalement ce qu’on peut appeler l’état d’esprit agile. Car plus qu’une simple méthodologie, il s’agit avant tout d’un état d’esprit porteur de valeurs et de principes fondamentaux.

Comme vous avez pu le constater à la lecture du manifeste, l’origine des méthodes agiles provient du secteur du développement logiciel même s’il intéresse désormais d’autres secteurs.

Ces méthodes sont nées d’un constat sur la réalité du terrain. Un constat qui consiste notamment à dire que les projets de développement logiciel sont devenus si complexes que l’incertitude est désormais inévitable sur de tels projets. Et pire que ça, pour un nouveau logiciel le besoin ne peut pas être complètement connu tant que les utilisateurs ne l’ont pas utilisé.

Partant de ce constat, une poignée d’experts de terrain ont pris conscience qu’il était temps d’attaquer la gestion d’un projet sous un autre angle que celui de l’approche traditionnelle. En repartant d’une page blanche. C’est ainsi que plusieurs méthodes alternatives au cycle en V ont commencé à voir le jour. Des méthodes extrêmement pragmatiques, puisque créées et éprouvées par des personnes de terrain.

Parmi ces différentes méthodes, Scrum est de très loin LE plus utilisé. Je dis « LE » parce qu’il s’agit d’un cadre méthodologique et non pas d’une méthode à proprement parlé. En fait, on pourrait presque résumer Scrum à la phrase « diviser pour mieux maîtriser ». Dans le sens où on divise le périmètre à accomplir en sous-ensembles d’éléments porteurs de valeur. On divise le temps en intervalles courts appelés itérations (ou sprints pour utiliser le vocabulaire de Scrum) dans lesquelles on conçoit, réalise et teste de nouvelles fonctionnalités augmentant la valeur du produit. Et sur un gros projet, on divise les troupes en équipes de moins de 10 personnes pour une coordination et une efficacité optimale.

Maintenant, je vous propose d’utiliser une métaphore pour illustrer mes propos…

Rien de tel qu’une métaphore

Les méthodes agiles partent du principe que spécifier dans les détails l’intégralité d’un produit avant de réaliser ce dernier, et chercher à établir un plan détaillé du projet avant de se lancer, est contre-productif.

Cela revient à planifier dans les détails un trajet Paris-Narbonne en voiture par les petites routes. Spécifiant chaque ville et village traversé, l’heure de passage associée, chaque rue empruntée dans les agglomérations, litres d’essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d’arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire même la panne. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez-vous passé à planifier cet itinéraire et comment réagirez-vous face à la frustration de ne pas pouvoir appliquer votre plan à la lettre ?

L’idée consiste à se fixer un premier objectif à courts-termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. On peut, au passage, réaliser une projection de l’heure d’arrivée basée sur les mesures faites sur les tronçons déjà franchis. Une projection qui ne sera jamais exacte mais qui sera déjà plus fiable que les prédictions de l’approche classique. Car cette projection sera basée sur l’expérience. On parle donc d’une approche empirique.

Voilà, j’espère que cette petite métaphore vous aide à comprendre à minima la philosophie agile. Passons maintenant aux leviers de réussite offerts par l’approche agile.

Les 8 Leviers de Réussite Agiles

Avant d’aborder ces 8 leviers de réussite, nous devons partager une même définition d’un projet réussi.

Définition d’un Projet Réussi

D’après vous, un projet réussi est-il projet qui aboutit à un produit conforme à ses spécifications initiales ? Pas nécessairement. J’ai le souvenir plutôt marquant d’une équipe ayant travaillé plus d’un an sur un projet mené en cycle en V en respectant scrupuleusement les spécifications validées à l’issue de la phase de conception. Respectant également le budget ainsi que le délai fixé. Beau succès a priori. Mais en réalité, l’ensemble du produit s’est retrouvé à la poubelle. Il ne répondait pas au véritable besoin des utilisateurs. Au-delà de la perte budgétaire, je vous laisse imaginer le sentiment de frustration vécu par cette équipe, voyant qu’un an de leur vie professionnelle et de leurs efforts n’avait servi à rien, si ce n’est à apprendre que ce n’était pas la bonne voie à suivre en termes de produit.

Un projet réussi est-il un projet qui respecte le fameux trio : budget, délais et périmètre ? Sans oublier la qualité. Ça peut sans doute faire partie de la réussite. Même si, s’efforcer de respecter le périmètre initial peut nuire à la réussite. Puisque ça nous pousse à être fermé aux nouvelles bonnes idées qui ne manqueront pas d’arriver en cours de route.

Alors, je vous livre ma définition personnelle d’un projet réussi. Pour moi, un projet réussi est un projet qui donne le sourire à tout le monde. Aux utilisateurs, aux commanditaires, sponsors voire actionnaires. Ainsi qu’à l’équipe du projet qui a le sourire parce qu’elle est épanouie et fière de son travail. L’avantage avec cette définition, c’est que le succès est facile à mesurer. Il suffit d’observer la tête des gens, tout simplement ;-).

En d’autres termes, on réussit un projet lorsqu’on a fait le bon produit, celui que les utilisateurs attendent vraiment, au bon moment et au meilleur coût. Et Maintenant que nous partageons une même définition de la réussite, on peut passer aux 8 leviers de la gestion de projet agile qui permettent de démultiplier les chances de réussite.

Levier 1 : Réduire l’Effet Tunnel

Pour ce qui est du critère, « faire le bon produit », Souvenez-vous, pour un nouveau logiciel, voire un nouveau « produit » tout court, le besoin ne peut pas être complètement connu tant que les utilisateurs ne l’ont pas utilisé. Et le levier associé à ce principe, consiste à réduire l’effet tunnel, autrement dit cette absence de visibilité concrète que l’on constate sur des projets menés en cycle en V. Un tunnel qui correspond généralement à la phase de réalisation, la phase qui est paradoxalement la plus cruciale.

Sur un projet Scrum, on réduit cet effet tunnel en réduisant le délai entre l’expression du besoin et la concrétisation de la fonctionnalité associée. Plus ce délai est court, plus les écarts d’alignement entre le besoin exprimé et la fonctionnalité associée se réduisent. Délai qui correspond à celui du sprint (synonyme d’itération pour rappel). Sprint qui dure au maximum 4 semaines. Sur des projets de développement logiciel, il n’est pas rare de descendre à des durées de sprint de 2 semaines.

À la fin de chaque sprint, on va donc présenter le produit enrichi de nouvelles fonctionnalités aux utilisateurs finaux ou leur représentant afin de régulièrement vérifier qu’on fait le « bon produit » et on s’adapte si nécessaire.

Levier 2 : S’Ouvrir aux Changements

Second levier, s’ouvrir aux changements et les considérer comme des opportunités plutôt que des problèmes. Dans un monde en évolution permanente, l’ouverture au changement est devenue indispensable, voire même une question de survie. Il est donc hors de question de passer à côté d’une nouvelle super idée découverte en cours de route. Bien au contraire. Par ailleurs, la visibilité tôt et fréquente offerte par le premier levier favorise l’émergence de telles idées.

Sur un projet Scrum, chaque fonctionnalité qui n’est pas entamée ou planifiée dans le sprint en cours peut être révisée. Ou troquée au profit d’une nouvelle idée de fonctionnalité à plus grande valeur ajoutée. C’est finalement ce levier qui illustre le plus le terme « agile » au sens où il apporte énormément de souplesse sur le périmètre. Même si le terme « agile » vise aussi à illustrer la légèreté méthodologique.

Levier 3 : Optimiser la Communication

Troisième levier : optimiser la communication. La communication par écrit, par email ou spécifications, est sans doute le meilleur moyen de mal se comprendre. Puisqu’une telle communication est asynchrone et soumise à interprétation.

Rien n’est plus efficace que la communication en face à face. En particulier sur des projets complexes, sur lesquels il est à la fois difficile et crucial de bien se comprendre. Les méthodes agiles favorisent donc ce mode de communication. Ce qui n’interdit pas de restituer le fruit d’un échange en face à face dans de la documentation.

Par ailleurs, il n’y a pas d’intermédiaire entre l’équipe de développement qui réalise le produit et le responsable du produit qui représente les utilisateurs. Au contraire, on s’assure que ces deux acteurs interagissent ensemble au quotidien afin de bien se comprendre et avancer ensemble vers un objectif commun orienté « produit ».

Levier 4 : Minimalisme

Le quatrième levier, qui quant à lui démultiplie les chances de livrer au bon moment, consiste à se montrer minimaliste. St Exupéry disait « La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer. ».

L’objectif d’un projet agile ne consiste pas à réaliser toutes les fonctionnalités listées dans un cahier des charges. C’est même souvent contre-productif quand on y réfléchit. C’est comme ça qu’on peut se retrouver avec un produit « obèse », complexe à utiliser et maintenir. Un peu à l’image des télécommandes classiques de télévision dont on utilise à peine 10% des boutons.

L’idée consiste donc à commencer par réaliser les fonctionnalités qui ont le plus de valeur ajoutée. Ce qui nous permettra de mettre rapidement à disposition des utilisateurs une première version du produit. Et sur un marché soumis à concurrence, c’est évidemment un atout considérable.

Levier 5 : Amélioration continue

Le cinquième levier contribue aux trois critères de réussite à la fois et concerne particulièrement l’optimisation des coûts. Il s’agit du mécanisme d’amélioration continue. Face à un projet complexe, il est difficile voire impossible de définir à l’avance le processus de réalisation optimal. Il est donc nécessaire de s’appuyer sur une approche empirique.

Chaque itération donne l’occasion d’éprouver de nouvelles pratiques et techniques, pour ensuite les conserver ou les rejeter en fonction du résultat produit. Et la durée réduite des itérations ainsi que leur fréquence élevée permettent d’augmenter tôt et fréquemment l’efficacité de l’équipe du projet, donc des coûts. Peu à peu on se rapproche ainsi du processus de réalisation idéal sans jamais le considérer comme parfait.

Il y a un autre avantage offert par ce levier. C’est qu’on peut se lancer très tôt sans perdre de temps à essayer d’élaborer une organisation et un plan parfaits.

Levier 6 : Détecter les Défauts au plus Tôt

Sixième levier qui permet d’agir sur les coûts. Détecter les défauts au plus tôt. Plus un défaut sur un produit est détecté tard, plus il coûte cher. Un défaut sur un produit déjà entre les mains de milliers d’utilisateurs peut coûter des millions d’euros voire des vies humaines. Défaut de freinage d’une voiture, défaut de calcul d’une transaction financière, défaut de dosage d’un médicament, etc. Détecter ces défauts lors d’une phase de recette dédiée est déjà mieux qu’entre les mains d’un utilisateur mais on peut faire mieux.

Sur un projet de développement logiciel, on multiplie les opportunités de détecter les défauts au plus tôt à travers différentes pratiques d’ingénierie telles que l’intégration continue, la programmation en binôme ou le pilotage des développements par les tests.

Levier 7 : Architecture Souple & Émergeante

Septième levier associé à l’optimisation des coûts, et qui concerne peut-être encore plus spécifiquement les projets de développement logiciel, il consiste à utiliser une architecture souple et émergeante.

Je m’explique. Sur un projet de développement logiciel, on a tendance à comparer les travaux d’architecture à ceux du secteur du bâtiment. Des travaux d’architecture qui consistent, pour faire simple, à définir les différents composants techniques du logiciel que l’on veut réaliser et leurs interactions. C’est ainsi que l’on consacre un temps considérable à la définition en amont d’une architecture complète et détaillée, avant de construire par-dessus les fonctionnalités. Si bien que lorsque le périmètre fonctionnel est amené à évoluer (de nouvelles idées de fonctionnalités découvertes en cours de route ou l’abandon d’autres fonctionnalités finalement inutiles, voire carrément un changement de direction) on se retrouve plus ou moins enfermé dans l’architecture initialement prévue avec des coûts d’adaptation souvent importants. Et accessoirement, tout le budget qu’on aura consacré à la définition de la partie de l’architecture associée à des fonctionnalités finalement abandonnées, n’est que pure perte.

Il s’agit donc de concevoir une architecture souple qui va émerger au fil des sprints, en lien avec les fonctionnalités associées réalisées au fil de l’eau.

Levier 8 : Motiver

Enfin, le dernier levier, qui peut avoir une influence considérable sur les 3 critères de réussite à la fois, c’est la motivation. La motivation de l’équipe du projet constitue un levier de réussite essentiel. Une équipe motivée ira au-delà des attentes.

Sur un projet agile, le management doit croire en la capacité de son équipe à atteindre les objectifs fixés et offre son soutien quand c’est nécessaire. Il veille aussi à créer un environnement de travail motivant. Et à cultiver un rythme de travail soutenable afin de pouvoir maintenir ce dernier dans la durée sans sacrifier la qualité.

L’équipe quant à elle a le pouvoir de s’autoorganiser. Elle peut ainsi innover dans le choix et la mise au point de techniques et pratiques. Innovation qui ne peut émerger sans le droit à l’erreur accordé par le management. Le collectif a également une grande importance pour faire face aux challenges à relever. L’esprit d’équipe est ainsi cultivé, ce qui procure un sentiment d’appartenance et une fierté collective précieuse.

Les principes de confiance, auto-organisation, rythme soutenable font partie des 12 principes du manifeste agile et les interactions humaines sont valorisées par la première valeur de ce même manifeste.