Mener à bien ses projets : modèle en cascade, méthode agile ou hybride?

Un des articles les plus populaires de la Harvard Business Review (HBR) pour le moment (octobre 2023) est "It's Time to End the Battle Between Waterfall and Agile" [1], soit en français "Il est temps de mettre fin à la bataille entre le modèle en cascade et la méthode agile". Cet article d'Antonio Nieto-Rodriguez, un professeur et entrepreneur qui se qualifie de champion du monde de la gestion de projet sur LinkedIn, tente de nous convaincre, dans un compromis tout helvétique, qu'une solution hybride entre le modèle en cascade (waterfall en anglais) et la méthode agile est la meilleure solution pour mener à bien un projet. Selon lui, cette méthode hybride englobe les points forts du modèle en cascade et de la méthode agile tout en compensant leurs faiblesses. D'après l'auteur de l'article, en intégrant une méthode hybride dans notre boîte à outils de chef de projet, nous nous donnons les moyens d'augmenter le taux de réussite des projets, en apportant plus de valeur à notre organisation et en naviguant plus efficacement dans la réalité économique des projets.

Quand j'ai commencé mes études à la fin des années 1990, j'ai été initié à la méthode en cascade, en V, en W, le guide PMBOK. J'ai également étudié Unified Process (UP) et je suis passé à l'agilité au sens très large du terme, jusqu'à arriver à l'eXtreme Programming (XP), méthodologie que j'ai préférée en tant que développeur.

Depuis une dizaine d'années, je suis confronté au sempiternel débat : waterfall ou agile. De temps à autre, on essaie de me vendre le water-scrum-fall comme la solution et il semblerait qu'Harvard essaie de nous resservir ce plat maintes fois réchauffé.

Le modèle en cascade

Personnellement, je trouve que le modèle en cascade est trop rigide. Avant de changer, ou plutôt de chuter (comme le suggère la métaphore), de phase, il faut que la phase en cours soit terminée. Entre les phases de conception et d'analyse et les phases de construction et de test, le besoin évolue pour divers motifs, comme les contraintes budgétaires, techniques ou légales, mais aussi parce que le secteur souhaite toujours offrir plus à ses clients. Entre les deux premières phases et les tests, il peut se passer des mois, voire au moins une année. Il est donc souvent trop tard pour faire marche arrière.

La méthode agile

Lorsqu'une équipe utilise une méthode agile, comme Scrum, pour mener à bien un projet, dès la fin de la première itération, le client peut commencer à manipuler et à tester le produit ou le service. L'équipe de projet obtient tout de suite des retours et elle peut adapter son projet afin de répondre aux attentes des utilisateurs. Les clients de la solution développée pourront ainsi mieux préciser leur besoin, voire le montrer de façon plus concrète. Les opposants à la méthode diront qu'il y a beaucoup de déchets, car souvent une partie des développements doit être jetée. Mais ne faut-il pas savoir jeter pour se libérer et mieux s'organiser? Personnellement, je suis convaincu qu'il faut toucher/essayer pour se décider. Ne faisons-nous pas la même chose pour choisir des vêtements?

La méthode hybride

Revenons à l'article d'Antonio Nieto-Rodriguez. L'auteur illustre sa vision de l'hybride en présentant plusieurs exemples, dont deux ont retenu mon attention.

Le premier exemple nous apprend que Philips a adopté une approche hybride pour développer sa plateforme numérique HealthSuite, offrant des versions rapides et itératives pour le développement de logiciels, tout en respectant des directives strictes en matière de documentation et de sécurité. La sacro-sainte documentation, qui la lit? Est-elle toujours à jour? Si oui, quel est le coût de la mise à jour? Personnellement, je suis convaincu que la seule documentation à jour se trouve dans l'implémentation du projet.

Le deuxième exemple qui a failli me faire changer d'avis est celui d'Ubisoft, un développeur de jeux vidéo, qui a utilisé le modèle en cascade pour développer des actifs tels que les personnages et le codage initial de son jeu Assassin's Creed Valhalla, afin de s'assurer que le jeu de base serait robuste et bien construit. Puis Ubisoft est passé à l'approche Agile pour développer les mécanismes de jeu, le débogage et les mises à jour après le lancement. Dans les grandes entreprises et administrations pour les projets informatiques, n'est-ce pas le travail de l'architecture d'entreprise de fournir le socle technique commun à tous les projets, afin que les équipes de développement puissent travailler de façon agile et mettre en œuvre les techniques du DevOps? Nous pourrions aussi nous demander pourquoi Ubisoft a changé de méthode de projet. Ne sommes-nous pas face à une forme du biais du survivant?

En conclusion, je pense que si on veut satisfaire ses clients, pour passer rapidement de la charrette à la voiture (comme sur l'image ci-avant), il faut utiliser une méthode agile. C'est en améliorant constamment sa charrette que l'homme a réussi à construire la voiture. À l'inverse, si on veut faire plaisir au contrôle interne, alors il vaut mieux suivre le modèle en cascade, mais attention, la chute à la fin du projet sera plus grande!

[1] Antonio Nieto-Rodriguez, Harvard Business Review, It’s Time to End the Battle Between Waterfall and Agile, https://hbr.org/2023/10/its-time-to-end-the-battle-between-waterfall-and-agile, publié le 10 octobre 2023, consulté en ligne le 24 octobre 2023

Images : Dall-e