The word "agile" has been used to justify so much nonsense over the past fifteen years that I genuinely wouldn't blame you for flinching when you hear it.
We're agile can mean "we have a disciplined, iterative delivery process with clear commitments every two weeks." It can also mean "we don't really have a plan and we'd prefer you didn't ask." The problem is that both versions sound exactly the same in the pitch meeting. And by the time you've figured out which one you bought, you're three months in and £80k lighter.
I want to fix that. Because agile - done properly, by both sides - is genuinely the best way to deliver most digital projects. The Standish Group's CHAOS Report has consistently found that agile projects are roughly twice as likely to succeed and a third as likely to fail outright compared to waterfall. But that data comes with a massive asterisk: agile works when both the delivery team and the client fulfil their roles. Strip out either side, and you get something worse than waterfall - you get waterfall's rigidity with none of its predictability.
This piece is for the managing partner, the COO, the senior sponsor who's approved an agile engagement, or is about to, and wants to know what that actually requires of them. Not the theory. The practical, week-by-week reality of what agile feels like when you're the one paying.
Forget the methodology for a moment. Here's what agile means in terms of how your engagement will actually feel, day to day.
You will see working outputs every two weeks. Not a PowerPoint. Not a wireframe. Working functionality that you can click, test, and react to. This is genuinely different from a traditional project where the agency disappears for four months and comes back with a finished thing. In agile, you're watching the product take shape in real time - which means you can course-correct early, flag problems before they're expensive to fix, and build confidence as you go rather than holding your breath until launch day.
You can reprioritise between sprints. If your business priorities shift mid-project - a new competitor appears, a regulation changes, the board suddenly cares about something different - an agile delivery can accommodate that. But "accommodate" doesn't mean "for free and without consequence." It means: we'll swap something out of the plan to make room for the new priority. Understanding that trade-off structure is part of your job. If you treat every sprint as a chance to add things without removing anything, you don't have an agile project. You have an expanding scope with no end date.
The product is built in working layers. Each increment should be demonstrably functional - not a component waiting for six other components before it does anything. If you're three sprints in and the delivery team is telling you "it'll all come together at the end," that's not agile. That's waterfall in a hoodie.
Your original brief will be challenged - constructively. Here's the bit that catches people off guard. The brief you wrote before delivery started was based on what you thought you needed. Agile's real value is that it surfaces the gap between what you specified and what you actually need while there's still time and budget to do something about it. I was working with a professional services firm last year where the sprint three review revealed that the feature they'd prioritised highest in the original brief - a client-facing document portal they'd been planning for two years - was something almost nobody on their team would actually use day-to-day. What they needed instead was a much simpler status dashboard. We caught it eight weeks in, not eight months in. That's not the process failing. That's the process working.
Right, this is the bit where I get a little direct. Because there are three misrepresentations of agile that I encounter so frequently they've become almost standard.
"We'll make it up as we go." Agile has a defined structure. Sprint planning, daily standups, sprint review, retrospective. A delivery team that can't describe that structure clearly to you isn't doing agile. They're doing unstructured delivery with a trendy label stuck on it. If someone tells you they're "agile" but can't explain what happens in a sprint review versus a retrospective, push back. Hard.
"There's no plan." An agile project has a product backlog (the full list of things that need building, in priority order), a sprint plan (what's being built in the next two weeks), and defined success criteria for each piece of work. The difference from waterfall isn't that the plan doesn't exist - it's that the plan is held more lightly and updated more frequently. Think of it less like a blueprint and more like a sat nav that recalculates when conditions change. The destination is still agreed. The route might flex.
"Scope is unlimited." This one really gets on my nerves. The sprint commitment defines what's being delivered in each two-week period. Changes outside that commitment go through a formal process with a clear impact assessment. "We're agile so anything can change at any time" isn't agile practice. It's a governance failure that someone has put a nice name on. If your delivery partner says this to you, they're either inexperienced or they're managing your expectations downward so they can charge you for changes later.
I've heard 'agile' used to justify everything from 'we don't have a plan' to 'we'll charge you for changes.' I'm not sure what it actually means.
If that's where your head is, honestly, fair enough. You've probably been burned - or watched someone else get burned. The difference between real agile and "agile as an excuse" is simple: real agile has structure, commitments, and transparency. The counterfeit version has none of those things but uses the same vocabulary. By the end of this piece, you'll know which one you're looking at.
Here's what nobody tells you in the sales process: agile places specific, non-optional commitments on you as the client. Miss them, and it doesn't matter how good the delivery team is. The project will drift.
You need to be available for decisions. This is the single biggest client-side failure I see. In a two-week sprint, a decision deferred by three days affects 30% of the delivery window. Thirty per cent. In a waterfall project, three days of delay gets absorbed into a longer timeline and nobody notices until it compounds. In agile, three days can block an entire sprint. I worked with a firm where the senior sponsor was. and I'm being generous here, "strategically unavailable" every other week. The delivery team spent more time working around his diary than they did building the product. The project ran six weeks over. He blamed the agency. But the agency couldn't deliver what it had committed to because the person who needed to approve the direction was permanently in a different meeting.
You need to be involved in prioritisation. The product backlog is prioritised by commercial value, not by what's easiest to build. And the person who understands commercial value is you - not the delivery team. A managing partner who delegates prioritisation entirely to the agency has handed over the single most important lever in the engagement. I get it - you're busy, you hired them to handle this stuff. But prioritisation isn't "this stuff." Prioritisation is the strategic decision about what gets built first and what gets parked. That's your call.
You need to review work regularly. The sprint review is not a presentation. It's not a status briefing. It's a working session where you look at real functionality, poke at it, provide specific feedback, and confirm whether the direction is right. The managing partner who turns up, nods politely for twenty minutes, and says "looks great, carry on" isn't fulfilling their role. They're creating the conditions for a nasty surprise four sprints later when the thing that's been built doesn't match what they had in their head - a thing they never articulated because they never engaged with the work-in-progress.
There's a companion piece on managing an agency relationship without becoming a micromanager that covers the wider dynamic. But in an agile context, the minimum commitment is clear: show up, decide, and engage with incomplete work before it becomes complete.
You don't need a project management qualification to spot the signs. You just need to know what to look for.
The clearest one: you can see new working features every two weeks. Not designs, not documentation - something you can actually click on. If the sprint review consists of someone talking you through what they've been working on without showing you anything, that sprint hasn't delivered. I've sat in those reviews. They have a particular energy - slightly too much explanation, slightly too little to show. You'll recognise it.
Decisions are being made at the right pace. The delivery team isn't accumulating a growing list of questions waiting for your input. If they are, either they're not escalating effectively or you're not responding quickly enough. Either way, it needs fixing before it compounds.
Your feedback from sprint reviews is showing up in the next sprint's work. This is the proof that the feedback loop is actually functioning. If you raised something two sprints ago and it hasn't appeared or been explicitly deprioritised with your agreement, the review process is decorative.
Scope conversations are happening openly. Changes are documented, costed, and approved - not absorbed silently or used retroactively to justify an expanding timeline. Honest scope management should feel like a running negotiation. Not a surprise at the end.
And the team's energy is consistent. This one's softer, but it matters. A delivery team in a well-run project is engaged, forward-looking, willing to show you things they're proud of. A team that seems reluctant to demo their work is usually managing a problem they haven't told you about yet. Trust your instincts on that one.
Most of these warning signs aren't catastrophic. They're fixable - usually with a direct conversation. The danger isn't that they happen. The danger is that nobody names them.
Sprints that produce no visible output. The sprint review that consists entirely of a status update about what's "in progress" is a sprint that hasn't delivered. One missed sprint can happen - dependencies shift, something takes longer than estimated. Two in a row is a pattern. Three is a project in trouble.
Feedback that disappears. You raised something in the review. It didn't show up in the next sprint. Nobody mentioned it. Either it was deprioritised and nobody told you (a communication failure), or the review isn't actually feeding into sprint planning (a process failure). Both are fixable, but you need to name it.
A backlog that grows faster than it shrinks. If more items are being added than are being completed each sprint, scope is expanding without the constraints needed to maintain delivery rhythm. Additions should be balanced by removals or conscious deferral. A backlog that only grows is a project that will never finish.
Your input being bypassed. The delivery team that makes decisions on matters affecting commercial outcomes without involving you is operating outside the agile client relationship. Sometimes this happens because they're trying to be helpful and keep things moving. Sometimes it happens because they've given up trying to get hold of you. Either way, it needs addressing.
The word "agile" being used to deflect planning questions. This is the big one. If you ask "what will be in the next sprint?" and the answer is vague, or if you ask "what's the risk to the timeline?" and you're told "we're agile, we'll adapt" - that's not agile. That's someone hiding behind terminology. A competent agile team can tell you what they're planning to deliver next, what the dependencies are, and what could go wrong. The ones who can't aren't being agile. They're being evasive.
Agile is not the right approach for every project. If the requirements are fixed, the solution is well-understood, and the client doesn't want or need to be involved in iterative decision-making, waterfall might genuinely be the better fit. I've seen agile forced onto projects where it added overhead and complexity for no benefit - usually because someone in the delivery organisation had decided that "everything is agile now" without thinking about whether the project actually needed it.
But for most digital projects - particularly ones where the brief involves any degree of discovery, where the requirements might evolve as you learn more, or where the end product needs to reflect real user behaviour rather than assumed user behaviour - agile is the right call. The caveat is always the same: it only works if you, as the client, show up for your part of it.
One thing I've learned from years of running these engagements: agile delivery without a client-side governance rhythm creates a vacuum. The sprints tick along, the reviews happen, but nobody is stepping back to ask whether the overall direction still makes sense.
It's one of the reasons we developed the WHNN® quarterly rhythm at Distinction. Every quarter, you step back, review what's working, reassess priorities, and make collective decisions about where to put time and money next. It's not a methodology layer on top of agile - it's the client-side discipline that stops tactical delivery drifting away from strategic intent. The two things work together. Without the quarterly rhythm, even a well-run agile programme can spend six months building the right thing in the wrong direction.
If you want a practical reference you can hand to your project sponsor before the first sprint kicks off, we've put together a client-side agile checklist - a one-page document covering the three client commitments, the five working indicators, and the five warning signs from this article. It's designed as an onboarding document for the start of any agile engagement. Worth downloading before your next project begins.
Agile isn't something that happens to you. It's something you participate in. The managing partner who shows up fortnightly, makes decisions when they're needed, and engages honestly with work-in-progress will find that agile delivers exactly what it promises. The one who approves the budget and disappears will find it felt like chaos.
And they'll blame the methodology. But the methodology wasn't the problem.