La méthode waterfall s’immisce-t-elle dans votre Agile ? Identifiez les 7 signes !

L’Agilité a révolutionné le monde de l’entreprise grâce à son approche centrée sur le client, ses délais de mise sur le marché réduits et son environnement propice à l’innovation. De plus en plus d’organisations adoptent avec enthousiasme les frameworks Agiles, comme Scrum. Cependant, il arrive que malgré l’application de ces frameworks, les résultats espérés ne soient pas au rendez-vous, et l’esprit Agile semble absent au sein des équipes.

Clarifions une chose : la méthode waterfall n’est pas intrinsèquement mauvaise. Elle convient parfaitement à certains types de projets (comme la construction d’un bâtiment, par exemple). Mais lorsque vous visez l’Agilité et que vous retombez dans un fonctionnement de type waterfall, cela pose problème. Comment diagnostiquer ce syndrome de waterfall caché, et surtout, comment le résoudre ? C’est ce que nous allons explorer dans ce billet.

#1 Symptom : Structure d’équipe fonctionnelle

Qu’est-ce que c’est ?

Dans une structure d’équipe fonctionnelle, chaque équipe se concentre sur une étape spécifique du processus de développement, comme le design, le codage ou les tests, au lieu de collaborer sur un produit ou un incrément de produit. Même si chaque équipe applique un framework Agile, elles doivent constamment se coordonner et se transmettre le travail pour finaliser le produit.

Pourquoi est-ce problématique ?

Cette approche entraîne plusieurs écueils : une coordination complexe qui mène souvent à la création de Gantt charts et de plans de projet, signes typiques du waterfall. De plus, chaque équipe est uniquement responsable de sa partie, sans réelle prise en charge de l’expérience client globale. La livraison d’une fonctionnalité peut ainsi prendre des mois, car elle doit passer par plusieurs équipes et risque d’être constamment dépriorisée.

Que faire ?

La solution réside dans la création d’équipes cross-fonctionnelles regroupant toutes les compétences nécessaires pour livrer un produit. Si le produit est trop vaste pour une seule équipe, envisagez des équipes dédiées à une fonctionnalité ou à une zone de service, mais évitez de segmenter par fonction. Cela maintient l’agilité et la collaboration essentielles à l’Agilité.

#2 Symptom : Découpage horizontal du travail

Qu’est-ce que c’est ?

Imaginez votre produit final comme un gâteau, avec des couches représentant le design, la fonctionnalité et les tests. Même si vous ne pouvez pas servir tout le gâteau d’un coup, vous voudriez offrir une tranche complète (avec toutes les couches) pour recueillir les retours des clients. Malheureusement, les équipes choisissent souvent de découper horizontalement : concevoir toutes les fonctionnalités d’abord, puis coder, et enfin tester.

Pourquoi est-ce problématique ?

Cela semble efficace, mais c’est un piège ! Imaginez passer des semaines à créer un gâteau au chocolat parfait pour découvrir que vos clients détestent le chocolat. L’approche Agile propose de travailler une tranche à la fois, testant ainsi rapidement vos hypothèses.

Que faire ?

Les user stories sont une solution simple et efficace pour guider les équipes à découper le travail verticalement. Assurez-vous également de toujours expliciter la valeur client pour chaque tâche. Par exemple, "concevoir un bouton" n’a pas de valeur explicite, tandis que "introduire une fonction de désabonnement" en a clairement.

#3 Symptom : Feuilles de route et plans figés

Qu’est-ce que c’est ?

Vous avez défini en détail les fonctionnalités à lancer ce trimestre et leur ordre de livraison. Le périmètre est figé dès le départ, et bien que vous planifiiez vos sprints et priorisiez le backlog, on attend de votre équipe qu’elle livre un ensemble spécifique de fonctionnalités. Parfois, des dépendances avec d’autres équipes imposent des délais stricts, ne laissant aucune place à la flexibilité.

Pourquoi est-ce problématique ?

L’un des principaux avantages de l’Agilité est sa capacité à s’adapter aux changements, à apprendre continuellement des clients et à pivoter si nécessaire. Un périmètre figé entrave cette flexibilité, empêchant les expérimentations et rendant difficile la réponse à un environnement changeant.

Que faire ?

Les grandes planifications (annuelles, trimestrielles) restent importantes, mais elles doivent servir de lignes directrices, non de règles immuables. Chaque équipe doit pouvoir ajuster ses plans et gérer les dépendances au fil du temps. Les OKRs (Objectives and Key Results) sont une excellente solution : ils déplacent l’accent des livrables (features spécifiques) vers les résultats commerciaux (valeur pour le client ou l’entreprise), en phase avec les principes Agiles.

#4 Symptom : Grands jalons et larges livraisons

Qu’est-ce que c’est ?

Même si vous avez une certaine flexibilité sur les fonctionnalités, vous avez défini des jalons et des dates de livraison. Souvent, des managers imposent des délais artificiels pour "stimuler" les équipes et "accélérer les lancements". Ironiquement, cette approche obtient souvent l’effet inverse.

Pourquoi est-ce problématique ?

Les délais mettent l’équipe sous la pression du triangle projet : périmètre, budget, et calendrier. Un calendrier serré impacte inévitablement le périmètre (ou parfois le budget), et détourne l’équipe de la valeur client au profit de la contrainte temporelle. Le stress des délais nuit à la santé de l’équipe, à la motivation individuelle, et freine l’innovation.

Que faire ?

Aussi contre-intuitif que cela puisse paraître, envisagez d’abandonner les délais fixes et laissez chaque équipe définir son propre rythme. Encore une fois, les OKRs brillent dans ce contexte. En mettant l’accent sur les résultats, les équipes sont responsabilisées sur leur performance tout en ayant la liberté de décider quoi faire et dans quel ordre.

#5 Symptom : Les métriques et résultats de recherche n’influencent pas vos plans

Qu’est-ce que c’est ?

Vous suivez peut-être un framework Agile et restez flexible sur le périmètre, mais prenez-vous réellement en compte les données que vous collectez ? Les équipes peuvent mener des recherches clients et des tests, mais l’inertie les pousse parfois à poursuivre sur leur trajectoire initiale, même si les résultats suggèrent un changement.

Pourquoi est-ce problématique ?

Ignorer de nouvelles connaissances revient à manquer des opportunités et à risquer de perdre du temps sur des initiatives inutiles. Rester inflexible malgré des preuves du contraire freine l’innovation et nuit à la satisfaction client.

Que faire ?

Chaque nouvelle donnée doit influencer votre planification, que ce soit pour saisir des opportunités ou abandonner des idées non pertinentes. Lors des réunions de planification, commencez par examiner les dernières analyses et alignez vos priorités produit avec le marché et les besoins des clients. En d’autres termes, laissez les données guider votre Agilité.

#6 Symptom : Priorité à la quantité (output) plutôt qu’aux résultats (outcome)

Qu’est-ce que c’est ?

Si une équipe se concentre davantage sur "faire avancer les choses" que sur "obtenir des résultats", elle risque l’échec. Par exemple, dans de nombreux contextes (comme au Japon), la promotion peut aller à celui qui travaille de longues heures, même sans efficacité particulière, plutôt qu’à celui qui trouve des solutions innovantes.

Pourquoi est-ce problématique ?

Favoriser l’output conduit à des incitations mal orientées et une préférence pour la quantité au détriment de la qualité. Cela freine les approches créatives et détourne l’équipe de la véritable valeur client.

Que faire ?

Les OKRs sont encore une fois très utiles. Ils permettent d’aligner les objectifs individuels sur ceux de l’équipe, en mettant l’accent sur la contribution aux résultats (outcomes) plutôt qu’à la simple productivité (outputs). L’essentiel est l’impact, pas la quantité de travail accompli.

#7 Symptom : Absence de sécurité psychologique

Qu’est-ce que c’est ?

Sans sécurité psychologique, les membres de l’équipe hésitent à partager leurs idées, à remettre en question les plans ou à se donner du feedback. Ils craignent l’échec et évitent les expérimentations risquées.

Pourquoi est-ce problématique ?

Sans sécurité psychologique, de grandes idées ne sont jamais exprimées, et personne n’intervient pour corriger de mauvaises décisions. L’apprentissage est limité, car les expérimentations sont freinées, et le feedback, essentiel à la croissance, n’est pas échangé. Un tel environnement n’est ni productif, ni agréable.

Que faire ?

La sécurité psychologique commence par le leadership : montrez l’exemple, faites preuve de vulnérabilité, et communiquez que les erreurs sont acceptables. Récompensez les expérimentations, pas seulement leurs succès ou échecs. Créez un environnement où les erreurs sont perçues comme des opportunités d’apprentissage.

Il n’y a rien de mal à la méthode waterfall si elle est consciemment choisie dans le bon contexte. Mais lorsque le waterfall s’insinue dans votre démarche Agile sans invitation, il devient un obstacle. J’espère que ce billet vous a permis d’identifier les impacts négatifs potentiels du waterfall caché et de trouver des moyens de les surmonter.

Rappelez-vous, l’Agilité n’est pas une destination mais un voyage. C’est un moyen de travail qui aide à atteindre vos objectifs et à apporter plus de valeur. Au lieu de vous concentrer sur l’objectif d’être "100% Agile", appliquez le bon sens et demandez-vous si vous maximisez l’efficacité de votre équipe à chaque instant. Bonne continuation sur votre chemin Agile !