Why Are We Always Chasing Deadlines?
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: The Romance of "Perfect Design"
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.
The Process: Once You Pass, It's Over
- Requirements Analysis: Document everything the customer wants. (Hundreds of pages of documents at this stage.)
- System Design: Complete DB schemas, architecture, UI planning perfectly. Drawing the "blueprint" stage.
- Implementation: Just code according to the design. You cannot change the plan at this stage.
- Testing: Catch bugs after everything is built.
- Maintenance: Fix after launch.
When Waterfall Is Needed
Waterfall isn't "bad." When failure costs are astronomical, Waterfall is essential.
- Construction: Can you say "Let's change the bathroom location" after building an apartment to the 10th floor? No. You must design perfectly from the start.
- Medical Devices / Aerospace: NASA can't say "Let's launch the Mars rover and adjust the orbit later." One bug leads to billions in losses or casualties.
- SI Projects: In structures where you get paid only if you deliver exactly 100 features defined in the contract by the deadline, Waterfall is the "safest" choice.
The Tragedy in Software
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.
Agile: "Making Friends with Chaos"
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."
Agile Manifesto: 4 Core Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Core Principle: Feedback Loop
The essence of Agile is "build short, get criticized fast." Break a 1-year project into 2-week units (Sprints).
- During 2 weeks: Do planning, design, development, testing, and deployment all together.
- After 2 weeks: Show working product to the customer.
- Feedback: "This button is uncomfortable." → Immediately reflect in the next 2-week plan.
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 Practice Tools
Agile is a "Mindset," and the methodologies (Frameworks) for actually practicing it are separate.
Scrum: Structured Sprint Running
The most widely used framework. Borrowed from rugby terminology.
- Sprint: Usually a 2-week development cycle. During this period, external interference (plan changes) is blocked.
- Roles:
- PO (Product Owner): Decides "what to build." Customer's representative.
- Scrum Master: "Removes obstacles." Coach who helps the team run well.
- Team: The actual builders.
- Events:
- Daily Standup: 15 minutes every morning. Share "what I did yesterday, what I'll do today, what's blocking me."
- Sprint Review: Time to demo what was built and get applause.
- Retrospective: Time to reflect "what should we fix to do better next time?"
Kanban: The Endless Conveyor Belt
Originated from Toyota car factories.
- Visualization: Stick post-its on whiteboard:
To Do→Doing→Done. - WIP Limit (Work In Progress): Set rules like "only 3 items can be in the
Doingcolumn."- This is key. If work isn't finished, you can't start new work. Team members must swarm to clear the bottleneck.
- Infinite Flow: No periods like sprints. Just deploy immediately when one thing is done. Suitable for maintenance teams.
XP: Extreme Developer Training
If Scrum focuses on "management," XP emphasizes "technical practices."
- Pair Programming: Two people code together on one computer. Real-time code review effect.
- TDD (Test Driven Development): Write test code first.
- CI (Continuous Integration): Merge code dozens of times a day.
"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.
The Reality Gap: "Fake Agile"
Many companies say "We're Agile." But the reality is:
- They do morning standup meetings, but it becomes the manager's sermon time.
- They do sprints every 2 weeks, but the 1-year plan is already fixed.
- "It's Agile so we don't need documentation, right?" and they wing it without planning docs.
- They deploy once every 3 months.
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.
How to Do Retrospectives Well
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.
- Keep: What was good this sprint. "Thorough code reviews caught bugs early, that was good."
- Problem: What was disappointing. (Talk about phenomena, not blame people). "The plan changed during development, so we worked overtime."
- Try: Concrete action items to execute immediately in the next sprint. "From now on, if plans change, we'll agree to extend the deadline by one day."
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.
Story Points and Planning Poker
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.
Why Not Use Time?
- A 1-hour task for a junior is a 10-minute task for a senior. Different standards.
- Development has many variables, so time prediction is inherently impossible.
How to Do Planning Poker
- Team members each have Fibonacci sequence cards (1, 2, 3, 5, 8, 13, 21...).
- Product manager explains the feature. "Build login page."
- On the count of three, everyone plays a card.
- Developer A: 3
- Developer B: 8
- Discuss why there's a difference. (This process reveals hidden complexity.)
- Vote again to reach consensus.
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.
Spotify Model: Scaling Up
"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.)
- Squad: Smallest unit team (6-12 people). Has planning/design/development all together. Moves independently like a "small startup."
- Tribe: Collection of Squads. (e.g., Music Player Tribe, Payment Tribe).
- Chapter: Functional group. (e.g., Android Chapter, Backend Chapter). People using the same technology from different Squads share know-how.
- Guild: Hobby or interest group. (e.g., Wine Guild, Rust Language Guild).
The core of this structure is "harmony of Autonomy and Alignment." Each Squad decides autonomously, but maintains technical alignment through Chapters.
Comparison Summary
| 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 |
Wrapping Up: No Silver Bullet
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."