How and when agile working works (and when it really doesn't)

Agile working works when the requirements are genuinely uncertain, the people paying for the software are available to make decisions every week or two, and everyone accepts that the scope will move. It fails when the contract fixes scope, price and date together, when the client cannot spare anyone to review the work, or when the contract or the procurement process requires the whole specification to be approved before a line of code is written. Most of the agile projects we have seen go wrong did not fail because agile is a bad idea. They failed because the conditions agile depends on were never in place.

We have used agile methods on client projects for years, and we have also, quite deliberately, not used them on a few. This post explains the difference in plain terms.

What agile working actually means

Agile breaks development into short cycles, usually one or two weeks, called sprints. In each sprint the team designs, builds and tests a small slice of working software, then shows it to you. You react, the priorities are re-ordered, and the next sprint starts.

The alternative, waterfall, treats the product as a single whole. You specify everything, design everything, build everything, then test everything. Each stage finishes before the next begins.

The classic way to picture the difference is transport. Under waterfall you design the wheels, then the chassis, then the body, and you have nothing usable until the very last day. Under agile you build a skateboard, then a scooter, then a bicycle, then a motorbike. Every stage is something a person can actually ride, and every stage teaches you something about what they want next.

That matters most when the money or the patience runs out early. With waterfall you are left with an unusable half-car. With agile you are left with whatever stage you reached, and every one of those stages was something you could ride.

Where agile genuinely earns its place

The requirements will change and you know it

If you are building something new, a first product, a customer portal nobody in your market has attempted, an internal tool replacing a spreadsheet that four departments each use differently, you do not yet know what you need. You only think you do. Agile turns that ignorance into a schedule of small, cheap corrections rather than one large, expensive one at the end.

You want to see progress you can judge

Working software every fortnight is a far better progress report than a percentage on a Gantt chart. It also exposes trouble early. A feature that looked simple on paper and turns out to be awkward shows up in the first few sprints rather than late in the build.

Risk is spread rather than stacked

Continuous testing means you are never carrying a mountain of unverified work. If a release goes wrong, the blast radius is one sprint. Late-stage integration surprises, the thing that sinks so many fixed-plan projects, largely stop happening because integration is happening constantly.

Business value can be re-ordered

Because the backlog is prioritised each sprint, the features that matter commercially get built first. If your funding round, trade show or contract renewal is in March, you can aim the first four sprints at whatever needs to exist by March and defer the rest. This is where a decent product roadmap does most of its work.

When agile really doesn’t work

Your contract fixes scope, price and date together

You can fix any two of scope, cost and time. You cannot fix all three and still be agile, because agile’s entire value comes from moving scope. If you are procuring under a tender that demands a fixed deliverable for a fixed sum on a fixed date, an agile process bolted on top becomes theatre. Sprints happen, but nothing they discover is allowed to change anything.

That is not always the wrong choice. Sometimes a fixed-scope build with a properly written requirements specification is exactly right, particularly for a well-understood replacement system. Be honest about which one you have bought.

Nobody on your side is available

Agile moves the client from a spectator to a participant. Somebody with authority has to look at the work, answer questions and make decisions, most weeks, for the length of the project. If your only available decision-maker is a director with a diary full for the next quarter, sprints will stall waiting for sign-off and you will get the costs of agile with none of the benefits.

Before starting, name the person. It should be a person, not a committee. Then check they actually have the hours.

The environment demands the specification up front

Some regulated work, in finance, healthcare, safety-critical systems and parts of the public sector, requires demonstrable traceability from an approved requirement to a tested outcome, and some procurement processes insist on the full requirement set being documented, reviewed and approved before build. Where the contract or the auditor is working that way, an evolving backlog creates a problem rather than solving one.

The usual answer is a hybrid: fix the regulated core, run the rest iteratively. We do this fairly often on business application projects where the compliance boundary is narrow and everything around it is not.

The team has adopted the ceremonies but not the intent

This is the most common failure of all. Daily stand-ups become status meetings. Retrospectives produce actions nobody owns. The backlog is a wish list nobody prunes. Estimates harden into promises and then into blame. At that point agile is a set of costly meetings sitting on top of the same waterfall you had before.

The test we apply is whether recent sprints have actually altered the plan. If the backlog has come out of every review in the same order it went in, the process is decorative.

Agile versus waterfall at a glance

Question	Agile suits you	Waterfall suits you
How well do you know the requirements?	Roughly, and you expect to learn	Precisely, and they are signed off
Who decides, and how often are they free?	One empowered person, most weeks	Approved once, at the start
What does the contract fix?	Budget and time, with scope flexing	All three, deliberately
What happens if funding stops early?	You keep the working slices built so far	You have an incomplete system
Approval regime	Light, or bounded to one area	Full sign-off demanded before build

How we run sprints in practice

We keep the one to two week sprint as the unit of work, but a feature passes through three stages rather than being designed, built and signed off inside a single cycle. The plain version tends to leave client testing squeezed into the last afternoon, and that is where the expensive mistakes hide.

• Design. The design for the feature is finalised and agreed before its build sprint opens, so development starts from something settled rather than something being argued about on day two.
• Build. We develop the feature and test it internally during the sprint. Nothing reaches you until it works on our side.
• Client testing and fixes. You test it properly and we correct what you find, before it is called done.

So a given feature is usually in flight across two sprints: it is being designed while the previous batch is being built, and you are testing it while the next batch is under way. The cadence stays regular, but no single sprint carries the whole of one feature’s life.

It sounds like more process. In practice it removes the most expensive kind of rework, which is the sort discovered three sprints after the fact. You can see more of how we structure engagements on our how we work page, and the broader benefits in our post on the advantages of agile development.

Frequently Asked Questions

Is agile always better than waterfall?

No. Agile is better when the requirements are uncertain and the people funding the work can engage regularly. Waterfall is better when the requirements are genuinely fixed, fully understood and must be approved before build begins, which some contracts and procurement processes insist upon. Choosing agile for a project with an immovable scope, price and deadline gives you the overheads of iteration with none of its flexibility. Match the method to the conditions rather than to fashion.

How much client time does an agile project actually need?

The amount varies with the size and complexity of the build, but the shape is consistent. Budget a named decision-maker for an hour or two around each sprint review, however long it genuinely takes them to test the new increment, and enough availability to answer questions within a day or so mid-sprint. That recurs every sprint for the length of the project, and it cannot be delegated to somebody without authority to change priorities. Projects without that availability drift, and the drift costs more than the meetings would.

Can agile work with a fixed budget?

Yes, provided the budget is fixed and the scope is not. This is the most workable arrangement for most businesses: you agree a total spend, we prioritise the backlog so the highest-value features are built first, and you decide when what has been built is enough. Our cost estimator gives a sensible starting range. What does not work is fixing budget, scope and date simultaneously and calling the result agile.

What is a sprint and how long should it be?

A sprint is a fixed period, usually one or two weeks, in which a team designs, builds and tests a defined slice of working software. Shorter sprints give faster feedback but carry more overhead per cycle. Two weeks suits most business software projects. The length matters less than the discipline: the sprint ends on the agreed date whether or not everything is finished, and unfinished work returns to the backlog rather than quietly extending the deadline.

How do I tell whether my current supplier is really working in an agile way?

Ask what changed as a result of the last three sprint reviews. If priorities were re-ordered, features were dropped or added, and you can point to a decision you made that altered the plan, the process is real. If the answer is that everything proceeded exactly as originally scheduled, you are on a waterfall project with stand-ups attached. Also check that you are being shown working software rather than slide decks.

Does agile work for small projects?

It works, but the ceremony needs to shrink with the project. For a short build of a few weeks, a full sprint apparatus is heavier than the work itself. Keep the useful parts, short cycles, working software shown regularly, a prioritised list, and drop the rest. The principle that matters at any size is that you see something real early enough to change your mind cheaply.

Deciding which approach fits your project

If you are unsure whether your project wants sprints or a specification, the deciding factor is usually how confident you are in the requirements and how available your decision-maker is. We are happy to talk that through before anyone commits to a method. Have a look at how we approach custom software development, or get in touch and we will give you a straight answer about which way round would serve you better.