We've managed projects using strict Scrum, Kanban, Waterfall, and various hybrids. The uncomfortable truth? The projects that succeeded had more to do with clear requirements, good communication, and skilled engineers than which methodology was on the wall. But the methodology still matters — it determines how quickly you can adapt when (not if) things change.
What We'll Cover
Head-to-Head Comparison
| Dimension | Agile | Waterfall |
|---|---|---|
| Requirements | Evolve through discovery. User stories refined each sprint | Defined upfront. Change requests are formal and costly |
| Delivery | Working software every 2-4 weeks | Complete system delivered at the end |
| Feedback | Continuous — users see working features early | Late — users see the product after months of development |
| Risk | Discovered early (small iterations expose problems fast) | Discovered late (integration issues surface at the end) |
| Documentation | Lighter — working software over comprehensive docs | Heavy — detailed specs, design docs, test plans upfront |
| Budget predictability | Time and materials. Scope adjusts to fit budget | Fixed scope, fixed price (theoretically). In practice, change orders add up |
| Team structure | Cross-functional, self-organizing | Specialized roles, hierarchical handoffs |
When Agile Is the Right Call
- You're building a product, not a project. Products evolve based on user feedback. If you're building something that will change based on what you learn after launch, Agile's iterative approach is essential
- Requirements are uncertain. If the stakeholder says "I'll know it when I see it," Waterfall will fail. Agile lets you show them working software every 2 weeks and adjust
- Speed to market matters. Agile delivers value incrementally. You can launch an MVP in 6 weeks instead of waiting 6 months for a complete system
- The technology is new to the team. Iterating quickly lets you learn and adjust, rather than committing to a technical architecture you'll regret
When Waterfall Actually Makes Sense
Waterfall gets unfairly criticized. For certain types of projects, it's genuinely the better choice.
- Regulatory requirements demand documentation. Medical devices (FDA), aviation software (DO-178C), banking systems (SOX compliance) require extensive upfront documentation. Agile can satisfy these requirements, but the overhead of doing so often negates the benefits
- Requirements are truly fixed. Migrating a database, replacing an ERP system, implementing a spec-defined protocol — when the end state is known and won't change, planning upfront is more efficient than iterating
- Dependencies are external and sequential. Building a bridge: foundation → structure → electrical → plumbing. Software that coordinates with hardware, construction, or government approvals often follows Waterfall naturally
- Fixed-price contracts. When a client wants a fixed price, you need a fixed scope. That's Waterfall. You can run Agile internally within phases, but the external contract is Waterfall
Hybrid Approaches (What Most Teams Actually Do)
In practice, almost nobody runs pure Agile or pure Waterfall. Most teams use a hybrid.
Water-Scrum-Fall (Most Common Hybrid)
Waterfall for high-level planning (phases, milestones, budgets), Scrum for execution within each phase. Product managers define what needs to happen in each phase; the development team uses sprints to deliver it. This is how most enterprise software projects actually work, even if they claim to be "Agile."
Agile with a Fixed Scope Phase
We use this for client projects: spend 2-3 weeks doing discovery and planning (Waterfall-style). Define scope, architecture, and timeline. Then execute in 2-week sprints (Agile-style), with flexibility to adjust within the agreed scope. This gives clients the predictability they need while preserving flexibility in implementation.
SAFe (Scaled Agile Framework)
For organizations with 50+ developers working on a shared product. Essentially Agile at the team level, Waterfall at the program level. We have mixed feelings about SAFe — it adds significant process overhead, but for large organizations that need coordination across many teams, it's better than chaos.
Scrum vs Kanban vs Scrumban
Within Agile, the Scrum vs Kanban choice matters more than most people think.
| Aspect | Scrum | Kanban | Scrumban |
|---|---|---|---|
| Cadence | Fixed sprints (2 weeks) | Continuous flow | Sprints with continuous replenishment |
| Planning | Sprint planning every 2 weeks | Just-in-time — pull next item when capacity opens | Light sprint planning + pull-based execution |
| Best for | Feature development with predictable cadence | Support teams, ops, continuous delivery | Teams transitioning from Scrum or doing mixed feature/support work |
| WIP limits | Sprint backlog is the WIP limit | Explicit WIP limits per column | WIP limits with sprint boundaries |
| Our recommendation | Product teams building features | DevOps, support, maintenance teams | Teams doing 50/50 features and support |
What We've Learned Running Both
After managing 100+ projects across both methodologies, here's our honest assessment:
- Bad Agile is worse than decent Waterfall. A team doing "Agile" with no retrospectives, no demos, no estimation, and sprints that are just 2-week waterfalls — that's not Agile, it's chaos. At least Waterfall has structure
- The methodology doesn't fix team dysfunction. If your team has unclear ownership, poor communication, or no technical leadership, switching from Waterfall to Agile won't help. Fix the team first
- Estimation is hard in both. Agile just makes it more visible (you know you're off track after 2 weeks, not 6 months). See our guide on software estimation techniques
- Client-facing projects almost always need a hybrid. Clients want fixed timelines and budgets (Waterfall) with the ability to change their mind (Agile). The hybrid approach with a discovery phase works best
Frequently Asked Questions
Can Agile work with fixed-price contracts?
Yes, but with trade-offs. Fix the price and timeline, but allow scope flexibility within a defined range. The client gets budget certainty; the team gets flexibility to adjust features based on what they learn. Define "must-have" vs "nice-to-have" features upfront — the must-haves are guaranteed, nice-to-haves adjust to fit.
Is Waterfall dead?
Not at all. Waterfall is alive and appropriate in construction-like projects, regulated industries, hardware-software integration, and any project where requirements are truly stable. What's dead is using Waterfall for product development where learning and adaptation are essential.
Do we need a Scrum Master?
For teams new to Scrum, a dedicated Scrum Master helps enormously for the first 3-6 months. After that, the role can be rotated among team members. For experienced Agile teams, a full-time Scrum Master often isn't needed — the engineering manager or tech lead can facilitate ceremonies.
How do we transition from Waterfall to Agile?
Start with one team, not the whole organization. Run a pilot project using Scrum for 3 months. Keep the ceremonies (standup, planning, retro, demo) even when they feel awkward. Get a coach for the first few sprints. The biggest challenge isn't process — it's mindset. Stakeholders need to accept that scope will flex to fit time, not the other way around.