Right, let's get something out of the way. If you've ever sat through a project update and heard phrases like "sprint velocity," "backlog grooming," or "we need to refine the definition of done" - and your main thought was I have absolutely no idea what any of that means, but I'm nodding because I'm paying these people £800 a day - this article is for you.
Not for the project manager. Not for the developers. For you. The person who signed the statement of work, who has to explain the investment to the board, and who is ultimately going to be judged on whether the thing actually delivered.
I've managed agile projects for the best part of fifteen years - law firms, financial services businesses, SaaS companies, consultancies, membership bodies. And I can tell you with some confidence that the single biggest factor in whether an agile project succeeds or fails isn't the methodology. It's whether the client understands their role in it.
That's not a criticism. It's a design flaw in how our industry explains itself.
Agile is a way of delivering a project in short, regular cycles - usually two weeks - instead of planning everything upfront and hoping it all comes together at the end. Each cycle produces something visible. You review it. You give feedback. Priorities get adjusted. The next cycle starts.
That's it. That's the core of it. Everything else - the Scrum boards, the standups, the retrospectives - is just machinery to make that cycle work smoothly. Important machinery, but not your problem. Your problem is knowing what to expect, what's expected of you, and how to tell whether it's going well.
So let me walk you through that.
If you've commissioned digital projects before, you've probably experienced what's sometimes called "waterfall" delivery. Write a long specification at the start, agree a fixed price and timeline, then wait several months to see the finished product. It feels safe. It feels controlled. And in my experience, more often than not, it ends in a painful conversation about why the thing that was delivered doesn't match what you thought you asked for.
I was involved in a project about eight years ago - a law firm, around 200 fee earners - where we inherited a waterfall project that had gone sideways. The firm had spent five months writing a 94-page specification document. Ninety-four pages. The agency had then spent four months building to that spec. When the firm finally saw the working product, their first reaction was "this isn't what we meant." But it was, technically, exactly what the spec described. The problem was that nobody - not the firm, not the agency - could hold 94 pages of abstract requirements in their head and accurately picture the outcome.
That project ended up costing roughly twice what it should have, and taking three times as long. Not because anyone was incompetent. Because the process assumed you could predict everything at the start and execute perfectly in the dark.
Agile exists to solve that problem. Instead of one big reveal at the end, you get a small reveal every two weeks. Instead of betting everything on a specification written before anyone's done any real work, you make lots of smaller bets, each informed by what you've learned from the last one.
For you as the client, this means a few things. You see working progress regularly - not a slide deck, not a wireframe, but actual working functionality you can click on, test, and react to. You can change your mind. Not unlimited changes, I'll come back to that, but if something isn't right, or if your priorities shift, that can be reflected in the next cycle rather than triggering a formal change request that costs £15,000 and delays everything by six weeks. And you get value earlier. In a well-run agile project, you'll often have something usable before the whole project is finished. We delivered a portal for a membership body a couple of years ago where the member login and CPD tracking were live and being used while we were still building the event registration module. That's not cutting corners. That's delivering value incrementally instead of holding everything hostage until the last piece is done.
Agile seems like 'making it up as we go.' How can I control costs and scope?
I hear this constantly, and honestly, I have some sympathy. Because bad agile does look exactly like making it up as you go. I've seen agencies use "we're agile" as a get-out-of-jail-free card for not having a plan. That's not agile. That's just disorganised.
Good agile has a plan. A clear one. The difference is that the plan lives at two levels. There's a high-level roadmap that says "here's what we're building, here's roughly how long it'll take, and here's what it'll cost." And then there's a detailed plan for the next two-week cycle that says "here's exactly what we're doing right now." The first level gives you budget confidence. The second gives you course-correction ability.
Think of it like driving from London to Edinburgh. You know the destination, you know roughly how long it'll take, and you've got a route planned. But if there's a three-hour delay on the M1, you don't just sit in it because the plan said M1. You reroute. The destination hasn't changed. The budget hasn't changed. The specific path adapts to reality.
Scope control in agile works through prioritisation, not prediction. At the start of the project, you agree what's in scope - but you also agree, and this is the bit that matters, that not everything is equally important. Some things are essential. Some are important. Some would be nice. If time or budget gets tight, the "nice to have" items move down or drop off. That conversation happens openly, in real time, with you in the room. Not as a nasty surprise at the end.
Here's the thing nobody tells you when you commission an agile project: you have a job. Not in the "just let us get on with it and we'll show you the finished product" sense. An actual, ongoing, time-consuming job.
In my experience, the number one predictor of whether an agile project goes well is the quality and availability of the client-side decision-maker. Not the budget. Not the technology. Not even the quality of the delivery team, although obviously that matters. Whether the person who can say "yes, that's right" or "no, change direction" is present, engaged, and empowered to make calls.
What does that look like in practice?
You need to be available. Not full-time. But reachable within a working day for decisions. If your delivery team hits a fork in the road, "should the enquiry form ask for company size or not?", and they can't get an answer for two weeks, that two-week cycle is going to deliver very little. I worked with a consulting firm last year where the project sponsor was brilliant, deeply engaged, understood exactly what she wanted. She was also running three other major initiatives and travelling two weeks out of every four. The project took nearly twice as long as it should have. Not because of the delivery team. Because decisions queued up waiting for her.
You need to review work regularly. Every two weeks, you should be looking at what's been built. Not a ten-minute glance on your phone between meetings. A proper review where you click through things, test them against real scenarios, and give honest feedback. "This looks fine" is the most dangerous phrase in agile delivery. It usually means "I haven't really looked at it properly but I don't want to slow things down." And then three months later, you're looking at the finished product thinking this isn't what I meant.
You need to make prioritisation calls. This is the one that catches people off guard. In agile, you're not just reviewing the work - you're actively involved in deciding what gets worked on next. If the delivery team comes to you and says "we've got budget for six more features, but we think these three are more impactful than those three," you need to be in that conversation. Because nobody else knows your business well enough to make that call.
A quick aside on this: one pattern I see a lot is clients who delegate their role to someone too junior. They'll nominate a marketing coordinator or a project administrator as the day-to-day contact, and then wonder why the strategic decisions aren't landing right. The person in the room needs the authority to say "yes, build it that way" without checking with three people above them. If that's not you personally, it needs to be someone you trust and have explicitly empowered.
You don't need to understand the methodology to evaluate whether an agile project is on track. You just need to pay attention to a few things.
Visible progress every two weeks. Non-negotiable. At the end of every cycle, you should be able to see something new that works. If the team is showing you plans, or talking about what they're going to build next, or explaining that they've been "setting up infrastructure" for three consecutive cycles - something's wrong. Good agile teams show, they don't tell. Even in early cycles when the foundations are being laid, a competent team will find a way to show you something tangible.
Scope conversations are happening openly. In a healthy project, you'll regularly hear things like "we think feature X is going to take longer than we estimated - here are three options for how to handle that." This might feel uncomfortable. It might feel like bad news. It's actually the opposite. It means the team is being honest with you about trade-offs instead of quietly cutting corners or blowing through the budget.
Decisions are getting made. If your project has a growing list of "things we need to decide" that nobody's deciding, you're in trouble. One of the things that distinguishes well-run agile projects is a relentless focus on unblocking decisions. If they're piling up, ask why. Often it's because nobody's sure who has the authority, or because the delivery team is being too polite to push for an answer.
The backlog is getting shorter. The backlog is just the list of everything that still needs doing. In a healthy project, it shrinks over time. If it's growing, if more items are being added than completed, you need to understand why. Sometimes it's legitimate: you've discovered something new that genuinely needs building. Sometimes it's a sign that scope is creeping and nobody's having the honest conversation about it.
The warning signs are usually subtle at first. That's what makes them dangerous.
Sprints with no visible output. "We've been working on backend infrastructure" is sometimes true. But if you've heard it for three consecutive cycles and you still can't see anything you can click on, push back. Hard.
Your feedback isn't being reflected. You reviewed something two weeks ago and said "this doesn't work for us." The next review shows the same thing, slightly tweaked. That's a team that's either not listening or doesn't agree with you but won't say so. Either way, it needs addressing immediately.
Nobody's talking about trade-offs. If every update is "everything's on track, all good," be suspicious. Real projects have friction. Real projects involve difficult choices. If nobody's bringing you difficult choices, they're either making them without you or pretending they don't exist.
The relationship feels transactional. This is harder to pin down, but it matters. In a good agile engagement, you should feel like you're working with the delivery team, not watching them from behind glass. If every interaction is a formal meeting with an agenda and minutes, and there's no informal back-and-forth between cycles, the collaborative bit of agile has been lost. You're just doing waterfall with shorter intervals.
I had a conversation recently with the COO of a financial services firm who'd been through two failed agile projects before working with us. She said something that stuck with me: "Both agencies told me they were agile. But in both cases, I felt like a spectator. They'd show me things, I'd comment, and then they'd go away and do whatever they were going to do anyway." That's not a methodology problem. That's a relationship problem wearing an agile badge.
I want to be honest about something. Agile asks more of you as a client than traditional project delivery does. It asks you to be present, to make decisions under uncertainty, to accept that the plan will evolve, and to trust that evolving doesn't mean failing.
And in return, it asks the delivery team to be transparent about progress, honest about problems, and disciplined about delivering value in every cycle. Not just busy work. Actual value.
When both sides hold up their end, agile is genuinely the best way I've seen to deliver complex digital work. Not because the methodology is magic - it's honestly pretty straightforward. But because it creates a rhythm of visibility, feedback, and course-correction that catches problems when they're small instead of discovering them when they're catastrophic.
When one side doesn't hold up their end, when the client disappears, or the delivery team hides behind process, it can feel worse than waterfall. Because at least with waterfall, you knew where you stood. Bad agile is a special kind of frustrating.
So before you commission your next project, or if you're in the middle of one now, ask yourself two questions. First: do I understand what's expected of me, and am I genuinely willing to commit that time? Second: is my delivery partner being transparent enough that I can tell whether this is working?
If the answer to both is yes, you're probably in good shape. If either answer is no, you've found the thing that needs fixing - and it's not the methodology.