15 idées reçues sur l’agilité

Thibault Baheux

22 juin 2022 - minutes de lecture

L'agilité, c'est ZE concept que l'on nous sert à toutes les sauces. On ne compte plus le nombre d'entreprises qui se disent agiles parce que c'est tendance, ou les cabinets de conseil qui vendent leurs services à prix d'or pour devenir une entreprise plus agile, alors même qu'ils n'appliquent pas eux-mêmes l'agilité.

L'agilité est un concept qui se répand mais qui est très souvent mal compris, mal implémenté et du coup mal utilisé.

Voici un tour d'horizon des mythes et des idées reçues les plus répandus sur l'agilité en entreprise.

15 idées reçues sur les méthodes agiles

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

"L'agilité n'est qu'une mode. On s'en sortait très bien avant tout ça. On continuera de faire comme on a toujours fait, et on y arrivera".

Oui, certes. Mais à quel prix ? Combien seront laissés sur le carreau ou baisseront les bras pour arriver au résultat souhaité ? La douleur n'est pas forcément un passage obligé en gestion de projet.

Je me souviens encore d'un DSI qui pensait que "l'agilité est un concept fumeux vendu à prix d'or par des guignols qui ne savent pas comment travailler mais qui vont vous apprendre à le faire".

Pourtant c'est on ne peut plus faux. L'agilité est bien là pour durer.

La réalité

L'agilité existe depuis bien longtemps. Le manifeste agile, qui décrit quelles sont les valeurs agiles et les principes des méthodes agiles a par exemple été rédigé et signé en 2001.

Pas tout jeune donc ! ça commence à faire de la bouteille pour une simple mode.

Cette vision erronée de l'agilité vient du fait que nous sommes conditionnés au "mode projet" : nous ne voyons une situation que sous le prisme de ce que nous connaissons déjà. La gestion de projet traditionnelle nous pousse à voir comme critère de succès un projet qui respecte les délais, le budget, le périmètre... Quitte à sacrifier la qualité.

Mon conseil

Acceptez que l'agilité est un changement de paradigme. Elle remet la qualité et la satisfaction du client sur le devant de la scène.

Changer de paradigme signifie changer en profondeur : culture, croyances limitantes, état d'esprit... Changer les méthodes de travail ne suffit pas.

Acceptez qu'il existe d'autres manières de faire que celles que vous connaissez, qui peuvent être autant voire plus efficaces. Le seul moyen d'en être sûr ? C'est d'expérimenter.

Pour aller + loin : Le manifeste agile est-il toujours d'actualité ? Découvrez ma réponse dans cet article.

Idée reçue n°2 : L'agilité ça ne fonctionne que pour l'IT

"L'agilité c'est bien, ça fonctionne, mais uniquement pour les projets de développement informatique."

Bzzzzz ! C'est faux !

Il est vrai que l'agilité s'est largement répandue dans le domaine de l'informatique, et plus particulièrement du développement. Il faut dire que ces projets s'y prêtent largement bien. Mais ce n'est pas parce que les services IT ont le plus souvent recours à l'agilité que les autres que ça ne marche que pour eux.

La réalité

Il faut voir l'agilité comme des bonnes pratiques de gestion de produit. Mais qu'est-ce qu'un produit dans ce cas ? Cela va d'un produit physique que l'on peut toucher au développement d'un outil informatique, en passant par la mise en place d'une nouvelle organisation ou d'un nouveau service.

L'agilité peut donc tout à fait s'adapter à des projets de recherche & développement, des projets de transformation RH, des projets transverses, des projets événementiels ou encore des projets immobiliers.

Mon conseil

Arrêtez de vous lancer dans des planifications détaillées qui ne servent à rien. Vous ne pouvez pas tout anticiper, vous ne pouvez pas savoir ce qui va se passer en bien ou en mal en cours de route sur votre projet. Faire une planification détaillée, c'est jouer au devin.

Établissez un macro-planning, puis procédez de manière itérative pour gérer votre projet.

Faites une session de brainstorming avec l'équipe afin de déterminer quelles actions concrètes vous pouvez mettre en place dès demain afin de développer une culture agile dans l'équipe. Reposez-vous notamment sur les 4 valeurs et les 12 principes de l'agilité.

Idée reçue n°3 : L'agilité, c'est le chaos

"L'agilité, c'est un monde de chaos sans foi ni loi, où les équipes rejettent toute autorité et font ce qu'elles veulent. Où le client est roi et peut subitement décider toutes les heures de changer d'avis, et déprioriser certaines actions pour en reprioriser d'autres, au grand dam de l'équipe projet."

Et bien... non, pas vraiment.
J'ai déjà vécu une situation comme ça, mais je peux vous garantir que ça n'avait rien d'agile.

La réalité

Cette idée reçue démontre un manque de compréhension de ce qu'est l'agilité. Alors oui, effectivement, les documents habituels en gestion de projet ne sont pas tous présents. Ils ne sont pas tous réalisés en amont du projet. On n'a pas de planning ultra détaillé avant de commencer la moindre action.

Mais bien sûr qu'il y a des processus en agile (et heureusement d'ailleurs). Bien sûr que les équipes ne sont pas en roue libre dans l'entreprise. Bien sûr qu'il y a du management : il n'est pas question de tout remettre en cause. 

Seulement, l'équipe est auto-organisée : elle est la plus à même de prendre la meilleure décision à un instant t sur un projet. Elle dispose ainsi de plus d'autonomie, de pouvoir de décision et de responsabilités qu'une équipe projet classique.

Mon conseil

Ne laissez pas les équipes partir en vrille et claquer la prote au nez du reste de l'organisation.

Fixez un cadre précis dans lequel les équipes peuvent s'auto-organiser et s'auto-gérer.

N'oubliez jamais que le manifeste agile précise bien concernant les valeurs agiles que :

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Manifeste agile

Idée reçue n°4 : L'agilité, c'est zéro hiérarchie

"L'agilité, ça signifie que tous les managers pointent au chômage."

Dans la lignée directe de la précédente celle-là. Et si si, je vous l'assure, je l'ai entendu.

La réalité

Ce mythe démontre une incompréhension autour de la notion d'équipe auto-organisée et auto-gérée. Cela ne veut pas dire que l'équipe est livrée à elle-même, en mode "roue libre", sans aucun management.

Cela veut dire que l'équipe est la mieux placée pour s'organiser afin de livrer le projet, et de prendre des décisions dans l'intérêt du projet. L'objectif de l'équipe agile est ainsi de créer le plus de valeur possible à partir d'un minimum de fonctionnalités, et de satisfaire le client.

Le management a tout à fait sa place dans l'agilité. Cependant, il est nécessaire que les pratiques de management évoluent. Les techniques de management d'un ancien temps type "management & contrôle" ne fonctionneront pas en agilité. Entre nous, elles ne fonctionnaient déjà pas avant.

Mon conseil

Formez vos managers à l'agilité et à l'évolution de leur métier et de leurs pratiques de management.

Je vous recommande notamment le site Management 3.0, ainsi que la lecture du livre éponyme :

Management 3.0 - Leading agile developers, developing agile leaders

Idée reçue n°5 : L'agilité, c'est pour les petits projets

Je pense que ce mythe trouve son origine en deux endroits : la taille réduite des équipes agiles, et le fait que l'agilité fait la part belle aux cycles courts de quelques semaines.

La réalité

La taille de l'équipe agile n'est pas dictée par une limitation des coûts et donc du périmètre du projet, mais par l'empirisme : plus il y a de personnes dans une équipe, plus la collaboration sera compliquée.

Une équipe agile doit cependant être autonome et disposer de toutes les compétences nécessaires en son sein pour mener à bien le projet.

Bien qu'une équipe soit composée de 10 personnes maximum, rien ne vous empêche de faire travailler plusieurs équipes agiles sur un même projet en parallèle. Il existe des frameworks éprouvés d'agilité à grande échelle (agility at scale), comme le framework Safe.

Mon conseil

Penser jalons, phases, et planning projet est une erreur lorsque vous utilisez des méthodes agiles. Ces notions se prêtent bien aux méthodes prédictives de gestion de projet, mais pas à l'agilité.

La question n'est pas de savoir quelle est la taille du projet, mais plutôt d'identifier la meilleure manière d'apporter rapidement de la valeur à un client. Et ça, peu importe le nombre de sprints nécessaires pour aller au bout du projet, vous serez toujours en mesure de le réaliser, même avec une équipe réduite.

Idée reçue n°6 : L'agilité, c'est utiliser Trello

"Ah ouais, tu utilises Trello ? Tu fais de l'agilité alors."

Euh... Pas forcément non. J'en connais plusieurs qui utilisent Trello comme ils utiliseraient une liste de tâches. L'outil ne fait pas l'agilité.

La réalité

La valeur n°1 du manifeste agile est très claire à ce sujet : ce n'est pas l'outil utilisé qui fait que l'on est agile ou pas.

Les individus et leurs interactions, de préférence aux processus et aux outils. 

L'agilité, c'est avant tout un état d'esprit. Du côté opérationnel, il faut plus voir ça comme un ensemble de bonnes pratiques (parmi lesquelles on peut avoir l'utilisation de certains outils spécifiques), dans un but unique : apporter le plus de valeur possible et satisfaire le client.

Mon conseil

Ne choisissez pas un outil parce qu'il est "agile", qu'il a telle ou telle fonctionnalité, ou parce que c'est le leader du marché. Choisir un outil, c'est avant tout sélectionner un outil qui est adapté à sa manière de travailler.

Plutôt que d'imposer Trello ou équivalent à l'équipe agile, laissez l'équipe agile s'outiller en fonction de ses besoins réels.

Idée reçue n°7 : L'agilité, c'est la méthode Scrum

"Scrum, c'est agile."

C'est vrai. Je vous l'accord, Scrum est un framework agile. Mais c'est loin d'être le seul.

Cette idée reçue est très présente, mais c'est sans doute parce que Scrum est la méthodologie agile la plus connue et la plus appliquée dans le monde.

La réalité

L'agilité ce n'est pas que faire du Scrum. D'ailleurs, certaines sociétés appliquent la méthodologie Scrum, mais échouent à développer une culture agile.

Cela s'explique car le Scrum Guide est rarement appliqué à la lettre à 100%. Si c'était le cas, les 12 principes agiles seraient évidemment respectés.

Mais vous pouvez également être agile sans appliquer du tout Scrum. Tant que vous respectez les 4 valeurs agiles et les 12 principes de l'agilité, vous pouvez vous considérer comme agile.

Par exemple, les méthodologies Kanban, XP (eXtreme Programming), Safe sont toutes des méthodologies agiles.

Mon conseil

Bien que Scrum pose un cadre précis qui peut vous faciliter la vie afin de faire prendre l'agilité au sein de vos équipes, je vous conseille de vous questionner sur l'application des valeurs et principes agiles au sein de votre organisation :

  • Pourquoi l'agilité ?
  • Comment les valeurs et principes agiles s'incarnent au quotidien ?
  • Que pouvez-vous faire pour renforcer les pratiques agiles ?

Idée reçue n°8 : L'agilité, c'est zéro planification

"Être agile, c'est travailler à la "one again", sans faire de planning ni d'estimation. L'agilité, c'est bon pour ceux qui bossent à l'arrache et qui sont incapables de s'engager sur une date de fin".

Et oui, je l'ai entendu aussi celle-ci. Allez, c'est parti pour un debunkage de plus.

La réalité

La vérité, c'est qu'avec les méthodes prédictives, on a beau faire des plannings et des estimations ultra précises, on se plante la plupart du temps. 

C'est humain : nous sommes tous mauvais pour faire des estimations et des prédictions. Et plus l'échéance est lointaine, plus la marge d'erreur est importante.

Il n'y a qu'à voir les chantiers de construction avec les échéances qui sont repoussées encore et encore, parfois jusqu'à prendre plusieurs années de retard.

Avec l'agilité, on ne prétend pas connaître et prédire l'avenir. On accepte que l'incertitude est tout autour de nous. Plutôt que de faire un plan sur 3 mois ou 3 ans, on se concentre sur le sprint en cours, donc sur la ou les prochaines semaines devant nous.

Et à la fin de chaque sprint, on livre quelque chose. On réduit ainsi le laps de temps nécessaire pour avoir un feedback du client. Et si on se plante (et oui, ça arrive même en agile), on n'attend pas 3 ans pour que le client nous disent que ce n'est absolument pas ce qu'il voulait : on est fixé en quelques semaines.

Mon conseil

Déjà qu'elle n'est pas forcément pertinente avec les méthodologies traditionnelles de gestion de projet, la planification détaillée n'a aucun sens en agile.

Concentrez-vous sur le sprint en cours et sur la valeur que vous pouvez apporter MAINTENANT au client, plutôt que sur une valeur hypothétique que vous pourriez apporter dans le futur.

Idée reçue n°9 : L'agilité, c'est ne pas faire de documentation

"Les agilistes font peut-être bien leur job, mais il n'y a aucune documentation de livrée avec leur produit. Du coup,c 'est inutilisable. On paye cher des personnes qui ont décidé de ne faire que la moitié du boulot".

Encore un mythe bien présent, qui s'explique par une mauvaise interprétation du manifeste agile, notamment de la seconde valeur :

Des solutions opérationnelles, de préférence à une documentation exhaustive.

La réalité

Ce n'est pas l'un ou l'autre au choix : un produit qui fonctionne bien mais pas documenté versus un logiciel bourré de bug mais avec une documentation exhaustive de 3 000 pages.

Le manifeste est clair à ce sujet : bien que les éléments de droite ont de la valeur, nous reconnaissons davantage de valeur dans les éléments de gauche.

Bien sûr qu'une documentation exhaustive a de la valeur et aide le client à s'approprier le produit. Encore faut-il déjà que ce produit soit fonctionnel et réponde aux besoins du client.

Mon conseil

Procédez en deux phases : d'abord la mise en place de solutions opérationnelles, ensuite la rédaction d'une documentation complète.

Attention à ne pas mal interpréter : je ne vous dis pas de développer un logiciel dans son entier avant de fournir la moindre documentation. Ce serait idiot. Mais vous pouvez le faire par fonctionnalité.

Idée reçue n°10 : L'agilité, c'est être rapide

"Pour être agile, il faut aller plus vite que la concurrence et être le premier."

Non, désolé, mais ça ce n'est pas de l'agilité. Vous savez pourquoi ? Car aller vite, cela signifie rogner sur la qualité : on bâcle le travail pour avoir le sentiment d'avancer.

La réalité

Le problème de rogner sur la qualité, c'est que cela génère de la dette technique (des bugs dans un logiciel par exemple). Et cette dette technique ne disparaît pas d'elle-même. Elle continue de gonfler, et va devoir être traitée par l'équipe. 

Au final, cela demande 2 fois plus de temps de faire puis de corriger, plutôt que de faire bien du premier coup.

Faire de l'agilité, c'est avant tout apporter de la valeur au client, donc de produire de la qualité.

Certes, l'agilité vise à réduire le temps de développement d'un produit, mais pas en rognant sur la qualité. Pour réduire le cycle de développement, l'agilité propose de travailler en cycles courts, mais également de suivre un plan et de tester chaque étape de développement d'un produit.

Mon conseil

Ne lésinez jamais sur la qualité, et rédigez votre "definition of done" pour exprimer clairement ce qu'est une fonctionnalité terminée pour l'équipe.

Faites en sorte de minimiser autant que possible la dette technique de votre produit : personne n'aime utiliser quelque chose d'ultra bugué.

Idée reçue n°11 : L'agilité, ça ne fonctionne pas en télétravail

"L'agilité c'est bien beau, mais ça ne fonctionne que si l'équipe se trouve au même endroit. Exit donc le télétravail. Le manifeste agile est clair : il faut privilégier les individus et leurs interactions."

Et bien... Encore raté.

Les interactions ne sont pas limitées lorsqu'on est en télétravail. On peut échanger de la même manière avec ses collègues. S'il faudrait être absolument dans la même pièce pour travailler ensemble, comment expliquer que des entreprises de toutes tailles se développent avec des équipes sur plusieurs sites ?

Ce n'est pas différent du télétravail.

La réalité

Si votre équipe projet est en télétravail ou éparpillée sur différents sites, l'agilité est même à privilégier plus que les méthodes prédictives pour gérer votre projet. 

On perd peut-être les interactions informelles à la machine à café (et encore, depuis le covid, on en a beaucoup moins). Mais l'agilité permet grâce aux réunions collaboratives régulières et aux cycles courts de garder une interaction totale entre les membres d'une équipe.

Mon conseil

Privilégiez la culture de l'écrit lorsque votre équipe est en télétravail ou éparpillées sur plusieurs sites distants.

Réduisez également au maximum la durée des sprints (1 à 2 semaines max). Cela aura pour effet de planifier les réunions qui encadrent les sprints, afin de maintenir le dialogue dans l'équipe.

Ces cérémonies qui permettent la compréhension, la démonstration, l'ajustement et l'amélioration  (plannings, revues, rétrospectives) sont donc plus rapprochées et génèrent plus rapidement du feedback et des actions.

Idée reçue n°12 : L'agilité, c'est la porte ouverte aux clients qui changent d'avis comme de chemise

"L'agilité, c'est parfait pour ceux qui ne savent pas ce qu'ils veulent. Comme on dit oui à tout, c'est la prote ouverte aux changements quotidiens de priorité et aux projets sans fin."

Bon, je vais être clair... Il n'y a pas besoin de l'agilité pour ça. Sur un projet classique, j'ai déjà eu un client comme ça, et ce n'est pas gérable, agilité ou pas.

La réalité

Cependant, l'agilité permet effectivement de réajuster le périmètre projet en cours de route, sans remettre en cause l'intégralité du plan ou l'existence même du projet.

La valeur n°4 est d'ailleurs claire sur le sujet :

La réponse au changement, de préférence au respect d'un plan.

L'objectif de l'équipe agile est d'apporter le plus de valeur possible en un minimum de temps, et de satisfaire le client. Mais cela ne signifie pas dire oui à tout. Il y a une nuance.

Mon conseil

Lorsqu'un client souhaite faire évoluer le périmètre d'un projet, creusez le besoin pour comprendre quelle valeur il souhaite obtenir en réalisant cela, et quelle est la priorité.

Cherchez toujours à négocier : "Ok pour rajouter cette fonctionnalité dans le prochain sprint, par contre ce sera au détriment de telle autre. L'équipe n'est pas extensible à l'infini".

Idée reçue n°13 : L'agilité, ça ne fonctionne pas

"L'agilité c'est du flanc, ça ne marche pas."

Je ne compte plus le nombre de fois où je l'ai entendu. ça et "L'agilité c'est bien en théorie, mais ça ne tient pas en pratique."

Désolé, je vais encore vous contredire.

La réalité

Laissez-moi vous fournir quelques chiffres intéressants, pour vous démontrer que l'agilité non seulement fonctionne, mais à en plus toute sa place dans les méthodologies de gestion de projet :

  • Selon une étude réalisée par PWC, les projets agiles ont 28% plus de succès que les projets traditionnels.

Dans l'enquête 12th Annual State of Agile Report, réalisée par VersionOne en 2017, les personnes interrogées déclarent les bénéfices suivants à l'utilisation de l'agilité :

  • La gestion du changement dans les priorités (71%).
  • La visibilité du projet (66%).
  • L’harmonisation entre l’entreprise et les IT (65%).
  • La vitesse de livraison / le délai de commercialisation (62%).
  • La productivité des équipes (61%).

Mon conseil

Avant de tout rejeter en bloc, pourquoi ne tenteriez-vous pas une expérimentation ? Sans remettre en cause toutes vos pratiques ou changer du jour au lendemain de méthodologie de projet, pourquoi n'essaieriez-vous pas de mettre en place des actions pour intégrer les valeurs et principes agiles à votre quotidien ?

Idée reçue n°14 : L'agilité, c'est travailler de manière moderne

"L'agilité c'est pour ceux qui travaillent efficacement. Les méthodologies de gestion de projet traditionnelles c'est pour les dinosaures."

Je vous l'accorde, l'agilité permet dans certains cas d'être plus efficace. Mais ce n'est pas pour autant que c'est la plus adaptée.

Dénigrez les autres méthodologies de gestion de projet ou ceux qui les pratiquent n'avancent à rien, et n'aident surtout pas à faire adopter l'agilité.

La réalité

Je ne vais pas me faire que des amis, mais en réalité ces deux approches (agilité et méthodes prédictives) sont selon moi complémentaires.

Par exemple, pour piloter un projet de développement informatique, j'aurais tendance à travailler en mode agile avec l'équipe projet.

Mais sur un projet d'infrastructure IT, qui ressemble beaucoup dans la forme à un projet de construction immobilier, les méthodologies classiques sont je trouve plus adaptées. Pourquoi ? Car les étapes sont prédéterminées, certains jalons doivent absolument être respectés pour passer à la suite.

Ces projets prêtent moins bien à l'agilité.

Mon conseil

Mixez le meilleur des deux mondes :

  • Le processus d'initiation de projet dans l'approche agile n'est pas aussi mature que les approches traditionnelles. Vous pouvez vous en inspirer.
  • Les approches traditionnelles sotn bien souvent trop rigides face aux demandes de changements. Intégrez plus de souplesse dans les évolutions du périmètre, et arrêtez de perdre du temps à dresser un planning détaillé sur 5 ans, alors que vous savez pertinemment que dans quelques semaines il faudra le refaire.

Idée reçue n°15 : L'agilité, c'est faire une réunion d'équipe chaque matin

"Dans l'équipe on est agile, on fait une réunion d'équipe chaque matin pour que chacun sache ce qu'il faut faire."

Là, on fait référence au daily standup meeting, l'une des pratiques les plus adoptées de l'agilité.

Mais ce n'est pas parce qu'on réunit l'équipe chaque matin que l'on est agile. Et dans ce cas précis, le brief quotidien durait généralement de 30min à 1h. Et la plupart du temps, la parole était au manager, qui attribuait ensuite les tâches à ses collaborateurs.

Une approche très "Top-Down" donc, et vraiment pas grand chose d'agile.

La réalité

Un daily standup meeting agile  est en réalité une réunion d'équipe cadencée (15 minutes maximum), pendant laquelle l'ensemble des participants doivent répondre aux 3 questions suivantes :

  1. Qu'est-ce que j'ai fait hier ?
  2. Qu'est-ce que je vais faire aujourd'hui ?
  3. Qu'est-ce que j'ai comme problème ?

L'objectif n'est ni de résoudre en live les problématiques, ni d'attribuer les tâches.

Pour aller + loin : Je vous invite à lire l'excellent article de Clément Rochas sur le sujet : "Non, le daily standup meeting ce n'est pas ça !"

Mon conseil

Appliquez les bonnes pratiques pour mener votre Daily Standup Meeting :

  • 15 minutes maximum.
  • Tout le monde debout ET devant un tableau (on parle de Scrum Board le plus souvent)
  • Chacun prend la parole, ce n'est pas un outil de communication verticale.
  • Il s'agit d'un moment d'échange et de partage, et chacun doit y trouver un intérêt.
  • C'est une réunion de l'équipe, pour l'équipe, par l'équipe. Le manager et le scrum master n'ont pas à monopoliser la parole.

L'agilité n'est pas la solution miracle à tous les problèmes

Bien que l'agilité dispose de nombreux avantages, ce n'est pas la réponse à tout. Certains projets sont plus adaptés que d'autres à l'utilisation des méthodes agiles.

On ne doit pas choisir de faire de l'agilité pour faire de l'agilité, ça ne rime à rien. Une transformation agile doit se faire pour atteindre un objectif précis : mieux satisfaire les clients par exemple.

Si vous souhaitez devenir une entreprise agile, ou renforcer les pratiques agiles dans votre organisation, je vous conseille la lecture de mon guide pour bien réussir vos transformations agiles.

Je vous conseille également de commander quelques uns de ces livres sur l'agilité, pour creuser les concepts passionnants autour de l'agilité.


Thibault Baheux

Chef de projet IT depuis 2008, j'ai travaillé sur des projets à plusieurs millions d'euros.
J'ai décidé de dépoussiérer la gestion de projet.
Exit les méthodologies complexes, exit les outils lents, lourds, complexes à utiliser.
Mon objectif ? Vous donner les clés pour piloter vos projets avec efficacité.


Articles Similaires


Cet article vous a plu ? Dites-le nous !

Votre adresse mail est et restera confidentielle. Les champs avec une astérisque (*) sont obligatoires.

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