Une pratique qui attise l’intérêt des principaux acteurs de la vie économique mondiale mérite que l’on s’y intéresse. Lorsqu’elle apparaît comme le postulat d’une différentiation stratégique, on s’y attarde. Et lorsqu’elle représente la capacité à maintenir la compétitivité des entreprises dans un environnement changeant, on l’adopte. Cette pratique, c’est l’agilité, qui s’est invitée depuis plusieurs années dans les méthodes de gestion de l’industrie, du commerce, de l’administration ou encore de l’informatique.
Il n’est pas aisé de trouver une définition commune à la notion de l’agilité car la pratique se décline en un ensemble de méthodes dites « agiles » adaptées à chaque domaine. Par exemple, dans une vision purement économique, l’agilité est la capacité d’offrir à la clientèle des produits et des services sur mesures quel que soit l’élargissement ou le durcissement des environnements concurrentiels. Il existe néanmoins un socle des pratiques communes aux différentes méthodes qui repose sur deux caractéristiques essentielles : la capacité à insuffler la réactivité et la performance à l’organisation ; la capacité à apporter des réponses concrètes à la résolution de problèmes complexes. Le champ d’application de l’agilité est donc très vaste du moment où elle contribue à résoudre la complexité.
L’existence d’un socle commun ne doit néanmoins pas laisser croire à une quelconque interopérabilité des méthodes agiles entre les différents domaines d’application. L’agilité dans la vision informatique se différencie radicalement par ses méthodes des pratiques inspirées et appliquées dans le commerce, dans l’administration ou dans l’industrie.
Le présent article traite de la vision informatique de l’agilité et s’efforcera dans un premier temps d’en présenter l’essence. Les vertus attendues, prouvées ou non, seront ensuite mises en exergue avant que leur soient opposées les principales critiques ou limites.
I. La crise des systèmes d’information à l’origine du courant de pensée « agile »
Les systèmes d’information sont emportés par un mouvement de transformation historique des technologies. C’est la raison pour laquelle, par époque, les cohérences de l’urbanisation des systèmes d’information et informatiques ne sont pas les mêmes. Le passage d’une cohérence à une autre se traduit par l’élaboration de nouveaux processus opérationnels, de nouvelles méthodes de travail voire de nouvelles philosophies de management. J’ai nommé cette transformation la « crise des systèmes d’information ». Le concept de crise dans ce contexte fait référence à la fin d’une époque, avant l’ouverture du processus incertain qui conduit à une autre époque, celles de nouveaux processus censées améliorer les précédentes.
Jusqu’au début des années 1990, les méthodes ou principes de gestion de projet reposaient essentiellement sur une approche de type séquentiel ou cycles de vie prédictifs, aussi appelés « totalement planifiés ».
Les volontés de rupture avec cette approche commencèrent à émerger dès le début des années 1980 sous le prétexte que le système en cours était en voie d’atteindre ses limites. C’est ainsi qu’en 1986, un modèle de développement itératif et incrémental fut élaboré par Barry W.
Les études empiriques ont fait la lumière sur les causes des échecs des projets
Il a fallu attendre la publication en 1994 par le Standish
Cette publication annuelle est devenue une référence même si elle a été critiquée par quelques travaux de recherche. Ses résultats sont, malgré tout, régulièrement repris dans la presse spécialisée et dans des livres consacrés aux moyens d’améliorer la réussite des projets. Au-delà de ces critiques, elle a le mérite de s’inscrire dans la continuité et de n’avoir toujours pas en face une publication concurrente sérieuse. Seuls l’Observatoire des projets
Entre 1994 et 2012, les Chaos Report ont montré que le taux de succès des projets était seulement de 30 % en moyenne pendant que près de 24 % des projets étaient abandonnés et que 46 % se terminaient avec un dépassement des charges ou des délais. Si on considère la période 1994-2000, le taux de succès des projets était en moyenne de 24 % et 31 % des projets étaient simplement abandonnés.
Ces mauvais résultats avaient plusieurs causes qui ont été progressivement mises en lumières, fournissant ainsi aux experts des pistes de réflexion pour tenter de remédier aux défectuosités qui sont à l’origine de ces échecs. Les principales causes remontées portent essentiellement sur l’instabilité des environnements technologiques, sur le fait que beaucoup de fonctionnalités sont souvent implémentées alors qu’elles ne serviront jamais et aussi sur le fait que dans les relations de type client-fournisseur, le client est souvent dans l’incapacité d’exprimer ses besoins et exigences de manière exhaustive dès le début des projets.
L’unification des méthodes agiles pour améliorer le développement logiciel
La mise en lumière des facteurs d’échecs a ouvert la voie à de nouvelles réflexions basées sur l’optimisation des processus opérationnels et sur une meilleure urbanisation des systèmes informatiques. La mise en œuvre de ces nouveaux processus n’est devenue vraiment une réalité qu’à partir de 2001 lorsqu’aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites « agiles ».
De cette réunion, une définition canonique du développement agile et de ses principes sous-jacents fut consignée dans ce qui fut baptisé le Manifeste agile. Ce document débute par la déclaration suivante : « Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait, nous avons déduit des valeurs communes. » Le manifeste prône quatre valeurs fondamentales (l’équipe, l’application, la collaboration, l’acceptation du changement) axées sur une vision plus pragmatique de la conception de logiciels et sur un effort centré plus particulièrement sur la satisfaction réelle des besoins du client, et non celle des termes d’un quelconque contrat de développement. Les principes de cette nouvelle philosophie de gestion de projet sont édictés à travers quatre oppositions entre concepts traditionnels et nouveaux concepts : la préconisation est de se focaliser sur les « individus et interactions », le « logiciel fonctionnel », la « collaboration avec le client » et la « réaction au changement », plutôt que, respectivement, les « processus et outils », la production d’une « documentation complète », la « négociation de contrat » et le « suivi d’un plan ».
Comprendre les fondements de la pensée agile et ses principes sous-jacents
Au-delà du modèle conceptuel imaginé par les experts, il importe de se pencher sur son application dans les projets de la vie réelle.
La connaissance méthodologique ne suffit pas à bien gérer un projet ni à devenir un bon chef de projet. Il est nécessaire de lui adjoindre ce qu’on appelle la performance, c’est-à-dire, l’application de cette connaissance, autrement dit, ce que le chef de projet est capable d’accomplir en appliquant ces connaissances. Cette performance ou compétence représente l'« épine au pied » dans l’application de la démarche agile, non pas à cause d’une quelconque complexité liée à l’exécution des règles édictées dans le manifeste agile, mais plutôt à cause des fondements mêmes de la pensée. Par fondements, on fait référence ici à trois éléments qui caractérisent les méthodes agiles : l’incertitude, l’expérimentation et l’adaptation.
À la base de la réflexion, il y a ce qu’on appelle l’incertitude qui est basée sur deux postulats :
- dans un projet, on ne sait pas exactement et au détail près ce qu’on doit faire ni ce qu’on espère obtenir au final ;
- on sait tout ce qui doit être fait et au détail près, mais pas exactement ce que l’on va faire ou ce que l’on peut faire.
Ensuite, vient le principe d’expérimentation considéré comme une façon d’avancer sans vision claire sur la cible. C’est une conséquence de l’incertitude en ce sens qu’il s’appuie sur la valorisation des essais et des erreurs, donc sur des logiques de prototypage, pour valider le logiciel tout au long du cycle de vie.
Enfin, le principe d’adaptation (ou l’adaptabilité) est le fait que la démarche permet de revoir, corriger et ajuster à tout moment les priorités déjà établies à la fois directement au niveau des produits et services mais également des processus d’élaboration de ces produits et services. L’adaptabilité s’apparente au principe de correction de trajectoires connu dans le domaine de la balistique pour les missiles et batteries antimissile. On peut tirer des missiles sans avoir à faire de puissants calculs a priori, la correction se fera chemin faisant.
Dans la gestion de projets, les corrections ou ajustements à opérer sont déterminés grâce au feedback ou boucle de retour des clients à l’issue de chaque phase de test.
Ne pas confondre agilité et management de projet
« Le management de projet, c’est l’application de connaissances, des compétences, d’outils et techniques aux activités d’un projet afin d’en satisfaire les
Les méthodes agiles proposent un ensemble de processus qui visent à accélérer le cycle de développement d’un logiciel ou d’un service. Les caractéristiques itératives, adaptatives, incrémentales, etc. ne sont que des propriétés dérivées de cet objectif initial de réduction du cycle de vie du logiciel. Par conséquent, les méthodes agiles sont des outils au service de l’activité plus globale de management de projet.
La confusion entre l’agilité et le management de projet est le résultat d’une méconnaissance manifeste de la démarche agile notamment et malheureusement de certains cadres dirigeants qui vont jusqu’à considérer cette méthode comme une manière de « faire plus vite et moins cher ». De ce fait, il y a une tendance à privilégier par défaut les démarches agiles, quelle que soit la nature ou la taille d’un projet à réaliser, alors que, comme nous le verrons plus tard dans ce document, la démarche agile est inadaptée à certains types de projets.
La vertu attendue de l’agilité est l’amélioration de la valeur client
Dans une vision globale de la relation client-fournisseur, la définition classique de la valeur des prestations pour le client est donnée par l’expression : « Le bon produit pour le bon prix et au
Le bon produit a exactement les fonctionnalités attendues par le client. Ce qui veut dire que si vous faites de la « sur qualité » (Gold plating), vous ne respectez pas ces exigences. La notion de bon ou de juste prix est assez subjective, car elle est basée sur la croyance du client et du fournisseur que ce prix correspond à la transaction, prix pour lequel le client est prêt à payer et le fournisseur prêt à vendre. Le bon moment, c’est l’échéance fixée par le client pour exercer son droit de jouissance du produit ou service pour lequel il a payé.
La conjonction de ces trois éléments vise donc à assurer le bénéfice que va percevoir le client, non seulement en atteignant le but pour lequel le produit a été acquis mais également pour avoir été associé au processus de fabrication du produit et à sa personnalisation.
Dans les démarches traditionnelles, le client est surtout impliqué dans la phase de démarrage du projet pour l’expression détaillée des besoins et dans la phase de planification, c’est-à-dire avant la conception et la réalisation, pour la validation des spécifications. Ensuite, il doit attendre la fin du processus de réalisation pour recevoir la solution et effectuer la recette. Il y a donc un effet tunnel qui peut être néfaste et conflictuel dès qu’un déphasage est constaté entre le besoin initial et l’application réalisée.
L’approche agile propose au contraire de réduire considérablement, voire complètement, cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début jusqu’à la fin du projet et en adoptant un processus de développement itératif et incrémental dont l’avancée repose sur des validations successives du client et son feedback régulier tout au long du cycle de vie du produit.
II. Les limites des démarches agiles
Cet article soulève d’importantes limites non exhaustives des démarches agiles. Il existe tout d’abord une limite idéologique fondée sur des idées préconçues. L’inadaptabilité à certains types de projets constitue une seconde catégorie de limites. Mais les principales limites sont structurelles et liées à l’application de certains principes fondamentaux de l’agilité.
La limite idéologique
La limite idéologique est la croyance non prouvée à un remède universel contre les échecs chroniques des projets de développement logiciel. Comme tout nouveau système, le processus agile n’a pas échappé à la spéculation idéologique sur ses présupposées vertus. L’engouement qu’il suscite devient naturellement propice à la prolifération d’un certain nombre d’idées reçues qu’il convient de balayer si l’on veut donner à l’agilité la place qui lui revient et pour laquelle elle a été créée.
En effet, la croyance qui s’est généralisée depuis quelques années dans l’industrie informatique est celle qui considère le processus agile comme le remède universel contre les échecs chroniques des projets de développement logiciel. Que vous soyez en mode projet ou en maintenance, l’expression maîtresse des responsables informatiques est toujours l’agilité. Il est vrai que le processus agile facilite la réalisation des petits projets. Il est également vrai qu’il facilite la décomposition des grands projets en une série de petits projets. En ce sens, et en tant qu’outil au service du management du projet, il joue pleinement son rôle. En revanche, le considérer comme remède miracle contre les échecs des projets revient à vouloir qualifier l’antibiotique comme la solution thérapeutique à toutes les maladies.
En se référant aux statistiques disponibles, rien ne démontre à ce jour de façon empirique une supériorité globale des méthodes agiles sur les processus classiques de développement logiciel.
Sans disposer de chiffres réels, plusieurs affirmations avaient été avancées, jusqu’à une période très récente, pour dire que les projets gérés selon l’approche agile connaissaient moins d’échecs et de dérives. Aucune critique véritable ne pouvait alors être formulée à l’encontre de ces affirmations sans tomber aussi dans les travers d’une déclaration infondée et dénuée de toute substance empirique.
L’éclairage apporté par les premières études statistiques
Le Chaos Report 2013 du Standish Group a apporté un éclairage partiel à ce débat en présentant les résultats d’une étude comparative sur une période de 10 ans des taux de réussite et d’échec des petits projets, selon qu’ils utilisent une démarche en « cascade » ou une approche agile. Les projets comparés sont ceux dont le coût global de développement n’excède pas un million de dollars.
Les résultats (voir Tableau 1) ont montré que contrairement à ce qui est souvent affirmé, le recours aux démarches agiles n’améliore pas significativement les taux de succès des projets. On observe même étonnamment que le modèle en « cascade » a non seulement un taux de succès supérieur à la démarche agile, 49 % contre 46 %, mais également qu’il dérive moins, 43 % contre 48 %. Seul le taux d’échec ou d’abandon définitif du projet est légèrement plus élevé pour le modèle en cascade, 8 % contre 6 %.
Ce résultat est venu conforter une autre étude réalisée en 2010 par le groupe Evans
Bien évidemment, cet échantillon faible ne peut servir de preuve pour annoncer une quelconque supériorité d’une méthode par rapport à une autre. Ce qui est important, c’est la prise de conscience qu’une telle étude peut créer pour nous conduire à une réflexion raisonnée dans nos choix de méthodes en matière de gestion de projets.
Rôle de l’agilité dans l’amélioration des taux de réussite des projets depuis 2010
Si l’on se réfère toujours au rapport annuel Standish Group, l’un des points notables ces dernières années est l’augmentation du taux de réussite des projets même si jusqu’en 2014, il reste toujours en deçà des 40 %.
Le constat est que, même si plus de 60 % des projets sont abandonnés ou se terminent avec un dépassement des charges ou des délais, il y a effectivement une légère embellie mais contrairement aux idées reçues, l’agilité n’est pas le facteur déterminant de cette situation. Le rapport 2013 montre que sur les petits projets, l’apport des méthodes agiles ne vient qu’en sixième position après d’autres critères comme le support du management au projet, l’implication des utilisateurs, l’optimisation, les compétences des ressources et l’expertise en management de projet.
L’inadéquation des démarches agiles à des projets gigantesques
Le passage à l’échelle, c’est-à-dire, l’augmentation de la taille de l’équipe et donc du nombre d’intervenants constituent une des principales difficultés des démarches agiles. La problématique est de savoir comment passer d’une équipe de 10 personnes à plusieurs dizaines voire centaines de personnes et d’être capable d’appliquer les mêmes règles de fonctionnement.
Avec un nombre important d’intervenants, les possibilités de discuter en face-à-face sont limitées, les logiques d’itération, avec leurs principes de feedback, peuvent apporter beaucoup de confusions obligeant au final à lisser les itérations, voire à les supprimer pour tendre vers une logique de flux. L’explication de ce phénomène est triviale. Dans une logique d’itérations avec des sous-phases d’une durée de deux à trois semaines, la synchronisation nécessaire entre les individus (que ce soit dans l’équipe de développement ou avec le client) deviendra difficile au point de remettre en question le rythme préétabli des itérations.
Certains diront que la démarche agile facilite le découpage de grands projets en petits projets de taille raisonnable. À concéder cette vérité, l’hypothèse d’un découpage multiple n’ajoute-t-elle pas de la complexité à quelque chose qui est déjà complexe ?
La conséquence est une tendance presque forcée de l’agilité vers le Lean Management. Ceci conduisit d’ailleurs les « agilistes », partisans de l’agilité, à considérer une déclinaison spécifique du Lean Management, le « Lean start-up », comme une évolution naturelle de la démarche « agile ».
Cette tendance Lean conduit à un problème plus profond qui va au-delà des simples règles à appliquer pour conduire un projet. À l’origine, le Lean a été créé pour lutter contre le gaspillage, optimiser le travail afin d’augmenter la productivité et par là, la production. Pour l’appliquer dans un projet de système d’information, il faut évidemment isoler ce qui est gaspillage de ce qui ne l’est pas, quelle que soit la méthode utilisée (traditionnelle ou agile). L’enjeu n’est donc plus de choisir entre le processus agile et les méthodes traditionnelles, mais entre le Lean et ces deux processus.
Le vrai enjeu consistera au final d’inscrire l’agilité (de court terme) dans la logique Lean (de moyen et long terme) en évitant trois choses :
- la prolétarisation (perte de savoirs) qui est reprochée à la démarche Lean ;
- tomber dans les travers des méthodes traditionnelles que l’agilité rejette ;
- perdre sa substance en se laissant submerger par les principes Lean.
Les limites structurelles dans l’application de certains principes fondamentaux
Les démarches agiles ont atteint leurs limites structurelles dans l’application de plusieurs de leurs principes de base. En voici une liste non exhaustive de six limitations.
La trop forte dépendance au client
Le processus agile requiert une disponibilité constante et entière du client qui doit être prêt à s’impliquer à tout moment au projet. Plus que disponible, le client doit être « du métier », ce qui est synonyme d’efficacité. Un client efficace est une force de proposition fonctionnelle au fait du détail et de la réalité du processus métier.
Qu’adviendra-t-il si le client n’est pas « du métier » ou si l’équipe n’est pas homogène (conflits entre les développeurs qui travaillent en binôme par exemple) ? Vraisemblablement, une dérive ou un échec du projet.
On pourra, à juste titre, dire que ceci posera le même problème dans une méthode traditionnelle mais le fait est que contrairement aux méthodes traditionnelles, la participation du client dans tout le cycle d’implémentation du produit est imposée par l’agilité et considérée comme condition de réussite des projets.
Le non-respect des cadres organisationnels
Les méthodes agiles remettent en cause le mode d’organisation hiérarchique au profit d’un fonctionnement collaboratif. Il est donc évident que la résistance au changement sera exacerbée lorsqu’on se trouve dans des sociétés où l’attachement à la structure hiérarchique est fort.
Les cadres organisationnels et réglementaires sont généralement mis en place en conformité avec les stratégies globales d’entreprise. Ils ont souvent nécessité plusieurs années pour être définis. La mauvaise application des principes de l’agilité pousse certains à contourner voire ignorer ces cadres et méthodes en place dans une entreprise sous prétexte de leur lourdeur. Or, constituant la richesse de l’entreprise, c’est grâce à ces cadres que des actifs organisationnels solides peuvent être mis en place (plans, processus, politiques internes, procédures et bases de connaissances, etc.). C’est également grâce à ces cadres que des facteurs environnementaux de l’entreprise sont consolidés (culture, codes de conduite, normes de fabrication, disciplines et connaissances, systèmes d'information de gestion, etc.)
Ainsi, plutôt que d’ignorer ou contourner ces cadres, le processus agile peut s’intégrer parfaitement dans le schéma existant et profiter de cette richesse pour s’accomplir encore mieux.
Les limites du mode itératif et de l’acceptation des changements
L’agilité fonctionne sur la motivation des ressources humaines. Si le projet est mal appréhendé par les utilisateurs, la résistance au changement sera forte et le mode d’organisation agile sera dur ou plus long à mettre en place.
Le mode itératif peut atteindre rapidement ses limites lorsqu’on fait prévaloir le « faire plus vite et moins cher » au détriment de la qualité. Prenons l’exemple d’un produit dont la réussite repose en grande partie ou essentiellement sur son ergonomie. La mise en œuvre de ce type de produit peut nécessiter des phases de conception et de réalisation assez longues, et mécaniquement des coûts plus élevés.
La démarche qui consiste à définir au fur et à mesure de nouvelles fonctionnalités pour alimenter les itérations ne sera pas forcément efficace dans un tel projet. Cette remarque rejoint d’ailleurs une des principales critiques formulées depuis longtemps à l’encontre de l’agilité, à savoir, son inadéquation aux projets de ruptures qui exigent des innovations révolutionnaires (cf. Takeushi et Nonaka – 1986).
La difficile contractualisation d’un projet agile
Dans l’optique agile, on ne peut pas se contenter de négocier un contrat en début de projet puis de ne travailler que sur cette base. Le client devant être impliqué et devant collaborer avec l’équipe afin de fournir un feedback continu sur l’adaptation du logiciel à ses attentes, ceci va avoir des impacts sur les clauses contractuelles. De ce fait, la contractualisation devient un des éléments complexes du processus agile. Faut-il appliquer un contrat au forfait ou en régie ? Aucun ne semble vraiment complètement adapté… Il faut donc s’armer d’ingéniosité pour imaginer des variantes de l’un ou l’autre type de contrat, voire inventer de nouveaux types de contrats. C’est ainsi que furent proposés la technique de forfaitisation de chaque itération ou encore le principe de troc d’exigences.
La première technique donne au client la possibilité d’arrêter le contrat à la fin de chaque itération. Quant à la seconde technique, elle permet au client de demander la réalisation d’une exigence imprévue en échange du retrait d’une autre moins importante, de priorité faible et de même coût.
Nous ne sommes donc plus dans des contrats standards mais des pseudo-montages spécifiques à chaque contexte de projet. Si on ajoute à cela les techniques d’estimation de charges aussi très spécifiques aux démarches agiles, on complexifie, bien évidemment, encore plus la mise en œuvre d’un contrat type.
Le niveau de documentation variable ou manque de documentation suffisante
Une mauvaise interprétation des principes agiles a fini par créer une faiblesse de la méthode. La démarche stipule qu’un document ne doit être produit que s’il s’avère nécessaire au projet. Ce qui est au fond une très bonne chose et un clin d’œil au Lean management dans son principe de lutte contre le gaspillage. En revanche, ce principe qui aurait dû être fondamental a été malheureusement interprété comme une règle préconisant de ne produire qu’une documentation minimale voire presque pas de documentation du tout. En ce sens, et de par ses conséquences, le manque de documentation est devenu un des inconvénients majeurs des méthodes agiles. À trop vouloir prioriser les logiciels opérationnels par rapport à une documentation exhaustive, on a fini par ne plus respecter les normes internes sur la qualité de la documentation. Ce qui est produit finalement est de niveau variable et donc non standard.
Deux conséquences majeures découlent de cette situation : la difficulté en phase de maintenance logicielle lorsque le projet doit être pris en charge par une autre équipe et la difficulté d’exécuter une clause contractuelle de réversibilité (transfert de la solution logicielle à une autre société).
Le manque de vision d’avenir
Lorsqu’on œuvre dans une logique d’adaptation avec de multiples itérations sur des périodes très courtes de l’ordre de 2 à 3 semaines en vue de produire rapidement un produit, un service ou un résultat, il est évident qu’on opère et raisonne dans le court terme. Cette vision n’est pas adaptée à une logique de transformation ou de mutation qui nécessite une période de temps au-delà du court terme. Le court terme devient à la fois la force et la faiblesse de l’agilité. Il représente la faiblesse : il ne permet pas de se projeter sur l’avenir et de mener des transformations. On reste plutôt focalisé sur le devenir, c’est-à-dire quelque chose qui est prévu pour arriver naturellement : Il va pleuvoir dès que les nuages vont se former, les maisons seront rasées sous la force de l’ouragan, etc. L’agilité a donc besoin d’une articulation entre le court terme et le long terme, pour pouvoir effectuer des transformations.
Enfin, le fonctionnement « court-termiste » a fait complètement disparaître la notion de chemin critique dans les processus agiles. L’importance du chemin critique n’est plus à démontrer dans un projet. Il sert entre autres à déterminer la nécessité d’effectuer ou pas des investissements. En ce sens on comprend mieux ce qui manque donc à la démarche agile.
Le choix d'une méthode
Existe-t-il vraiment une meilleure méthode de gestion d’un projet de système d’information ? Suffit-il à une méthode d’être mieux à même de construire une interaction entre les parties prenantes pour être qualifié de meilleure ? La réponse à ces questions est évidemment négative.
La comparaison entre les méthodes sur une base quantitative du nombre de projets avec succès ou en échec est une approche dénuée de logique. Si une méthode supplantait les autres, l’évidence et le bon sens guideraient tout le monde à l’adopter. Le choix d’une méthode dépend du contexte, de l’environnement, des parties prenantes, du budget, du type de besoin et de son niveau de détail exprimé par le client, etc. Ainsi, seule la maîtrise de plusieurs méthodes et connaissances permettra au final de choisir la (les) méthode(s) adaptée(s) à chaque contexte. Le constat qui est d’ailleurs devenu une réalité, c’est que l’on s’achemine de plus en plus vers un mélange de plusieurs méthodologies pour mieux gérer un projet.
Les équipes expérimentées arrivent à mixer avec ingéniosité les principes traditionnels et agiles. Cette logique de « mélange » se trouve d’ailleurs au sein même des démarches agiles car la méthode la plus utilisée actuellement dans la gestion des projets, le
Ce qui est important de savoir pour éviter de s’engouffrer dans les travers de l’opposition entre ce qui est agile de ce qui ne l’est pas, c’est que la bonne méthode sera toujours celle qui est en phase avec l’alignement stratégique de l’entreprise.
Le fait de se cantonner à une seule méthode, en l’occurrence l’agilité, sous prétexte que le discours ambiant l’encense, est une erreur professionnelle : un tel choix ne fait qu’orienter vers une seule vision d’un monde bien trop complexe.
L’agilité a beaucoup de limites, tout comme les méthodes traditionnelles, mais si l’on veut l’accompagner et lui donner les moyens de corriger ces limites, une approche acceptable serait de sortir du dogme des produits et services fabriqués rapidement et à moindre coût. Il faudra ensuite lui ouvrir la voie vers des chantiers de transformation, lesquels vont nécessiter de gérer le long terme et surtout d’effectuer des vraies études d’opportunité et de faisabilité, autres éléments qui font partie, à ce jour, des faiblesses de la démarche agile.
