“We Are Agile” Is Not a Scope Statement
There’s a scenario I keep running into on enterprise Salesforce programmes, and I want to write about it because plenty of you are probably sitting in the same room I am.
The shape of it goes like this. The programme has a fixed go-live date, set by the business for reasons that aren’t going to move. It has a fixed budget, signed off and visible all the way up to the executive committee. Ask the obvious follow-up question, what’s the scope?, and the answer is some flavour of “we’ll work it out as we go, we are agile.”
I’ve heard this defence from PMOs, delivery leads, product owners, and SI partners. Sometimes it’s earnestly meant. More often it’s a way to postpone an uncomfortable conversation. Either way, it doesn’t hold up, and on a Salesforce programme it holds up particularly badly.
The iron triangle didn’t go away
Time, cost, scope: pick two. That isn’t a waterfall idea, it’s a constraint of physics, and adopting Scrum doesn’t repeal it. If your time is fixed and your cost is fixed, the third corner has to flex. What changes between programmes is how the flexing happens.
There are really two flavours. In the first, scope flexes against a defined target. You know what you’re trying to build, you’ve sized it honestly, and you’ve agreed up front that lower-priority items get cut if you can’t fit them all in. Trade-offs happen explicitly, with visibility, against criteria the business has already signed up to.
In the second, scope is undefined, whatever lands at go-live is what the business gets, and there’s no target, no priority list, no descope mechanism, and no honest conversation with stakeholders about what they’re losing.
Only the first is agile in any meaningful sense. The second is delivery without a destination, with the vocabulary of agile pulled over the top to make it look intentional.
When a delivery lead invokes agile in this kind of context, I want to believe they mean something specific: that there’s a defined minimum viable scope, a prioritised stack of work behind it, a working mechanism for trading items in and out as the team learns, and a business sponsor who has accepted that the team will cut from the bottom if velocity demands it.
That position is defensible. In practice it’s rare.
More often, “we are agile” is doing one of three jobs. It’s letting the team avoid the work of defining scope, which is genuinely hard and genuinely political. It’s letting the team duck a delivery commitment, which is what would follow if scope was actually defined. Or it’s a quiet bet that the business won’t notice until the consequences land somewhere other than the team. None of that is about agile delivery. It’s about avoidance.
What you actually need on a fixed-time, fixed-budget Salesforce build
Salesforce programmes are particularly unforgiving here, because so many of the structural decisions are expensive to reverse. Sharing model, identity strategy, single-org versus multi-org, integration patterns, the data architecture: these aren’t sprint outputs. You commit to them early and you live with them.
To deliver against a fixed date and budget without abandoning agile in spirit, a few things have to be in place from the start.
Start with a defined minimum viable scope. Not a backlog, not a roadmap, but a concrete written answer to the question of what the absolute floor looks like at go-live. Without one, you can’t size capacity, sequence integrations, plan the data migration, or scope your environments. You can write user stories all day and none of it gets you closer to delivering the right thing.
Behind the floor, a prioritised stack: everything that’s nice-to-have, ranked, with the business owning the ranking. When something has to give, it’s obvious what gives.
On top of that, a working descope mechanism. A regular forum where scope decisions actually get made, an audit trail of what’s been deferred, and stakeholders who understand that deferral is a likely outcome they’ll need to plan around.
Then a target architecture: the non-negotiable spine of the build, settled up front, because the alternative is rebuilding it later at much greater cost.
And underneath all of it, a capacity model honest enough to test the date. If the floor scope doesn’t fit the time and budget available, that’s a finding the steering committee needs now, not at the end of sprint twelve.
You can have all five and still deliver in a genuinely agile way inside the constraints they set. What you can’t do is skip them and call the result agile because the team runs stand-ups and uses a Jira board.
Where the risk actually lives
The piece that gets glossed over in this debate, in my experience, is what the “we are agile” posture is actually doing to risk.
When time and budget are fixed and scope is undefined, “we are agile” quietly transfers delivery risk from the team to the business. The team gets to operate without committing to anything specific. The business turns up at go-live and finds out what it bought.
That isn’t a partnership. It’s a sleight of hand performed with ceremony.
The whole point of agile delivery, on the better days I’ve seen it work, is that trade-offs become more visible than they were under traditional waterfall, not less. If your stakeholders can’t tell you what they’re getting for their money and their date, the programme isn’t running agile. It’s running a delivery model where someone has decided scope definition is too inconvenient, and the consequences are someone else’s problem.
What I’d push for
If I were running this debate from the business side, the move I’d argue for is fairly straightforward. Get a defined floor scope on paper, signed off by the business sponsor, inside weeks rather than quarters. Build the prioritised stack behind it. Stand up a real, functioning descope forum. Make the trade-offs visible to everyone who’ll have to live with them.
That’s harder than saying “we are agile.” It means getting the delivery lead, the product owner, and the business sponsor into a room together for an honest conversation about what’s actually being committed to. Somebody has to name, out loud, which items get cut first if velocity slips. The steering committee has to accept that “deferred to a future release” is a real outcome they should plan around, and think through what that means for the business case behind the programme.
It’s planning, basically. And it’s exactly the kind of planning “we are agile” has become a way to dodge.
Agile is a delivery philosophy. It isn’t a scope statement, and it isn’t a substitute for one. Fixed time and fixed budget don’t get easier when you adopt Scrum, they get harder, because two of the normal levers have already been removed, and the only way to operate inside what’s left is with more scope discipline, not less.
If your delivery lead is answering the question “what are we actually building?” with “we are agile,” the conversation you actually need isn’t about methodology, it’s about accountability. Have it now, while there’s still enough time and budget left to act on whatever comes out of it.