Les méthodes agiles sont moins efficaces que les méthodes prédictives!

Management
1

Sous ce titre à priori provocateur, je souhaite apporter quelques précisions.

Les méthodes dites prédictives (cascade, cycle en V ou W, etc.) sont décriées depuis le fameux rapport « Chaos Report » du Standish Group : Les 2/3 des projets informatiques échouent.
Chiffre confirmé par plusieurs autres rapports.

Fort de ce constat, les agilistes n’ont eu de cesse de mettre en avant les méthodes agiles comme alternative absolue pour résoudre ce problème.

Or, en 2010, le groupe Evans Data a réalisé une étude auprès de 1200 développeurs dans le monde.

Résultat : non seulement les méthodes agiles ne font pas mieux que les autres méthodes, mais en plus le taux d’abandon sur les projets en mode agile est supérieur par rapport aux méthodes décriées.

Pourquoi ce post ?
Je suis un fervent utilisateur de méthodologies empiriques quelles soient agiles ou non (ITIL, CMMI, Prince2, IPMA, PMI, Hermes, Scrum, Agile PM, ISO 21500, Lean, BPM, etc.) et après 15 ans d’exp j’en viens au constat suivant qui peut expliquer ces taux d’échecs:

Aucune méthode ne supplante les autres, tout est histoire de contexte, d’environnement, de parties prenantes, de besoin plus ou moins exprimé, etc.

Seule la maitrise de plusieurs méthodes et connaissances de divers environnements permet de choisir le ou les bonnes méthodes à appliquer (nous allons de plus en plus vers le mix méthodologique).

Se cantonner à une seule (l’agile en l’occurrence) parce que le discours ambiant explique que c’est la meilleure voie est à mon avis une erreur.

Non seulement c’est faux, preuve à l’appuie, mais en plus ceci enferme dans une seule vue d’un monde bien trop complexe.

Pas de volonté de polémiquer ou de prêcher pour une quelconque paroisse… j’utilise toutes ces méthodes (agile ou non) depuis plusieurs années.

Voilà pourquoi je vous renouvelle mon conseil : s’investir dans plusieurs méthodologies est la voie de la réussite.

Sources :
Chaos report 2014 : http://www.projectsmart.co.uk/docs/chaos-report.pdf
Evans Data report : http://www.lemagit.fr/actualites/2240196765/Developpement-seulement-36-des-projets-livres-dans-les-delais

4 « J'aime »
2

Hello,

Le principal avantages des méthodes agiles est justement celui ci : Pouvoir s’arrêter avant qu’il ne soit trop tard. Même si celà peut paraitre modeste, les méthodes agiles ont au moins eu cet avantage : Faire comprendre qu’il est preferable parfois de s’arrêter plutôt que d’insister dans une impasse (office national de paye : 350mns d’euros d’après la cour des comptes, projet abandonné).
Du coup, cette interprétation ne me parait pas correcte pour juger de la supériorité d’un type de méthode sur un autre. Savoir s’arrêter à temps est une grande qualité, prendre en compte ses échecs et repartir en est une autre.
Donc oui, les projets agiles abandonnent plus souvent que les autres, et c’est même une bonne chose :wink:

1 « J'aime »
3

Rien n’est jamais gravé dans le marbre.

Quel que soit le projet dans lequel on se lance et quel que soit la méthode (y compris à la one again), il est possible de s’arrêter à n’importe quel moment (le GO/NO GO n’est pas exclusif à l’agile).
Il y a une méconnaissance des méthodes pour avancer cet argument.

Donc il ne s’agit pas là d’un « avantage »: ce n’est pas la méthode qui décide mais les hommes et les femmes qui l’appliquent.

Par expérience (je fais de l’agile depuis 7 ans), les causes d’abandon en agile sont plus graves que ça et sont principalement dues à 2 raisons:

  • Le manque de visibilité long terme
    Comment intégrer ce qui est fait dans la stratégie entreprise? … car extrêmement rare sont les études d’opportunité et de faisabilité sur les projets agiles. Du coup, difficile de défendre ça lorsqu’il y a arbitrage dans un portefeuille de projets.
  • L’épuisement de budget avant un résultat probant pour négocier un budget complémentaire.

Bien évidement il y a des abandons pour des raisons justifiables (comme les impasses), mais pas plus qu’ailleurs.

1 « J'aime »
4

C’est potentiellement un point positif ça :wink:

5

Bonjour,

Travaillant dans le secteur du numérique depuis plus de 20 ans, avec une pratique d’une trentaine d’années, je crois que je peux dire que j’en ai vu des choses, beaucoup même…

J’ai travaillé sur de nombreux projets, dans différents domaines, des petits ou des gros, seul ou avec de nombreuses équipes, dispersées ou réunies, …

Je partage globalement la position de @Aka74 au sujet des méthodes et du résultat final, qui comprend bien sûr les coûts et les délais.

Je dit d’ailleurs souvent, trop souvent même que 60% des projets IT (numérique) dépasses de plus de 60% les délais et les coûts (budgets).

A cela plusieurs raisons, les outils, la méthode, l’organisation, … et surtout l’humain.

Chacun y va de son petit argument pour son outil, sa méthode… mais, en fait ce qui compte c’est la satisfaction de l’utilisateur, car à la finale d’une manière ou d’une autre c’est lui qui tient les cordons de la bourse, le carnet de chèque. Après bien sûr, il faut considérer les responsabilités au bon niveau, car il y’a dans une équipe des exécutants et des managers (responsables).

Pour ma part, il n’y à pas de méthodes meilleurs qu’une autres, il y’a des méthodes qui sont des outils au services des équipes en charge de concevoir et réaliser un système qui doit satisfaire les besoins des utilisateurs. Encore faut-il savoir utiliser la ou lesdites méthodes à bon escient.
Par expérience le tout UML, le tout ITIL, ou le tout COBIT ne rime à rien, elle sont juste là pour tracer une voie que les équipes doivent suivre, et ce qui compte avant tout c’est l’objectif final.

Dans un projet et plus particulièrement un projet IT innovant les aléas sont grands.

De nombreux projets ont été abandonnés ou ont faillis êtres abandonnés, parce que trop gros, trop complexe, … et finalement trop coûteux.

Pour finir, je voudrais pour les plus jeunes qui n’ont pas connus expliquer certaines choses, du temps ou c’était les débuts de l’informatique personnel. Si si et c’était y a pas si longtemps… je ne suis pourtant pas un papy, mais bon.
Ainsi, quand j’ai commencé a faire du développement sur Thomson TO7 ou ZX Spectrum, nous n’avions que quelques KO de mémoire à gérer pour nos programmes et données. Contre les méga-octets ou giga-octets dont on peu disposer aujourd’hui. A l’époque la mémoire coûtais extrêmement cher, il fallais donc trouver des solutions. Certes nous n’étions pas dans un cadre professionnel mais, tout de même.
Le Thomson TO7 fonctionnais avec un lecteur de cassette et nous pouvions utiliser une fonctionnalité du langage de programmation que sont les overlays.

Vous ne vous imagineriez certainement pas aujourd’hui faire des overlays pour vos développements.

Et pourtant nombre d’applicatifs, sont lent, fastidieux à utiliser, plante, … et tout ça à cause d’une très mauvaise gestion des allocations de ressources. Et c’est pas une question de langage, d’outils ou de méthode !