In short, the two approaches are thought of as:
- Waterfall: a complex process of inter-dependent milestones to build an “aircraft carrier” instance.
- Agile: independent simple step to get an immediate result (hopefully incremental).
Most of the arguments about their differences seem bogus or pointless to me.
Instead of “waterfall vs agile”, there is only one fundamental factor impacting every development - the instance build cost.
Instance Build Cost
Effects on planning/engineering:
- If you are building a house, the cost is so high that you only build this house once - suggesting a waterfall mode.
- If you are 3D-printing a house, afford few throw-away versions before the final one - suggesting an agile mode.
- And if something is independent, regardless of waterfall or agile, it is instantly done. Otherwise, what is it waiting for (depending on)?
Normally, I consider both:
- build cost - the higher the build cost, the fewer feedback prototypes to see if the direction is right;
- dependency graph - the more dependencies, the “harder” it is to reach the target.
But if you think just a bit, these factors are not even orthogonal - describing dependencies means zooming in on the build cost (breaking it down).
Moving to the contrasts:
- To build a skyscraper version, you need 100000000s of dollars and 10s of months of tracking dependent activities.
- To build a software version, an automated pipeline does it in minutes adding a few dollars to a shared bill.
In other words, “agility” is highly conditional - you do not decide to “go agile”. Instead, you assess the build cost and select the right mode.
Both waterfall and agile belong to each other in dualism like yin and yang - just two extremes for low and high build costs.
Agile emerged in software development and became ubiquitous because of extremely low build cost via automation, not because of the trendy popular rituals.
Popular Rituals
Sprint Planning, Backlog Grooming, Retrospective, Daily Standup…
If activities are not focused on reducing build cost to deliver incrementally, then what is the point?
Human engagement might be the point, but:
- it benefits anything regardless of agile or waterfall,
- it does not require fancily named activities to blur the focus.
Iteration Length
Sprint, or Cycle, or Iteration… any fixed-time planning horizon has nothing to do with deliverables.
What Cycle Length should you use?
- 1 month
- 2 weeks
- 3 days
What relevance does a length have?
- If a task is dependent, it will block on dependencies regardless of when the cycle ends.
- If a cycle is fixed (rather than delivering as soon as ready), this only creates unnecessary dependencies (increasing build cost).
Deliveries in batches may make sense if there is (again) a significant build cost for every rollout (testing, downtime, bureaucracy).
But shouldn’t the build cost be reduced then rather than introducing Sprints with fixed intervals?
Now, some periodicity is induced by continuous progress measurements (daily, weekly, monthly, yearly - anything induced by celestial cycles).
However, my argument is that progress measurements should not impair the progress itself.
Conclusion
Original Agile Manifesto makes sense - move fast and assess where you are often (implies affordable build cost).
Subsequent Agile Movement is a marketing hype to mud the water and sell something “new”.
And if you stuff your waterfall process with periodic prototype builds, you will likely beat agile teams simply by having better planning.