What It Actually Means
The reasoning is sound and worth stating plainly: nobody knows exactly what they need at the start. Not you, and not the people building it. Long detailed plans assume perfect foresight and then get followed past the point where everyone can see they are wrong, because changing the plan looks like failure.
What It Should Mean For You
Agile is described from the developer’s side almost everywhere, so here is what it should actually deliver to the person paying.
You see working software early and often. Not designs, not progress reports. Something that runs, at regular intervals from quite early on.
You can change your mind, at a known cost. Priorities shift between cycles. The next block of work is chosen rather than assumed.
You can stop. This is the underrated one. Because value is delivered continuously, there is a usable product at many points along the way. You are never in the position of having funded eighteen months and holding nothing.
Bad news arrives early. Difficulties surface in week three rather than at the end.
If you are not getting those four things, whatever is happening may be agile internally, and it is not benefiting you.
How It Gets Misused
Two failure modes are worth recognising, because both are common.
Agile as an excuse not to commit. No estimate, no scope, no date, and any question about cost answered with a comment about the impossibility of prediction. Genuine uncertainty exists and it does not remove the supplier’s obligation to help you plan. A good team gives you ranges, tells you what drives them, and revises openly as they learn. “We cannot say” is not agility.
Agile as a label on the old process. Daily meetings and two-week blocks bolted onto a fixed plan that nobody may change. You get the ceremony without the ability to adjust, which is worse than either approach on its own.
What To Ask
- When do I first see something working? Weeks, not months. The answer tells you a great deal.
- What happens at the end of each cycle, and what is my part in it? You should be reviewing and choosing what comes next.
- How do we handle scope and budget? Agile does not mean unbounded. Ask how you will know if it is heading past what you can spend.
- What is the smallest thing that would be genuinely useful? If that can be built first, most of your risk disappears.
The Practical Compromise
Pure agile with an open budget is uncomfortable for most businesses, and it should be. You need to know roughly what this costs.
The arrangement that works is a fixed budget and timeline with flexible scope: the spend is agreed, the date is agreed, and what gets built inside them is decided as you go, highest value first. You keep control of cost, the team keeps the ability to adapt, and if you stop early you stop with the most valuable work already done rather than with a half-finished everything.
That requires the first release to be genuinely small, which is the same discipline as a real MVP, and it is where most of the benefit actually comes from.
More terms are in the glossary.
