Agile ou Waterfall (Séquentielle) – laquelle est la meilleure ?

En tant que praticien agile, formateur, coach et consultant, vous pourriez vous attendre à ce que je dise : « Agile est la seule façon de réussir — payez-moi beaucoup d'argent et je vous montrerai pourquoi ! »

Mais voici la vérité (attention spoiler) : je ne peux répondre à cette question qu'en disant « ça dépend ». Cela peut sembler vague, mais c'est souvent la réponse la plus honnête et la plus précieuse.

Au final, vous seul pouvez décider ce qui convient le mieux à votre projet et à votre organisation, en vous basant sur les facteurs et contraintes que vous comprenez mieux que moi. J'espère que cet article vous aidera à y voir plus clair.

Commençons par examiner les idées fondamentales derrière chaque approche.

La gestion de projet en cascade suit une approche séquentielle et prédictive. La portée est généralement fixe, et la solution est souvent entièrement spécifiée avant le développement. La livraison peut se faire en un seul « big bang » ou par phases, où chaque phase livre une partie importante de la solution globale.

Une méthode cascade typique comprend ces étapes :

1. Analyse : Identifier, documenter, convenir et approuver les exigences et toutes les normes de qualité. En informatique, cela inclut les exigences non fonctionnelles.
2. Conception : Créer et approuver une conception détaillée qui répond aux exigences convenues et aux critères de qualité.
3. Construction : Construire la solution selon la conception, en s'assurant qu'elle répond à toutes les exigences spécifiées et aux normes de qualité.
4. Test : Tester minutieusement la solution pour confirmer qu'elle répond aux exigences convenues, à la conception et aux autres critères de qualité.
5. Déploiement : Mettre la solution en service pour livrer sa valeur métier prévue.

Chaque étape doit être planifiée et dotée de ressources, avec toutes les activités clairement identifiées, estimées et assignées. Dans de nombreux cas, les activités seront décomposées en tâches détaillées et représentées sous la forme d'un diagramme de GANTT. Pour un projet en phases, l'analyse et la conception de haut niveau doivent avoir lieu en premier pour définir le contexte et la portée de chaque phase.

L'approche en cascade nécessite un style prédictif de gestion de projet dans lequel chaque étape produit une documentation qui décrit ce que l'étape suivante doit faire.

Tout le travail de chaque étape est planifié sur la base de l'attente (elle-même une prédiction) que le résultat correspondra à ce qui a été convenu. La documentation correctement approuvée est le principal moyen de communiquer l'intention du projet à toutes les personnes impliquées ou affectées.

Le contrôle du projet repose sur la démonstration que le travail livré correspond à la documentation de l'étape précédente, ainsi que sur le respect du plan approuvé pour l'étape en cours. Tout changement devrait passer par un processus formel dans lequel la documentation est révisée et approuvée. Idéalement, la documentation est examinée régulièrement pour s'assurer qu'elle répond toujours aux besoins métier en évolution.

Les changements peuvent être identifiés à partir du travail des étapes ultérieures du processus en cascade. Par exemple, des problèmes découverts pendant l'étape de Test qui identifient un décalage entre les exigences spécifiées et les besoins métier actuels. Une analyse de ce décalage est nécessaire, les changements convenus se répercutant ensuite en cascade pour finalement être testés à nouveau.

La perception du succès dans la méthode en cascade tend, par conséquent, à être liée à la qualité de correspondance entre la prédiction et le besoin réel, et à l'alignement des résultats avec la prédiction en termes de budget, d'échéanciers et de qualité.

Le processus en cascade peut sembler simple au premier abord, mais il s'avère souvent plus complexe que prévu. Il s'appuie fortement sur la documentation, utilise des approbations hiérarchiques et suit une planification centralisée. Parce qu'il exige une documentation et une planification détaillées dès le départ, le processus peut devenir compliqué, avec de nombreuses parties connexes devant être reliées pour que le processus atteigne le résultat souhaité.

Avantages :

• Structure claire : L'approche étape par étape est facile à comprendre pour les chefs de projet et à expliquer aux parties prenantes.
• Planification prévisible : L'analyse et la conception approfondies au début favorisent une planification et une budgétisation claires et précises.
• Suivi simple : Les progrès peuvent être surveillés par la documentation (montrant comment les jalons sont atteints) et vérifiés par rapport au plan (pour confirmer que les tâches se terminent dans les délais et dans le budget).

Inconvénients :

• Gestion complexe des changements : La gestion des changements nécessaires peut être fastidieuse, poussant parfois les équipes à contourner entièrement le processus et entraînant une perte de contrôle.
• Détection tardive des problèmes : Le développement par gros incréments avec des tests largement concentrés à la fin du processus peut révéler les problèmes trop tard, causant des retards inattendus et des dépassements de coûts.
• Concentration réduite sur la valeur métier : L'analyse et la documentation approfondies en amont n'offrent aucune valeur métier directe ; elles existent uniquement pour guider le processus.

Bien qu'elle conserve un élément de processus distinct pour encadrer le développement, une approche agile de la gestion de projet se concentre davantage sur les personnes que sur les processus. Le travail préliminaire est intentionnellement léger, ne façonnant que la solution et le plan de haut niveau tout en laissant les détails plus fins jusqu'au dernier moment responsable avant le développement. Généralement, le développement procède fonctionnalité par fonctionnalité dans des « Sprints » de durée fixe.

Les participants du projet – notamment, et c'est important, les gens d'affaires au sein des équipes de développement – collaborent tout au long du projet. Ils construisent des incréments plus petits qu'avec l'approche traditionnelle en cascade, en utilisant un processus itératif.

Chaque itération inclut l'analyse, la conception, la construction, les tests, et idéalement le déploiement, dans des cycles qui peuvent durer quelques heures seulement ou s'étendre sur plusieurs jours ou semaines (plutôt que les semaines ou mois souvent observés avec l'approche en cascade). L'objectif est de déployer des parties de la solution dès qu'elles peuvent apporter de la valeur.

Le développement s'appuie sur la collaboration détaillée d'individus compétents et qualifiés, habilités par l'organisation à développer une solution qui répond au besoin de l'entreprise.

Ces individus définissent les détails du besoin avant de planifier le travail de développement requis. Ils exécutent ensuite ce plan, en l'ajustant continuellement pour rester concentrés sur la livraison d'une valeur maximale. Pour une véritable agilité, les équipes suivent souvent des valeurs telles que celles que l'on trouve dans Scrum, qui est actuellement l'approche de livraison agile la plus largement adoptée.

L'approche itérative est très tolérante au changement car elle reporte la planification détaillée jusqu'au dernier moment responsable, en utilisant des données en temps réel et des cycles de planification courts. Au lieu d'être entièrement prédite dès le début, la solution émerge progressivement pour répondre aux besoins qui ont été esquissés (mais pas définis méticuleusement) au début du projet.

En priorisant les exigences de haut niveau en amont et en traitant d'abord les plus importantes, cela permet aux équipes agiles de maintenir un contrôle strict sur les délais et les budgets. Le développement se termine simplement de manière contrôlée une fois que les limites de temps ou de budget sont atteintes, seuls les éléments les moins valorisés étant exclus de la livraison finale.

Parce que les cycles de développement sont courts (généralement d'environ deux semaines) et fixes, il est logique de mesurer le succès par la livraison incrémentale de valeur à un rythme prévisible.

L'approche itérative et incrémentale, avec des cycles courts menés par des équipes auto-organisées autonomes, semble souvent chaotique. Mais composée de personnes compétentes, collaboratives et disciplinées, elle est très efficace et efficiente. Cela dit, le risque d'utiliser une approche agile avec des individus qui ne sont pas compétents, collaboratifs et disciplinés mène très probablement à l'échec. Cela rend la supervision (mais pas la gestion) essentielle jusqu'à ce que les équipes aient démontré leur capacité collective à livrer.

Avantages :

• Développement itératif : Des cycles de développement rapides avec des opportunités de collaboration et de retours continus réduisent le risque de construire une solution qui ne répond pas aux vrais besoins.
• Livraison de valeur incrémentale : Livrer une valeur tangible à intervalles courts améliore le contrôle global en facilitant le suivi des progrès et l'identification des mesures correctives.
• Adaptabilité : Laisser les détails au dernier moment responsable permet aux solutions d'émerger pour répondre aux besoins actuels plutôt qu'aux besoins prédits.

Inconvénients :

• Peut sembler non structuré : Particulièrement pour ceux habitués aux contrôles basés sur les processus. Cela ne convient pas bien aux managers et dirigeants ayant de forts besoins de contrôle.
• Compétence et collaboration élevées de tous les participants : Les dirigeants ont besoin de confiance pour faire confiance et de compétence pour autonomiser leurs équipes collaboratives.
• Potentiel de chaos et d'échec : Les équipes manquant de compétence démontrée et de professionnalisme peuvent échouer sans supervision appropriée.

Remarque : les inconvénients décrits ci-dessus s'appliquent aux équipes ou organisations qui découvrent la méthode de travail agile. Lorsqu'il y a une véritable compétence en agilité, il est difficile d'identifier des inconvénients universels, bien que des inconvénients spécifiques au contexte puissent bien survenir.

Les principales différences entre une approche agile et une approche en cascade peuvent être résumées en 5 dimensions :

1. Développement de la solution – Émergent vs. Spécifié :

• Agile : La solution émerge au fil du temps pour répondre aux besoins métier en évolution. Les détails évoluent à l'approche du développement, gardant la solution flexible.
• Cascade : La solution est définie en amont pour répondre à un besoin anticipé. Un contrôle rigoureux des changements est nécessaire pour maintenir l'alignement avec les besoins en évolution.

2. Participants au projet – Collaboratif et transversal vs. Cloisonné et spécialisé :

• Agile : Les membres de l'équipe travaillent ensemble avec des rôles larges, faisant tout ce qui est nécessaire pour atteindre leur objectif commun. L'objectif est d'éviter la communication par la documentation et de minimiser les transferts dans la mesure du possible.
• Cascade : Bien qu'un certain degré de collaboration soit souvent observé, elle se concentre souvent sur des activités spécifiques et spécialisées (comme la collecte d'exigences). Les participants au projet tendent à adopter l'approche cloisonnée de l'ingénierie industrielle qui a dominé la pensée du 20e siècle, généralement avec une communication et un contrôle gérés via la documentation.

3. Management – Auto-organisé vs. Dirigé :

• Agile : Les équipes s'organisent et se gèrent elles-mêmes, décidant comment accomplir les tâches et ajustant les processus au fur et à mesure qu'elles apprennent.
• Cascade : Les équipes reçoivent généralement des directives de la part des managers, qui décident de ce qui doit être fait, par qui, et quand. Le niveau de détail de ces instructions peut cependant varier selon le projet ou le style du manager.

4. Changement – Embrassé vs. Résisté :

• Agile : Parce que les équipes travaillent vers des objectifs larges sans définir chaque détail en amont, elles accueillent favorablement les changements lorsque de nouveaux besoins ou insights émergent.
• Cascade : La gestion du changement est bureaucratique et coûteuse car elle nécessite une analyse approfondie, de la documentation et une approbation. En conséquence, elle fait souvent obstacle aux changements nécessaires.

5. Contrôle basé sur : Discipline professionnelle vs. Conformité aux processus

• Agile : S'appuie largement sur la compétence, la discipline et l'auto-organisation de l'équipe. Les membres de l'équipe prennent des engagements les uns envers les autres et s'approprient collectivement les tâches et les solutions.
• Cascade : Utilise une planification détaillée et des instructions claires. Le rôle de chacun est défini en amont, et le chef de projet coordonne les activités. Le succès dépend du respect du plan et des processus tels que conçus.

Comme je l'ai mentionné plus tôt, cela dépend…

Dans le monde complexe d'aujourd'hui, mener un projet entièrement agile ou entièrement en cascade est peu probable. Plus souvent, les équipes constatent qu'un peu d'agilité peut apporter de la valeur à un projet principalement en cascade, tandis que certains éléments de la méthode en cascade ont du sens dans un projet par ailleurs agile. Ce mélange est souvent appelé une approche hybride, se situant dans la zone grise entre les deux extrêmes.

Donc, la vraie question d'un chef de projet n'est pas « Quelle méthode pure dois-je choisir ? » mais plutôt « Où mon projet doit-il se situer sur ce spectre ? » Les méthodes agiles prospèrent dans des environnements caractérisés par une forte volatilité, incertitude, complexité et ambiguïté (VUCA). À l'inverse, les approches en cascade fonctionnent généralement mieux lorsque les choses sont plus stables, certaines, simples et claires.

Le cadre Cynefin peut vous aider à déterminer où votre projet pourrait se situer sur ce spectre.

Cynefin, prononcé kuh-nev-in, est un mot gallois qui désigne les multiples facteurs entremêlés de notre environnement et de notre expérience qui nous influencent (dans notre façon de penser, d'interpréter et d'agir) d'une manière que nous ne pouvons jamais complètement comprendre.

Dans une simplification admise du Cadre Cynefin, l'environnement dans lequel nous travaillons – dans ce cas notre environnement de projet – peut être placé sur un spectre caractérisé comme clair, compliqué, complexe ou chaotique.

Dans un environnement de projet qui est :

• Clair, il existe un chemin évident entre le problème et la solution.
• Compliqué, le chemin entre le problème et la solution peut ne pas être évident, mais une bonne analyse révélera un chemin vers une solution appropriée.
• Complexe, il n'est pas possible d'identifier un seul chemin, même avec une analyse, car les prédictions ne peuvent être faites qu'en se basant sur la théorie plutôt que sur l'expérience.
• Chaotique, il n'y a aucune base pour la prédiction car il y a trop de facteurs changeants ou contradictoires. La seule voie possible est l'expérimentation.

Dans ce qui précède, le domaine clair se prête à une approche en cascade pure et le domaine chaotique nécessite de l'agilité. Les deux autres – les plus courants dans la réalité – sont probablement mieux servis par une approche hybride. Alors, demandez-vous : « lequel des cas ci-dessus décrit le mieux mon environnement de projet ? » et laissez cela guider votre sélection d'approche.

Vous devez également tenir compte d'autres contraintes imposées par les règles et la culture de votre organisation pour décider de l'approche la plus sensée pour votre projet. Essayer de faire fonctionner une approche en cascade dans une culture caractérisée par l'agilité ou une approche agile dans une culture caractérisée par le commandement et le contrôle causera des problèmes.

Une approche hybride sera peut-être plus susceptible de « se vendre » et de réussir.

Le Manifeste Agile, amélioré pour élargir son applicabilité au-delà du logiciel, identifie quatre déclarations de valeurs destinées à orienter les praticiens vers des comportements agiles. Toute personne souhaitant travailler de manière agile devrait valoriser :

En se concentrant sur les éléments de gauche tout en reconnaissant la valeur de ceux de droite.

Bien qu'il y ait débat sur l'applicabilité complète du Manifeste original dans le monde d'aujourd'hui – particulièrement dans un contexte logiciel – les déclarations de valeurs offrent encore des orientations utiles pour la gouvernance de projet. Il est logique de baser la gouvernance d'un projet agile sur les éléments de gauche, et la gouvernance d'un projet waterfall sur les éléments de droite.

• Personnes et travail d'équipe : Surveiller et favoriser la discipline professionnelle et la collaboration.
• Apporter de la valeur métier : Se concentrer sur la valeur qui soutient les besoins de l'entreprise, plutôt que de cocher les exigences de processus.
• Implication active de l'entreprise : Avoir des représentants de l'entreprise qui travaillent étroitement avec l'équipe tout au long du projet.
• Répondre aux besoins actuels lors du déploiement : S'assurer que la solution correspond aux véritables exigences métier au lancement—même si ces exigences diffèrent du plan initial.

• Suivre des processus prédéfinis : S'assurer que chacun respecte les étapes et approbations établies.
• Produire une documentation prédictive : Élaborer des spécifications claires et vérifier que la solution s'y conforme.
• Approuver les changements correctement : Valider tous les changements apportés à la documentation originale.
• Respecter les plans : S'assurer que les plans restent précis et réactifs aux changements approuvés.

Dans une configuration hybride, la gouvernance doit trouver le bon équilibre entre les éléments agiles et en cascade. Cela implique d'adapter les parties de chaque approche qui ont le plus de sens pour le contexte spécifique du projet.

L'approche de livraison de projet la plus efficace devrait être guidée par le contexte – à la fois la nature du travail et l'environnement dans lequel le projet évoluera. Méfiez-vous de quiconque promeut soit l'agilité pure soit la cascade pure comme une recette universellement applicable au succès.

En référence finale au cadre Cynefin – décrit un état d'Aporia (signifiant impasse) ou de Confusion et n'est pas un bon endroit où se trouver. Vous vous retrouverez très probablement, vous et votre projet, à souffrir ici si vous êtes incapable ou réticent à faire correspondre votre approche de projet à son contexte et à son environnement.

Vous devez réfléchir par vous-même, analyser le contexte, et agir en conséquence. Ce faisant, vous avez la meilleure chance de passer de l'Aporia/Confusion vers l'un des autres états où une approche, très probablement hybride, optimisera votre opportunité de réussite du projet.