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

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.