En effet, l’un des buts principaux de l’agilité est de marier aussi étroitement que possible la technique, le fonctionnel et le commercial afin de parvenir à délivrer le plus rapidement possible un produit apportant un maximum de valeur ajoutée au client.

En clair, l’agilité permet de passer d’un jeu individuel à un jeu collectif.

Ainsi, tout le monde est alors responsable et doit donc en conséquence faire de son mieux pour parvenir à atteindre l’objectif.

Alors que dans un cadre plus traditionnel, le commercial, le fonctionnel (qui ne fait souvent qu’un avec le commercial), le chef de projet et les développeurs se passe successivement la responsabilité du projet.

Et fort logiquement, c’est forcément les développeurs qui portent finalement l’intégralité de la responsabilité, d’autant que les trois premiers font tout leur possible pour leur passer le plus rapidement possible afin de couvrir leurs fesses.

En effet, puisque statistiquement, 80 % des projets sont des échecs, ils ont tout intérêt à se débarrasser le plus rapidement possible de ceux qui leur sont confiés afin de ne pas porter le chapeau en cas de problème.

Le commercial a de plus une motivation supplémentaire pour se débarrasser de cette responsabilité du projet le plus rapidement possible, puisqu’il est commissionné sur le montant de la vente lors de la signature du contrat.

Il a donc tout intérêt à faire signer le client le plus rapidement possible, car il fait d’une pierre deux coups : il se débarrasse de la responsabilité et il engrange la monnaie !

Le chef de projet doit de son côté repasser le bébé le plus rapidement à ses développeurs afin de pouvoir collecter le plus rapidement possible les métriques qui lui permettront de démontrer par sin (A + B) * cos(π) que ses développeurs sont responsables des retards malgré tous ses efforts.

Dans un cadre agile, les choses sont très différentes.

Tout d’abord, le commercial et le fonctionnel sont contraints de faire un travail de fond beaucoup plus important, pour qualifier correctement les besoins du client fonctionnellement et en terme de valeur ajoutée.

Cela suppose donc de discuter avec le client et surtout de le forcer à prendre conscience précisément de son besoin, ce qui est loin d’être facile.

Il faut en effet faire usage de psychologie pour ne pas le froisser et prendre suffisamment son temps pour ne pas qu’il se décide à la hâte pour se débarrasser de ce problème épineux quitte à faire par la suite sans cesse la girouette.

Il devient de plus nécessaire d’emmener un technicien en avant-vente, afin de savoir précisément ce qu’il est possible de faire techniquement parlant, afin de ne pas vendre du rêve au client.

Tout cela prend donc du temps et il faut de plus trouver un client qui comprenne et accepte la démarche, ce qui n’est pas si courant par rapport à ceux qui griffonnent un « cahier des charges » sur un morceau de nappe entre la poire et le fromage durant le repas offert par le commercial pour boucler l’affaire.

Les délais sont donc allongés, ce qui veut dire que le commercial n’aura pas sa commission aussi vite qu’en dehors du cadre agile.

Pire, certains qui n’avaient rien à faire dans un cadre traditionnel se retrouvent alors à devoir travailler et même à devoir assumer leur choix, puisque les développeurs ne peuvent plus être les coupables désignés par défaut du moindre aléas sur le projet.

De plus, dans un tel cadre, la notion hiérarchique devient rapidement très floue, et il arrive très souvent que les « mâles alpha » le vivent très mal.

Un chef de projet peut ainsi se sentir dépossédé de ses prérogatives, tandis qu’un patron qui n’a alors plus la possibilité d’imposer son rythme ou sa vision des choses peut avoir l’impression de perdre le contrôle.

Si l’on ajoute à tout cela le fait que le dialogue entre le client et l’équipe chargée du projet doit perdurer tout au long de sa réalisation, l’agilité peut être perçue comme une contrainte et non comme un avantage aux yeux de ceux qui n’en tirent finalement aucun avantage personnel malgré une responsabilité plus importante, une charge de travail augmenté et des avantages monétaires plus espacés dans le temps.

Car fondamentalement, au contraire des développeurs bien souvent habitués à travailler collectivement car la nature même de leur métier les y incitent, les commerciaux, les fonctionnels et même les chefs de projet sont fondamentalement des travailleurs individuels qui n’ont pas du tout l’habitude de s’inscrire dans une dynamique collective.

L’utilisation de l’agilité suppose donc une grosse remise en question de leur façon de travailler, et entre la résistance naturelle de l’Humain au changement et les problèmes d’ego ou de caractères, elle devient bien souvent finalement plus un problème qu’une solution.

Les personnes dans ce cas cherchent alors à contourner la philosophie agile plus ou moins ouvertement, afin de retrouver leur confort antérieur.

En clair, elles recommencent à jouer individuellement plutôt que collectivement, mais comme tout pratiquant de sport collectif le sait bien, il suffit d’un individualiste dans une équipe pour l’empêcher de marquer.

L’échec du projet à plus ou moins court terme est alors inéluctable.

De là à dire que l’agilité ne fonctionne pas et qu’elle est donc vouée à disparaître, il n’y a qu’un pas, et ce pas est d’autant plus facile à franchir qu’une fois que cette idée aura fait son chemin, il sera alors possible de revenir aux méthodes traditionnelles, tout aussi inefficaces, mais tellement plus confortables à tout point de vue pour les individualistes.

Ce n’est donc pas le fait que l’agilité soit une mauvaise méthode qui causera la perte de l'esprit agile.

Si ce dernier doit disparaître, c'est parce que les intérêts individuels seront parvenus à garder le dessus sur l’intérêt collectif.