Inter-dependent activities with milestones and intermediate builds
"Inter-dependent activities with milestones and intermediate builds"

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.

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.


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.

Microservices Split Criterion

Demonstrate rationality of splitting a service into microservices using dependencies between boolean expressions. Continue reading

Shells and Cores

Published on April 02, 2017

Obsessive Line Splitting Disorder (OLSD)

Published on November 13, 2016