Incremental Delivery Is Not a Process Choice. It Is a Discipline Choice.

A former engineer reached out to me recently with a genuine question. He was leading an internal initiative and wanted a second opinion on his delivery approach.

Let us call him S.

S. had structured his work carefully. A bulk delivery, broken down into milestones, aligned with quarterly objectives. The initiative itself made sense. Imagine an electronic transaction hub, capable of executing operations across multiple providers through a single integration layer.

From a planning perspective, the approach looked sound. It would almost certainly deliver results.

Eventually.

That qualifier matters more than most teams admit.

I proposed a different constraint :

What if every delivery, every two weeks, had to reach production?

Not a staging environment. Not a demo account. Production. Using a real production-grade account.

For a SaaS cloud provider, this should not feel radical, should it ? Accounts are cheap. Environments are reproducible. If something cannot run in production, it does not qualify as a delivery. This is not a guideline. It is a rule.

Every Increment Must Change Behaviour

The second constraint followed naturally.

Each increment must correspond to a measurable change in customer behaviour, supported by at least two metrics.

One metric tracks progress. One metric validates success.

Think in vectors rather than checkpoints. Direction matters as much as magnitude. A compass provides more value than a static map.

If an increment does not alter behaviour, then no value has reached the system. Activity occurred, but delivery did not.

This framing forces clarity. It removes vague notions of completion and replaces them with observable outcomes.

Small Enough to Revert, Real Enough to Matter

Incremental delivery introduces a productive tension.

Each delivery must matter, yet remain small enough to undo.

When priorities shift, something already exists in production. When assumptions prove wrong, the team can revert to the previous iteration and adjust. Risk moves forward in time, where it belongs, instead of accumulating silently.

Bulk delivery follows the opposite pattern. Long design phases. Extensive architectural debates. Large surface areas. Feedback arrives late, when reversal carries real cost.

That model does not reduce risk. It defers it.

How This Differs from Quarterly OKRs

S. asked a reasonable question. How does this differ from quarterly OKRs?

Conceptually, very little.

The intent remains identical. Clear goals. Explicit outcomes. Measurable impact.

The difference lies in execution. Many organisations treat OKRs as strategic artefacts, detached from day-to-day delivery. Incremental delivery should operate under the same logic as mid-term goals. Each step proves intent through reality.

Strategy does not live in decks. It reveals itself in production.

Yes, the First Delivery Can Look Almost Empty

Discipline becomes visible at the beginning.

The first API delivery may consist of an empty container. A deployed service returning a successful response without business logic. No transactions. No integrations.

That remains a valid delivery, as long as it lives in production.

It exercises deployment paths. It validates CI and CD. It establishes observability. It confirms that production remains reachable.

The first API gateway may only enforce a linter that always passes. Still valuable. Still real. Still part of the system.

Each increment strengthens the delivery chain and reduces uncertainty.

From Initiative to Story Level, the Same Rule Applies

We applied this logic rigorously on a commercial automotive platform.

Every user story title had to describe a behaviour change, accompanied by metrics of progress and success.

At that granularity, methodological debates lost relevance. Scrum versus Kanban became an implementation detail. When iterations shrink sufficiently, only outcomes matter.

Architecture stops drifting into abstraction. It becomes constrained by immediate use, real users, and real consequences.

That constraint does not weaken design. It grounds it.

What Agility Was Originally About

Agility never referred to ceremonies or frameworks.

It referred to the ability to place value in users’ hands quickly, observe the effects, and adapt based on evidence rather than belief.

Incremental delivery represents that principle in its purest form. It replaces promises with proof and intention with demonstration.

This approach demands discipline. Nothing more. Nothing less.

People Over Methods

No process compensates for weak foundations.

Incremental delivery requires engineers who think in systems rather than tickets. It requires product leaders who focus on defining the what, not dictating the how. It requires respect for reality over narrative.

Defining what to build remains an art. Delivering it incrementally remains a craft.

Neither responds to titles or frameworks.

Both respond to disciplined people, working close to production, guided by measurable change.

Because in the end, nothing counts unless it lives in production.