The claim and the reality
Almost every agency says it works in two-week cycles. Far fewer can put working software in front of a client at the end of one, in an environment the client can click through.
The gap is not discipline. It is infrastructure.
What has to be true
An increment is only meaningful if all four of these hold:
- A deploy is boring. If shipping requires a person, a checklist and a nervous afternoon, it will not happen every two weeks. It will happen quarterly, and the increments become theatre.
- The environment is real. A demo on a developer's laptop proves nothing about whether the software works. There has to be a deployed environment with realistic data.
- Unfinished work can be hidden. Feature flags, not long-lived branches. A branch that lives three weeks is not an increment, it is a merge conflict with a deadline.
- Tests are trusted. If the suite is flaky, people stop reading it, and the safety net that makes frequent deploys survivable is gone.
The order to build them in
Deploy pipeline first, always. Teams routinely start with test coverage and end up with a well-tested system they are still afraid to release.
Get the pipeline working on day one, when the application is trivial and the pipeline is therefore trivial too. Growing it alongside the system is far cheaper than retrofitting it onto something already complicated.
What the client sees
At the end of each increment: a deployed environment, a short demo of what changed, and an honest list of what did not get done and why. No burndown charts, no velocity, no story points presented as though they were a currency.
The demo is the status report. Anything else is a substitute for one.