Agile vs Waterfall Is the Wrong Executive Question

Agile versus Waterfall is often presented as a delivery decision.

Which method should we use?

Which framework should we adopt?

Which approach is faster?

Which one gives us better control?

These questions start with the method.

The executive question should start somewhere else.

What delivery approach best fits the work, the uncertainty, the risk and the outcome we need?

Agile and Waterfall are delivery approaches.

Neither is a transformation strategy.

Neither removes the need for governance.

Neither removes executive decisions.

Neither guarantees business outcomes.

The choice should follow the nature of the work.

Start with the outcome

Every transformation has an intended outcome.

Revenue growth.

Cost reduction.

Better customer experience.

Improved resilience.

A new operating capability.

A different way of working.

The delivery approach should support the outcome.

Start by asking:

What are we trying to change?

What outcome needs to be achieved?

What must be true for the outcome to exist?

Which parts of the solution are known?

Which parts still need to be learned?

Which constraints cannot move?

The answers shape the delivery approach.

Starting with Agile or Waterfall reverses the decision.

Uncertainty changes the delivery problem

Some transformation work is relatively well understood.

The requirements are clear.

The technology is established.

The dependencies are known.

The operating model is familiar.

Other work contains significant uncertainty.

The organisation is testing a new capability.

Customer behaviour is uncertain.

The technology is unfamiliar.

The operating model needs to evolve.

The solution needs to be learned through delivery.

These situations create different delivery requirements.

An iterative approach is useful when learning needs to happen during delivery.

A more sequential approach is useful where dependencies, controls or integration requirements require greater upfront definition.

The point is not to choose one philosophy.

The point is to match the approach to the work.

Agile does not remove delivery discipline

Agile is sometimes misunderstood as less structure.

Less planning.

Less documentation.

Less governance.

Less control.

Enterprise delivery does not work this way.

A technology-enabled transformation still needs business readiness.

Data migration still needs to work.

Users still need training.

Regulatory requirements still need to be satisfied.

Legal and commercial obligations still need attention.

The solution still needs testing.

Documentation still matters.

Formal handover still matters.

Agile changes how work is organised and delivered.

Agile does not remove the responsibilities surrounding enterprise delivery.

A delivery team might work iteratively while the wider transformation still requires formal controls.

This distinction matters.

The delivery method describes how work progresses.

It does not define every responsibility required to make the transformation succeed.

Waterfall does not mean poor delivery

The opposite assumption is equally unhelpful.

Waterfall is sometimes treated as outdated.

A sequential approach might be appropriate where:

- requirements are sufficiently understood

- dependencies need to be resolved in sequence

- regulatory controls require defined gates

- complex integration needs coordinated planning

- changes become expensive after a particular point

- business readiness needs formal approval

The delivery approach should reflect the work.

Calling an approach Waterfall does not make the approach weak.

Calling an approach Agile does not make the approach effective.

Ask how much uncertainty you need to resolve

One useful executive question is:

What do we still need to learn?

If the answer is very little, extensive iteration might add unnecessary complexity.

If the answer is substantial, forcing every requirement into a fixed plan creates a different problem.

The delivery model needs to accommodate the uncertainty.

This is why iterative planning has value.

Iterative planning supports progress without requiring the entire finished product to be understood at the outset.

Strong collaboration between the client and delivery team also helps maintain control over key design and delivery decisions.

But learning needs boundaries.

An experiment needs a hypothesis.

An iteration needs an objective.

A backlog needs prioritisation.

A release needs acceptance criteria.

A transformation still needs an outcome.

The backlog is not the strategy

Agile delivery often creates a product backlog.

The backlog contains requirements.

Those requirements need sequencing.

The sequence should consider:

Business value

Dependencies

Risk

This creates an important distinction.

A backlog manages delivery work.

A strategy determines which outcomes deserve investment.

The two need to remain connected.

If the backlog becomes the primary transformation strategy, delivery activity starts to replace strategic choice.

A team becomes busy.

The backlog gets smaller.

Sprints continue.

The transformation still might not be producing the intended business outcome.

The delivery view needs to connect back to value.

Decision rights matter more than methodology labels

Agile delivery often depends on empowered decision-making.

Someone needs authority to make functional decisions quickly.

Someone needs to resolve priorities.

Someone needs to accept trade-offs.

Someone needs to decide when the product is ready.

Those decision rights need to be explicit.

The same applies outside the delivery team.

Who decides funding?

Who resolves cross-programme dependencies?

Who accepts material risk?

Who changes scope?

Who changes sequence?

Who decides when an initiative should stop?

The delivery method does not answer these questions.

Governance does.

This connects directly to an earlier Journal principle:

Governance should be designed around decisions, not meetings.

Enterprise transformations rarely fit one method

Large transformations contain different types of work.

A customer-facing product might benefit from iterative delivery.

A data migration might require tightly controlled sequencing.

A regulatory change might require formal approval gates.

An operating model redesign might require experimentation and staged adoption.

A technology platform might combine iterative development with formal architecture and release controls.

Treating the entire transformation as Agile or Waterfall hides these differences.

The better question is:

Which approach fits each part of the work?

This does not mean selecting methods randomly.

The transformation still needs an integrated delivery model.

Roadmap.

Governance.

Dependencies.

Accountabilities.

Architecture.

Business readiness.

Risk.

Commercial arrangements.

The delivery approaches need to work together.

Hybrid is not the answer by default

“Hybrid” is sometimes presented as the safe answer.

Use Agile where useful.

Use Waterfall where necessary.

Combine the two.

Move on.

The problem is that hybrid describes a combination.

It does not explain the decision.

A credible delivery model should explain:

Why is this approach being used?

Where does the approach apply?

What risk does the approach address?

Which decisions remain central?

Which decisions are delegated?

How are dependencies managed?

How is business readiness controlled?

What evidence tells us the approach is working?

Hybrid should therefore be a consequence of the work, not a compromise between competing preferences.

Test the approach before scaling it

The delivery approach itself deserves testing.

If a strategy depends on unfamiliar technology, a prototype can test the technical concept and expose capability gaps.

A live pilot might test commercial or customer assumptions.

Delivery teams should be involved early because they understand what will be required to put the strategy into operation.

Governance should also evolve as an initiative expands across the organisation.

This suggests a useful principle:

Do not scale an untested delivery assumption.

Test the approach.

Learn from the evidence.

Adjust the model.

Then scale.

Procurement needs to follow the delivery model

The delivery approach also affects commercial design.

An Agile environment does not always fit a conventional fixed specification and fixed-price model.

Where scope evolves, the commercial model needs to recognise the uncertainty.

This matters because procurement decisions influence delivery behaviour.

Commercial incentives influence supplier behaviour.

Contract structures influence flexibility.

A transformation cannot separate delivery method from the commercial model supporting delivery.

The roadmap still matters

Agile does not mean abandoning the roadmap.

The roadmap should remain connected to:

- business outcomes

- dependencies

- capacity

- risk

- business readiness

- competing priorities

The sequence should evolve as evidence changes.

The roadmap should therefore provide direction without pretending uncertainty does not exist.

This is disciplined adaptability.

Not fixed planning.

Not uncontrolled iteration.

The executive test

Before approving a delivery approach, ask seven questions.

1. What outcome are we trying to deliver?

2. What do we know today, and what still needs to be learned?

3. Which risks require stronger control?

4. Is meaningful value deliverable incrementally?

5. Who has authority to make delivery decisions?

6. Which dependencies require coordination outside the delivery team?

7. What evidence will tell us the chosen approach is working?

If the discussion focuses mainly on Agile versus Waterfall, these questions have probably not been answered.

From methodology to delivery choice

A useful decision chain is:

Outcome → Uncertainty → Risk → Delivery Characteristics → Decision Rights → Delivery Approach → Evidence

The sequence matters.

The outcome establishes the destination.

Uncertainty determines how much learning is required.

Risk determines where stronger control is needed.

Delivery characteristics describe the nature of the work.

Decision rights establish who makes the necessary choices.

The delivery approach follows.

Evidence then tells us whether the approach is producing the intended result.

The approach itself should remain open to change.

A delivery model that worked at the beginning of a transformation might become inappropriate as the work moves into a different phase.

The organisation learns.

The work changes.

The delivery approach should respond.

The executive question

Agile versus Waterfall is an attractive executive debate because the labels are simple.

Transformation delivery is not.

The better question is harder:

What delivery approach gives this work the best conditions to produce the intended outcome?

The question forces leadership to consider uncertainty, risk, dependencies, decision rights, capability and evidence.

It also keeps methodology in its proper place.

The delivery method should serve the transformation.

The transformation should not serve the delivery method.

And once the delivery approach is chosen, another constraint becomes visible:

Does the organisation have enough capacity to deliver the transformation it has chosen?