On m'a déjà dit "on fait du Scrum" dans une équipe où personne ne savait ce qu'était un sprint backlog. On m'a aussi dit "on est Agile" dans une organisation où chaque décision nécessitait trois comités de validation. Et on m'a dit "Waterfall c'est mort" — juste avant qu'un client nous demande un projet à périmètre fixe, budget fixe, et date fixe. Waterfall a sauvé ce projet.
Le problème avec les méthodes de gestion de projet, ce n'est pas qu'elles sont mauvaises. C'est qu'on les utilise comme des religions au lieu d'outils. On choisit un camp, on y reste, et on traite les hérétiques avec condescendance. Alors comparons honnêtement.
Scrum : le sprint qui devient une marathon
Scrum a un cadre clair : des sprints de 2-4 semaines, un Product Owner, un Scrum Master, un backlog priorisé, et trois cérémonies (planning, daily, rétrospective). C'est propre, c'est structuré, et ça marche — quand l'équipe a l'autonomie pour livrer de bout en bout.
Mais voici ce que je vois en réalité :
- Le daily devient un report de statut — le Scrum Master pose "qu'est-ce que tu as fait hier ?" et tout le monde répond au manager, pas à l'équipe.
- Le sprint backlog est une liste de tâches imposée — pas négociée, pas estimée par l'équipe, juste descendue d'en haut.
- La rétrospective est une cérémonie vide — on note des post-its, on les met sur un mur, et rien ne change au sprint suivant.
- Le "definition of done" n'existe pas — ou alors il veut dire "les tests passent en CI", pas "c'est déployable en production".
Scrum fonctionne quand l'équipe peut réellement s'auto-organiser. Si votre organisation est hiérarchique, avec des validation gates à chaque étape, Scrum ne fera qu'ajouter des cérémonies par-dessus votre Waterfall existant. C'est ce qu'on appelle ScrumFall — et c'est pire que les deux séparément.
Kanban : le flux sans pression — jusqu'à ce qu'il n'y en ait plus
Kanban est plus simple : un tableau, des colonnes (À faire / En cours / Fait), une limite de travail en cours (WIP), et du flux continu. Pas de sprints, pas de cérémonies obligatoires, pas de rôles imposés.
Kanban excelle quand :
- Le travail est imprévisible et arrive au fil de l'eau (support, maintenance, bugs).
- L'équipe est petite (3-5 personnes).
- Les tâches sont courtes et homogènes.
- Vous voulez visualiser les blocages sans ajouter de structure.
Mais Kanban a un piège : sans limite WIP, ce n'est pas du Kanban, c'est juste un tableau. Et la plupart des équipes que je vois n'ont pas de limite WIP. Ou alors elles en ont une, mais personne ne la respecte parce que "cette tâche est urgente". Résultat : 47 tickets en colonne "En cours", un lead time de 3 semaines, et tout le monde se demande pourquoi rien n'avance.
Kanban sans WIP limit, c'est comme un feu rouge que tout le monde grille. Il est là, il est rouge, mais personne ne s'arrête.
Waterfall : le cadet du discrédit qui mérite mieux
Waterfall a mauvaise réputation. C'est le boogeyman de l'Agile. "Waterfall c'est le passé." "Waterfall c'est rigide." "Waterfall ça échoue."
Pourtant, Waterfall reste la bonne approche dans plusieurs cas :
- Contrats à prix fixe et périmètre fixe — quand le client veut savoir exactement ce qu'il aura, quand, et pour combien. Vous ne pouvez pas négocier le scope au sprint 8.
- Projets réglementés — medical, aéronautique, bancaire. Quand chaque phase doit être validée et tracée avant la suivante.
- Infrastructure et hardware — vous ne pouvez pas "itérer" sur un datacenter physique de la même manière que sur une API.
- Quand les besoins sont stables et bien compris — si rien ne va changer pendant 6 mois, pourquoi payer le coût des cérémonies Agile ?
Waterfall échoue quand les besoins sont flous au départ et changent en cours. Mais quand les besoins sont clairs, il est plus rapide, plus prévisible, et moins coûteux que n'importe quelle méthode Agile.
Comparaison honnête
Voici un tableau qui ne ment pas :
Scrum — Itérations courtes, besoins évolutifs, équipe autonome. Coût : cérémonies + overhead. Risque : devient du ScrumFall dans une organisation hiérarchique.
Kanban — Flux continu, travail imprévisible, petite équipe. Coût : discipline WIP. Risque : devient un tableau sans limite, lead time explose.
Waterfall — Phases séquentielles, besoins stables, contraintes contractuelles. Coût : rigidité. Risque : catastrophe si les besoins changent en cours.
Le vrai choix
La question n'est pas "Scrum ou Kanban ou Waterfall ?". La question est : quelles sont mes contraintes, et quelle méthode les respecte le mieux ?
Si vous avez un client qui change d'avis chaque semaine, Scrum ou Kanban. Si vous avez un contrat fixed-price avec un cahier des charges signé, Waterfall. Si vous avez une équipe de 3 personnes qui gère du support et des features, Kanban. Si vous avez une équipe de 12 qui livre un produit SaaS, Scrum.
Et rien ne vous empêche de mixer. ScrumBan existe : sprints pour les features, Kanban pour les bugs. Water-Scrum-Fall existe aussi : phase de design en Waterfall, développement en Scrum, déploiement en Waterfall. Ce n'est pas sale. C'est pragmatique.
Ce qui est sale, c'est de choisir une méthode parce que c'est tendance, et de forcer votre projet à rentrer dans une boîte qui ne lui correspond pas.
Et vous ?
Quelle méthode utilisez-vous vraiment — et pourquoi ? Est-ce un choix conscient ou une habitude ? Si vous deviez changer demain, qu'est-ce qui vous en empêcherait ? Partagez votre expérience, même si elle contredit cet article. Surtout si elle le contredit.
Partager votre retour