#CS#Methodology#Agile#Waterfall
Agile vs Waterfall: Speed vs Stability
Waterfall follows the plan rigorously. Agile adapts to change swiftly. Which suits your team? Agile isn't always the answer.
June 2, 2025
Codemapo
Waterfall follows the plan rigorously. Agile adapts to change swiftly. Which suits your team? Agile isn't always the answer.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.
Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?
Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?
Establishing TCP connection is expensive. Reuse it for multiple requests.
If you're a developer, this scene is familiar. The product manager changes specs 3 days before the deadline, saying "This is simple, right?" The designer requests "Just move this button 1 pixel" right before deployment. The developer screams "No, we have to rebuild the entire DB structure!"
Countless geniuses pondered how to break this eternal cycle of pain. The result was two massive streams: Waterfall and Agile. At first I thought "Isn't it just old way vs new way?" but I learned they have completely different philosophies for handling uncertainty.
When I first managed a project, I struggled a lot because I didn't understand this difference. I saw many cases where teams claimed to be "Agile" but actually worked like Waterfall, or tried to force Agile in situations that needed Waterfall and failed. Now I clearly understand why each methodology exists and when to use it.
Waterfall, as the name suggests, is like water falling from top to bottom - you cannot go back up. This approach originally came from Architecture and Manufacturing.
Waterfall isn't "bad." When failure costs are astronomical, Waterfall is essential.
But Software is, as the name suggests, "Soft." It's not a building made of concrete. If you build according to the design for 6 months, and during that time a competitor releases a better feature? Our product becomes garbage the moment it launches. This is Waterfall's biggest weakness: "inability to handle change."
When I first did an SI project, we worked hard for 6 months, but when we finally launched, the customer said "Oh, this isn't it..." That's when I realized. Software isn't a building.
In 2001, 17 developers met at a ski resort in Utah. (Legendary figures like Kent Beck and Robert Martin.) They declared: "We cannot predict the uncertain future. So let's adapt to change rather than follow a plan."
The essence of Agile is "build short, get criticized fast." Break a 1-year project into 2-week units (Sprints).
This way, the probability of building the wrong thing after 1 year approaches 0%. You can correct direction every 2 weeks (Pivot).
At first I thought "Deploy every 2 weeks? Is that possible?" but when I actually tried it, it was really effective. Getting customer feedback quickly drastically reduced the time spent going in the wrong direction.
Agile is a "Mindset," and the methodologies (Frameworks) for actually practicing it are separate.
The most widely used framework. Borrowed from rugby terminology.
Originated from Toyota car factories.
To Do → Doing → Done.Doing column."
If Scrum focuses on "management," XP emphasizes "technical practices."
"Working with Scrum while using XP techniques" is the ultimate combination. When I tried this combination with my team, I experienced noticeably improved code quality.
Many companies say "We're Agile." But the reality is:
This is called "Water-Scrum-Fall." Scrum on the surface, but still vertical Waterfall inside. Without Agile's core "Empowerment" and "Failure Tolerance" culture, Agile degenerates into just "a tool to squeeze developers." Whipping with "Finish in 2 weeks no matter what!" isn't Agile, it's a Death March.
When I first worked with a team that claimed to be "Agile," I experienced this fake Agile. They did standups but they were meaningless, they did sprints but plans didn't change... That's when I realized. Agile is culture, not form.
Retrospectives are the flower of Agile. Without retrospectives, it's not Agile. Many teams end retrospective time with "Good work everyone" or fight while blaming others. For proper retrospectives, I recommend the KPT (Keep, Problem, Try) method.
It's not just time to write a reflection. It's time to refactor how we work. Don't just refactor code, refactor the team's process too.
If you're doing Agile and asking "How many hours will this take?" you're a beginner. In Agile, we estimate Size instead of Time. This is called Story Points.
Use these agreed points to adjust the sprint workload. "Our team handled 30 points last time, so let's only take 30 points worth of work this time." This is the secret to creating Sustainable Velocity.
At first I thought "What is this nonsense?" but when I actually tried it, it was much more accurate than time estimation. Comparing relative sizes was actually clearer.
"How do you do Scrum with 500 team members?" When a startup grows, one Scrum team can't handle it. This is when Spotify's organizational structure emerged. (Rumor has it Spotify doesn't use it anymore, but it became industry standard terminology.)
The core of this structure is "harmony of Autonomy and Alignment." Each Squad decides autonomously, but maintains technical alignment through Chapters.
| Feature | Waterfall | Agile |
|---|---|---|
| Suitable For | Construction, Hardware, Financial Systems | Startups, Web/App Services, AI |
| Requirements | Fixed at start (Unchanging) | Continuously changing (Welcome) |
| Customer Participation | Only at start and end | Throughout entire process |
| Failure Timing | At project end (Disaster) | After 2 weeks (Opportunity) |
| Team Structure | Separated Planning/Design/Dev teams | Functional purpose organization (Squad) |
| Documentation | Extensive and detailed | Just Enough |
Agile isn't always the answer. If you're building a bank's ledger migration system, money disappearing while "being Agile" would be disastrous. Thorough Waterfall is right. But if you're building a "new service where market reaction is unknown," Waterfall is suicide.
What matters isn't the methodology's name. "Are we fighting uncertainty, or are we fighting complexity?" If it's uncertain, execute quickly and fail quickly. That's the cheapest path.
What I realized through various projects is that methodologies are just tools. What matters is choosing the right tool for our team's situation. Whether Agile or Waterfall, if the team runs well and customers are satisfied, that's the answer.
"Agile is not about going faster. It is about learning faster."