This is Waterfall Software Development

Image credit: wikimedia commons

Waterfall software development is when we carefully plan out everything in advance and then sequentially march towards a single release.

Everyone knows, waterfall software development is bad.

Waterfall is for dinosaurs. 

Image credit: stability ai

This is Professional Scrum™️, the most popular Agile software development methodology.

Image credit: wikimedia commons

Everyone knows, Agile is good!

The Scrum Alliance actually has a much better diagram than this, but it’s copyrighted and I don’t want them to sue me. Professional Scrum™️ is a trademark of the Scrum Alliance. So is Professional Scrum Master™️ and Professional Scrum Product Owner™️.

Sometimes it’s better to just go with the flow

“Waterfall bad, Agile good” is overly reductive.

There have been some Huge Success projects that used Waterfall. The Apollo program was a $250 billion (inflation adjusted) program that put a man on the moon. Their process was mostly waterfall.

On the other hand, Dropbox and Salesforce are two examples of Huge Success companies that adopted Scrum on their way to becoming juggernauts.

What’s the difference here?

For the Apollo program avoidance of failure depended on the proper application of science, so they (kind of) knew what success looked like from the very beginning. On the other hand, Product Market Fit is governed by fuzzy social “sciences” like economics and psychology.

But I thought Agile and Waterfall are opposites, right?

So why is the title of this post How to make a Waterfall Agile™️?

AGILE | English meaning – Cambridge Dictionary

I love this mental image of “monkeys are very agile climbers.” How can an agile team move like a monkey? Let’s take a moment and watch this video.

How to Move Like a Monkey | National Geographic

What do you notice? He’s constantly adjusting his path. He’s not moving in a straight line.

A thought experiment

Let’s say we are a hypothetical startup NewCo that just raised $1,500,000 and spends $500k/year. We have three years of runway. On this graph the arrow to the right represents time (or money. time is money, after all). If NewCo can get to Product Market Fit before they run out of money, they can raise a juicy Series A.

But this simple linear example isn’t the way the world works. Finding Product Market Fit is not the Apollo Program because startups are by definition trying to build something new, something unknown. We don’t know what success looks like and we don’t know exactly how we will get there.

Because we don’t know precisely where Product Market Fit is, it’s more useful to think of this as a probability cloud.

What if PMF wasn’t right in the center of the probability cloud? We might miss it!

In fact, a vanishingly small percentage of startups find PMF. Failure is the most likely outcome.

In those three years, we hopefully learned a lot along the way. That means the probability cloud got smaller! Unfortunately we also see that the center has moved, we are out of money, and we missed PMF.

If a startup uses a Waterfall process, there are no opportunities to change direction along the way.

So let’s break that line up into pieces.

Ideally, we do a little work, we learn a little more about our customers, and the point cloud target gets a little smaller.

Coming back to the Scrum diagram, each line segment is a Sprint.

And every time we start a new Sprint, we learn and the point cloud becomes smaller and easier to hit.

Each new Sprint gives us an opportunity to steer towards a new heading.

In this mental model, successfully finding Product Market Fit depends on a few things:

1. 🔼 The more we learn about our customers, the smaller the probability cloud.
   1. Lesson: Optimize for learning, not feature growth. 🔽
2. ⏱️ The sooner we learn about our customers, the direction of our vectors will be more accurate. 🎯
   1. Lesson: Frontload learning, the benefits of learning compound over time.
3. 🔁 The more frequently we change the plan according to new information, the smoother our path will be. 👣
   1. Lesson: Well informed changes in the plan are good and should not be avoided.
4. 🏆 We have to accomplish all of this before we run out of money. 💸
   1. There’s no lesson here. This is just a reminder to hurry!

Finding Product Market Fit is obviously much more complicated than that, but these attributes are “table stakes.”

Here come the Triangles

The next spicy ingredient in our shamefully mixed metaphor is the Iron Triangle from project management.

The Iron Triangle states that:

Scope, cost, and time. You can’t change all three without sacrificing quality, so pick two.

Or mathematically:

ΔCost + ΔTime – ΔScope ≥ ΔQuality

Alternately:

TANSTAAFL – “There Ain’t No Such Thing as a Free Lunch”

The calculus is easier if we assume the horse is a sphere.

image credit: Dall-E prompt “assuming the horse is a sphere”

In an agile startup seeking Product Market Fit:

• If we hold team size constant, Time and Cost are roughly equivalent
• Time+Cost is effectively the same as our runway.
• Quality is effectively the same as Product Market Fit..

Δrunway – Δscope ≥ ΔPMF

But this is a startup. runway can be considered fixed because we are unlikely to raise more funding unless we find PMF.

Δscope ≥ ΔPMF

This equation says “well designed increases in scope might lead to Product Market Fit, but it’s also possible to increase scope and not increase PMF.”

But wait – the Iron Triangle is only “iron” when we know exactly what we need to build. In a startup, scope of PMF is uncertain – it’s a point cloud.

May the Ghost of Heisenberg forgive me for what I am about to do

Looking at a point cloud reminds me of the Heisenberg Uncertainty Principle, a fundamental concept from Quantum Mechanics that states:

there is a limit to the precision with which certain pairs of physical properties, such as position and momentum, can be simultaneously known. In other words, the more accurately one property is measured, the less accurately the other property can be known.

https://en.wikipedia.org/wiki/Uncertainty_principle

Or, much more simply:

The more precisely we know the location of a particle, the less precisely we can know its direction (or visa versa).

⚠️ Physicists in the audience, avert your eyes. I am about to force a contrived metaphor that is not at all grounded in the mathematics of quantum mechanics.  ⚠️

[handwave-y metaphor goes here]

Image credit: Dall-E

From here, if I stand on my head and look sideways, I can contort the mathematics in a way that makes the reduced Iron Triangle look a lot like Heisenberg’s equations.

Dear reader, I’ll spare you from this Quantum Woo arithmetic heresy. Agile project management is not a quantum phenomenon. This is only a sloppy metaphor.

Disclaimer: The Uncertainty Principle is used for illustrative purposes only. No physicists were harmed in the making of this blog post (except maybe their sensibilities).

The Agile Startup’s Uncertainty Principle

Given that in a startup:

• we will know precisely what Runway is
• we won’t know precisely what Product Market Fit is (until we get there)
• the only “high confidence” plan is based on fixed time intervals, not fixed features

So, embrace risk, optimize your roadmap for Learning, not Predictability. And hope we reach the Promised Land.

This is a terrifying and unsatisfying result! I wish there was another conclusion to be drawn. 

You have a fixed budget, embrace the consequences.

But what about that Agile™️ Waterfall?

I want to call attention to the little trademark symbol in the title.

An agile startup is one that learns quickly and changes direction quickly.

An Agile™️ startup is a company that follows a specific certified process, like from the Scrum Alliance.

Ideally, all Agile™️ (certified) companies would also be agile (flexible), but in some cases, they might not be. Just because you are Agile™️ certified, does not mean that you learn and change quickly.

Time for one final definition!

Agile™️ Waterfall

/ˈadʒʌɪlˈwɔːtəfɔːl/

noun

Any long-running project that follows certified Agile processes, but never deviates from its predetermined plan.

“That Agile™️ Waterfall wasted a lot of productivity following processes designed for flexibility it didn’t use”

Agility™️ is not free!

Being agile has a lot of overhead compared to the waterfall method. The following table shows the Scrum Alliance’s recommended meeting times for a 2 week Sprint:

Sprint Planning (incl. Grooming)	4.0
Daily Scrum, x8	2.0
Sprint Review	2.0
Sprint Retrospective	1.5
Total	9.5

That’s 12% of our time dedicated to Scrum alone!

In addition, being (lower-case) agile can be even more expensive. We have science to do:

• create hypotheses
• design experiments
• execute experiments
• measure our progress
• learn from mistakes
• and update our plans

This leaves precious little time runway for building features! We’d better build the right ones.

“Shoot! A fella could have a pretty good weekend in Vegas with all that stuff.”

Being agile sure can be expensive. 😅

But what’s the alternative?

I guess a startup could make detailed plans and carefully execute them all the way into bankruptcy.