Méthode Agile vs. méthode Waterfall - comparaison et différences

Dans le monde du travail, on entend constamment dire que nous évoluons dans un monde VUCA et que nous devons nous adapter à notre environnement en constante évolution. Tout le monde parle d’être dans une transformation vers l’agilité. Certains peuvent ne plus y voir clair et se demander ce que cela signifie pour les organisations. 

Contrairement à la méthodologie dite en cascade, l’agilité est d’un tout autre calibre. En essayant de comprendre ce qu’est la méthode Agile par rapport à la méthode Waterfall, et laquelle est la plus appropriée, tu peux te retrouver dans la confusion. 

Si tu es dans le même cas, nous pouvons peut-être t’aider dans ce qui suit, car nous t’expliquons ici ce que signifie Agile vs Waterfall.

Modèle de cascade

Selon la devise “les vieux balais sont bons”, de nombreuses entreprises utilisent la méthode éprouvée de la cascade. Ce n’est pas surprenant et ce n’est certainement pas toujours une erreur, car le modèle de la cascade est un classique de la gestion de projet et a prouvé dans de nombreux cas qu’il pouvait être efficace.

Mais que signifie concrètement Agile vs. Cascade ? Le modèle en cascade est un modèle de processus linéaire dans lequel la procédure est organisée en phases de projet successives avec des points de départ et d’arrivée concrètement définis. En gros, on peut se le représenter ainsi :

Voyons tout cela à l’aide d’un exemple simple :

Dans la phase de définition, on détermine d’abord ce qui doit être créé. Par exemple, le client exprime un souhait : il veut une table. On analyse et on définit ensuite les exigences et on établit un plan de tout ce qui doit être fait. Dans la conception, on crée ensuite une conception du produit, dans notre exemple un croquis de la table. 

Lors de la phase de mise en œuvre, tout cela devient plus concret : nous choisissons le matériau, nous déterminons les dimensions exactes et nous construisons la table. Lors du contrôle, nous vérifions si tout fonctionne comme nous l’avons prévu : la table est-elle stable ? Les proportions sont-elles correctes ? La Évaluation a ensuite lieu avec le client : nous livrons le produit et recevons un feedback. 

Alors pourquoi changer quelque chose, alors que l’on dit si bien : Never change a running system.

Méthodologie agile (itérative) vs. cascade (linéaire)

Même si le modèle de la cascade a définitivement de bons côtés et est efficace dans de nombreuses situations, les entreprises devraient accepter de devenir plus agiles. Pourquoi ? Parce que le monde dans lequel nous évoluons tous nous impose des exigences de plus en plus complexes et contradictoires et que nous avons souvent du mal à y répondre avec une pensée en cascade.

La méthode de la cascade comporte quelques dangers. Bien que nous ayons un sentiment de sécurité élevé grâce à la planification et à la structure, nous sommes également très liés dans nos processus. Le processus de travail est plutôt statique et la planification précise ne nous laisse que très peu de marge de manœuvre. Et c’est justement ce dont nous avons besoin dans notre environnement dynamique. C’est là qu’intervient l’agilité. Jetons donc un coup d’œil à la méthode Agile contre la méthode Waterfall.

Mais au fait, quelle est la définition de l’agilité ? Selon le Duden agile est quelque chose comme “Témoignant de la mobilité ; agile et souple” et cette définition s’applique bien au monde du travail. 

L’agilité dans les entreprises signifie être capable d’adapter les stratégies, les structures et les processus de manière itérative aux conditions réelles et actuelles. C’est essentiel, car nous sommes confrontés à des changements complexes en raison de la numérisation et des changements démographiques, et nous devons donc rester adaptables. 

À propos, une brève remarque dans le contexte de la transformation agile : voulez-vous vous assurer que vous définissez actuellement les bonnes priorités dans votre transformation agile ? 

Alors faites notre test de maturité pour votre transformation agile - cela ne prend que 3 minutes. Vous obtenez même un benchmark basé sur plus de trois cents autres participants. Voir le bouton 🙂

Construire une table avec les méthodes agiles

Prenons le même exemple que précédemment : le client veut une table. Nous commençons donc par faire une esquisse. Je la montre au client et il décide s’il l’a imaginée comme ça ou pas. Si ce n’est pas le cas, l’esquisse est adaptée. Une fois l’esquisse réalisée, je choisis le matériau et je demande au client, de manière itérative, si tout se passe bien.

Peut-être que le client dira : “Oh non, je crois que je préfère le pin au cerisier”. Donc un autre bois : nous faisons donc un nouveau choix. Ensuite, la table est assemblée et là aussi, le client est régulièrement consulté et des modifications sont apportées si nécessaire.
On le voit bien : La méthodologie agile nous permet de réagir de manière flexible aux exigences changeantes, ce qui est pertinent dans un environnement complexe. 

C’est pourquoi le caractère statique de la méthodologie Waterfall n’est pas toujours suffisant. De plus, il peut arriver que les erreurs de mise en œuvre dues à la conception rigide dans le modèle Waterfall ne soient visibles qu’au moment de l’évaluation. Cela entraînerait des coûts de correction nettement plus élevés qu’une adaptation flexible.

Méthodes Agile vs. cascade dans le monde du travail

Il est encore souvent difficile de concevoir des processus agiles et itératifs dans les entreprises. Cela est dû au fait que les gens sont plutôt averses au risque et qu’ils ont parfois été socialisés pendant des décennies dans leur contexte professionnel avec un modèle de pensée marqué par les cascades. 

L’aversion au risque désigne ici la tendance, dans les situations de décision, à choisir la possibilité qui comporte le moins de risque - donc la perte la plus faible - par rapport au résultat. (cf. Kahneman & Tversky, 1979)

Les méthodes Agile vs. Cascade nous demandent d’abandonner cette sécurité supposée : au lieu de recourir à des méthodes éprouvées et d’utiliser des structures et des principes fixes, les anciens schémas de pensée de l’illusion de la planification sont brisés et des méthodes itératives sont utilisées. Cela entraîne d’abord un sentiment d’incertitude accrue, car il faut appliquer des approches nouvelles - apparemment risquées - qui interprètent l’incertitude comme faisant partie du plan.

Prévoir cette incertitude permet de créer la flexibilité nécessaire à long terme. Nous développons un éventail de possibilités d’action, ce qui, à l’inverse, stabilise la sécurité dans le monde du travail VUCA.

Equilibrer dynamique et stabilité 

La méthodologie agile - comme la méthodologie en cascade - comprend certains inconvénients :

• Les méthodes agiles rendent les incertitudes de planification visibles et en tiennent compte, de sorte que les plans doivent contenir plus de marge de manœuvre pour les nouvelles connaissances.
• Le résultat concret est plus difficile à estimer, car de nouvelles connaissances peuvent faire en sorte que l’on s’écarte du résultat prévu initialement.
• Pour les raisons mentionnées ci-dessus, les succès semblent moins prévisibles que dans un projet classique en cascade.

Bien entendu, différentes approches sont plus ou moins appropriées selon le projet.
Le modèle en cascade est surtout adapté aux projets qui ont déjà des exigences connues et constantes au préalable. 

Les méthodes agiles sont particulièrement optimales pour les projets dans lesquels de nombreux facteurs imprévisibles peuvent survenir et où des boucles de réflexion flexibles sont donc nécessaires. Dans la plupart des projets technologiques, une telle incertitude est inévitable, c’est pourquoi les méthodes agiles sont en plein essor, surtout dans ce domaine.

D’ailleurs, si tu souhaites spécifiquement exiger l’état d’esprit agile au sein de ton équipe ou de ton entreprise, cela vaut la peine de jeter un coup d’œil à notre article sur l’agilité. vérité étonnante derrière l’état d’esprit agile .

Méthode Agile vs. méthode Waterfall ou combinaison ?

Dans tout ce battage médiatique autour de « l’agile », on peut parfois avoir tendance à considérer les méthodes agiles comme une panacée. À tort. Le résultat peut-être surprenant de ce texte est clair.

Il s’avère que l’utilisation Les deux méthodologies Combiné conduit efficacement à l’objectif (Herrmann, 2007). De telles combinaisons sont utiles dans les situations où le modèle en cascade est exigé, mais que cela ne convient pas à la complexité du projet. 

Une sorte de voie médiane entre les deux méthodes est ce qu’on appelle le Développement axé sur les fonctionnalités (FDD).

Chez FDD on développe certes - comme dans la méthode en cascade - un plan concret à long terme avec des séquences individuelles et définies : les fonctionnalités. Cependant, les différentes fonctionnalités sont très courtes, ce qui permet des réactions à court terme aux exigences changeantes. La procédure n’est certes pas aussi itérative que les méthodes agiles, mais elle représente le cas échéant un compromis approprié. 

Et nous arrivons ainsi à un résultat plutôt surprenant : il ne doit pas toujours s’agir de la méthode Agile vs. Cascade. Les deux méthodes peuvent tout à fait se compléter. Les deux ont leur raison d’être. Selon le projet et le contexte.

Mais comme les méthodes agiles sont encore un terrain inconnu pour beaucoup, ils se demandent à juste titre comment on pourrait essayer les méthodes agiles.

Tu n’es pas sûr de savoir comment commencer ?

Pour beaucoup, « l’agilité » est encore un territoire inconnu. Ils se posent à juste titre la question : est-ce que je préfère faire le projet de manière agile ou en cascade ? Comment est-ce que je commencerais avec les méthodes agiles ? Une réponse « agile » à cela serait : lancez des expériences. Essayez différentes choses de manière itérative.

Les méthodes agiles sont traditionnellement introduites par deux voies, qui conviennent également parfaitement aux « débutants »: Kanban et les rétrospectives.

Kanban et les rétrospectives comme point de départ classique

Avec Kanban, on utilise un tableau (Kanban) visible publiquement sur lequel chaque membre de l’équipe rend ses activités actuelles transparentes. Cela favorise la communication, l’efficacité et, au final, la réussite du projet. Tu trouveras plus d’informations sur Kanban ici. 

L’idée de base des rétrospectives est de réfléchir activement et régulièrement en tant qu’équipe. Typiquement, toutes les deux semaines, on se réunit dans une réunion de rétrospective et on pose par exemple les questions suivantes : qu’est-ce qui fonctionne bien en ce moment ? Qu’est-ce qui ne va pas ? Et quelles mesures pouvons-nous prendre pour que les choses aillent mieux.

Si vous envisagez d’introduire des méthodes agiles…

Si tu es toujours à la recherche d’une planche rétro appropriée, notre article peut d’ailleurs t’aider avec ce sujet : Les meilleures planches rétro en comparaison.

Sources

Richard H. Thaler, Amos Tversky, Daniel Kahneman, Alan Schwartz, L’effet de la myopie et de l’aversion à la perte sur la prise de risque : un test expérimental, The Quarterly Journal of Economics, Volume 112, Issue 2, May 1997, Pages 647–661, https://doi.org/10.1162/003355397555226

Herrmann, A. (2007). Feature Driven Development entre la cascade et l’agilité.

akquinet

Projektmanagement Wasserfall vs. Scrum pinuts.de

Projektmanagement Wasserfall vs. Scrum Projektmanagement: Wasserfall-Modell vs. agiles Vorgehen Wasserfall Modell oder das agile Scrum Modell? Noch bevor die inhaltliche Konzeption eines umfangreichen Webprojekts beginnt, stehen die Verantwortlichen vor einer entscheidenden Frage: Mit welcher...

agil ▶ Rechtschreibung, Bedeutung, Definition, Herkunft | Duden duden.de

Definition, Rechtschreibung, Synonyme und Grammatik von 'agil' auf Duden online nachschlagen. Wörterbuch der deutschen Sprache.