5 idées reçues sur la gestion de projet agile

Florent Lothon

Les idées reçues à propos de la gestion de projet agile ou des méthodes agiles ne manquent pas et peuvent vous éloigner des bénéfices que vous pouvez en attendre. Avouez que ce serait dommage. A l'issue de cet article, vous pourrez vous faire votre propre idée.

Idée reçue n°1 : L'Agilité est une mode

Si l'on considère les méthodes agiles comme de simples méthodes, on peut se dire que c'est juste une mode qui passera. Après tout, des méthodes, on en a vu défiler. En réalité, les méthodes agiles sont bien plus que cela. D'une part, elles véhiculent des valeurs et principes fondamentaux - de management notamment - qui font d'elles un véritable état d'esprit, et d'autre part elles font l'objet d'un véritable changement de paradigme. A tel point qu'une ne devrait pas parler de gestion de projet pour qualifier cette approche mais de gestion de produit.

Le conditionnement du "mode projet" nous pousse à nous focaliser - parfois jusqu'à l'obsession - sur des critères de succès relevant du respect du délais, budget, périmètre... et qualité quand on ne la sacrifie pas au profit des premier critères. Et le produit alors ? Et la satisfaction des utilisateurs ? En mode agile, on se centre sur le produit et le but du jeu ne consiste pas à couvrir tous les besoins exprimés dans un cahier des charges initial qui sera tôt ou tard en déphasage avec le principe de réalité (cf. réelles attentes des "vrais" utilisateurs, évolutions réglementaires, nouvelles idées de fonctionnalités découvertes en cours de route, imprévus techniques, etc). Il consiste plutôt à satisfaire les utilisateurs et enjeux business associés avec le minimum de fonctionnalités.

On ne peut donc pas parler d'un effet de mode pour qualifier un tel changement de paradigme. D'autre part le mouvement agile est un mouvement de fond qui remonte à 2001, année de parution du manifeste agile, voire au delà, puisque la publication du cadre méthodologique agile le plus utilisé, Scrum, remonte à 1993. Un mouvement qui prend toujours plus d'ampleur malgré quelques dérives (certifications bidons, formateurs sans réelle expérience en gestion de projet agile, pratiques de développement agiles négligées, etc).

Idée reçue n°2 : L'Agilité, c'est l'anarchie

Cette idée reçue provient souvent d'une lecture un peu trop hâtive du manifeste agile décrivant les 4 valeurs et 12 principes communes aux différentes méthodes agiles.

4 valeurs qui consistent à privilégier les hommes et leurs interactions par rapport aux processus et aux outils car les projets sont devenus trop complexes pour interagir uniquement à travers des outils ou processus. A privilégier la réalisation d'un produit utilisable plutôt qu'une documentation exhaustive ou pléthorique, à privilégier la collaboration avec les clients plutôt que la négociation contractuelle et enfin l'adaptation au changement plutôt que le suivi d'un plan. Mais le manifeste ne s'arrête pas là, il ajoute : Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Autrement dit sur des projets agiles, il y a bien sûr des processus, Scrum en est un (très simple mais c'est un processus), des outils (il existe désormais pléthore d'outils de gestion de projet agile), de la documentation (il faut bien à minima capitaliser les connaissances requises pour la maintenance du produit et sa pérennité), des contrats (il existe même des contrats agiles "gagnant/gagnant") ainsi que des plans macro et beaucoup de planification (planification à 3 niveaux : long, moyen et court terme pour s'adapter aux changements).

J'ajouterai, que la gestion de projet agile exige bien plus de discipline et de rigueur que l'approche classique. A titre d'exemple, l'équipe d'un projet agile doit être capable de produire de nouvelles fonctionnalités potentiellement livrables aux utilisateurs à la fin de chaque itération dont la durée est très courte. 2 semaines en moyenne.

Idée reçue n°3 : L'Agilité, c'est pas pour les gros projets

Autre idée reçue liée au fait que les méthodes agiles et Scrum en particulier préconisent généralement une taille d'équipe inférieure à 10 personnes. Pour des raisons d'optimisation de "coûts" de coordination notamment. Une limitation qui n'est pas issue de la théorie mais de l'empirisme. Seul véritable moyen de parvenir à une méthodologie pragmatique adaptée aux réalités du terrain. Bien que cette recommandation de taille s'applique à une équipe, rien n'empêche de faire travailler plusieurs équipes de moins de 10 personnes. Il existe même des frameworks éprouvés de gestion de projet agile à grande échelle.

Idée reçue n°4 : L'Agilité, c'est uniquement pour les projets de développement logiciel

Nul doute que les méthodes agiles proviennent du secteur du développement logiciel. Cependant, on voit désormais Scrum (par exemple) utilisé sur des projets industriels, hardware ou encore dans l'éducation. Pour une raison simple, c'est que Scrum n'est qu'un cadre méthodologique léger et adaptable à toutes sortes de contextes projets. Il nous laisse toute liberté d'y intégrer les pratiques et techniques propres à notre contexte. Au point de nous déstabiliser au début car on a l'habitude d'attendre d'une méthode, la réponse à tous les problèmes et tous les cas de figure. Scrum est un cadre méthodologique, pas une méthode.

Idée reçue n° 5 : L'Agilité, ça marche qu'avec des bons et si tout le monde joue le jeu

Bien amenée, les méthodes agiles peuvent satisfaire aussi bien le top management que les acteurs de terrain. Car il se trouve que pour bénéficier des 8 leviers de réussite de la gestion de projet agile, il faut émanciper et respecter les acteurs de terrain : confiance, soutien, auto-organisation, rythme soutenable. Le manager quant à lui (ou chef de projet), généralement en surcharge, sera déchargé de certaines activités pesantes telles que les aspects planning et organisation du travail pour se concentrer sur la gestion des ressources, le leadership et le coaching des membres de son équipe pour développer leur potentiel, les faire grandir.

Mais si tout le monde ne joue pas le jeu ? L'important est surtout d'avoir un noyau dur de personnes prêtes à tenter l'aventure et un "sachant" agile déterminé à introduire l'agilité, notamment à travers le coaching des acteurs. Le niveau de compétences techniques des membres de l'équipe n'a pas davantage ou moins d'importance que sur un autre projet. De toute façon, tout le monde aura l'occasion de développer ses compétences.

Conclusion

Finalement, la seule véritable incompatibilité avec l'agilité serait une culture en conflit avec celle de l'agilité. Autrement dit avec les 4 valeurs et 12 principes du manifeste agile. Et là encore, il faut bien se dire que la culture d'une organisation peut évoluer. Il faudra peut être commencer par un premier projet pilote avec un sponsor fort qui adhère à la culture agile, a bien perçu les gains à tirer de l'agilité et saura démontrer ces gains en cas de succès du pilote pour faire basculer par la suite le reste de l'organisation.

Autre article qui peut vous intéresser : Les pièges de l'approche Agile.

A propos de l'auteur

Florent Lothon

Expert de terrain en gestion de projet et management d'équipe. Florent fait partie des pionniers dans l'usage des méthodes agiles sur des projets à forts enjeux en France dès 2007. Co-auteur du livre "Devenir une Entreprise Agile".

  • Aliou Sarr dit :

    Belle analyse. Je pense que les arguments sont là pour tout projet de développement de produit. L’idée d’un projet pilote pour convaincre de la pertinence des approches agiles est pertinente et beaucoup de spécialistes adhérent à cette idée. J’aimerai toutefois que les spécialistes produisent plus d’idées et d’exemples sur d’autres champs concernant la gestion de projet. Par exemple une approche agile d’un projet de changement et typiquement d’un projet ERP qui modifie les processus d’affaires avec des répercussions sur toute l’organisation

  • Bonjour Florent,

    Merci pour cet article à diffuser pour répandre la bonne parole 🙂

    Selon moi, le seul autre frein que je vois, serait les tests. Je n’ai qu’une seule expérience projet en mode agile, que nous avons adapté pour répondre à l’exigeante maîtrise d’ouvrage que j’étais 🙂
    60 anomalies à la fin de la 1ère itération !
    Alors voilà, comment suivre Scrum qui ne donne pas une part aux tests ?
    Selon un coach agile dont j’ai suivi une formation, il est impossible de faire de l’agilité sans l’automatisation des tests.

    Bien à vous,
    Malika, qui est tombée en amour du travail collaboratif en mode agile

  • Bonjour,
    L’un des points que je souhaite mentionner ne représente à mes yeux pas une idée reçue mais un frein à la démocratisation de l’utilisation des méthodes agiles.
    Ayant validé un Master 2 en 2012, il s’avère que les méthodes agiles n’ont jamais été mentionnées, et ce, malgré la multitude de cours de gestion de projets suivis.
    Ancrer ces méthodes dans les mœurs à ce moment lèverait le voile sur ces méthodes et effacerait également cette peur de l’inconnu lorsque le fonctionnement agile est présenté auprès des équipes projets en milieu professionnel.
    Pour ma part j’ai pris connaissance de ces méthodes au travers de recherches personnelles et notamment via votre site et vos explications claires.

  • Bonjour,
    Merci pour votre article.
    Je vois un « frein » à l’utilisation de la méthode, c’est de travailler en multi site.
    Il est malheureusement difficile de gérer le cérémoniel des mêlées quotidienne dans ce cas bien que la digitalisation des entreprises nous le permette de plus en plus.

    • Lothon Florent dit :

      Très juste Florent. Merci de me l’avoir rappelé.

      C’est vrai que je travaille depuis plus de 2 ans avec des équipes qui font leur mêlée à distance que j’en oublie que c’est perçu comme un frein au début.

  • Christophe FORET dit :

    Bonjour,

    Juste une petite contribution concernant l’idée reçue n°3 (L’Agilité c’est pas pour les gros projets). Spotify , le site de musique en ligne, a posté un retour d’expérience sur leur organisation. Pour les moins anglophones il y a eut une traduction de ce retour d’expérience (http://ayeba.fr/2013/06/spotify-est-agile-a-grande-echelle).

    Dans ce poste on nous explique qu’en découpant leur produit (le site Web de leur service) ils ont affecté chaque partie du portail à une équipe agile. Ils ont ensuite mis en place un certains nombre de process pour permettre la mutualisation du travail des différentes équipes pour obtenir un produit complet et cohérent développé et maintenu par plusieurs équipes SCRUM.

    Article très instructif et qui montre que l’idée reçue n°3 est en effet une… idée reçue.

  • Andréa Cochard dit :

    Bonjour,
    Tout d’abord merci pour tous ces articles intéressants. Dans le cadre de mes études d’ingénieur, je travaille actuellement sur le courant agile et je me demandais si vous auriez connaissance d’une application de ces méthodes dans le monde de la production ?
    Merci d’avance

    • Lothon Florent dit :

      Bonjour Andréa,
      Qu’entendez vous par Production ?
      Bien cordialement,
      Florent

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Vous voulez d'autres contenus de qualité ?

    Découvrez ces articles

    >