Every enterprise client we've worked with in the past two years has told us they're "doing agile." Some of them genuinely are. Most have adopted the vocabulary (sprints, standups, backlogs, retrospectives) without adopting the principle underneath it all. And the principle is beautifully simple: build a small thing, put it in front of real people, learn from what happens, and adjust. That's it. Everything else is ceremony.
What You Need to Know
- Agile in enterprise has largely become a process layer on top of waterfall thinking - sprints without iteration
- The core of agile is short feedback loops with real users, not standups and sprint planning
- Enterprise constraints (procurement, compliance, change control) create legitimate friction with agile delivery
- The teams that succeed adapt agile to enterprise reality rather than pretending the constraints don't exist
The Ceremony Problem
Here's what "agile" looks like at many of the enterprise organisations we work with.
Monday: sprint planning. The team estimates stories. The product owner prioritises the backlog. Stories are assigned. Everyone feels organised.
Daily: standups. Each person says what they did yesterday, what they'll do today, and what's blocking them. The meeting takes fifteen minutes. Sometimes twenty-five.
End of sprint: sprint review. The team demonstrates what they built. Stakeholders nod. The product owner says "looks good." The sprint closes.
End of sprint: retrospective. The team discusses what went well and what didn't. Action items are written on sticky notes. Most are forgotten by the following Monday.
This is process. It looks like agile. It isn't agile. It's waterfall with fortnightly milestones.
What's Missing
The gap between ceremony and agile is feedback. Real feedback from real users, applied to real decisions about what to build next.
In most enterprise "agile" teams we encounter, the feedback loop is broken in one of three ways.
Users are absent. The sprint review is attended by stakeholders, project managers, and occasionally a product owner. The people who will actually use the software daily are not in the room. The team is building what the stakeholders want, not what the users need. The gap between those two things is where enterprise projects fail.
Nothing ships between sprints. The team builds features in sprints, but nothing goes to production until the end of the project. There's a "sprint 1" and a "sprint 8" but no user has touched the software until the final release. The sprints are just time boxes for internal work. They're not delivering anything that generates real-world feedback.
Feedback doesn't change the plan. Even when feedback arrives, the plan doesn't change. The scope was fixed at the start of the project. The contract specifies deliverables. The backlog was written in January and it's June and nobody has added, removed, or reordered a story based on what they've learned. The team is "agile" in form but waterfall in substance.
If your backlog looks the same on day ninety as it did on day one, you're not doing agile. You're doing waterfall with standups. Real agile means the plan evolves because you're learning from the people you're building for.
Tim Hatherley-Greene
Chief Operating Officer
Why Enterprise Makes This Hard
It's easy to criticise enterprise agile. It's harder to acknowledge that enterprise constraints are real and they genuinely conflict with agile principles.
Procurement needs fixed scope. Government and large private sector clients procure software against a requirements document. The contract specifies what will be delivered, when, and for how much. That's a fixed-scope agreement, which is fundamentally at odds with agile's principle of adapting scope based on what you learn.
Change control slows everything. In regulated industries, deploying to production isn't a developer pressing a button. It's a change request, a review board, an approval process, and a deployment window. Weekly releases aren't just hard. They may be impossible under current governance.
Stakeholder availability is limited. The people who make decisions in enterprise organisations are busy. Getting thirty minutes of the CFO's time for a sprint review is a victory. Getting a room full of actual users for a fortnightly demo is usually unrealistic.
These aren't excuses. They're constraints. And the teams that do agile well in enterprise are the ones that work with these constraints rather than pretending they don't exist.
What Actually Works
We've been refining our approach to agile in enterprise over the past two years. What works isn't textbook agile. It's adapted agile that respects enterprise reality.
Ship to a staging environment early and often. If production deployments are constrained by change control, deploy to a staging or UAT environment that real users can access. Get feedback flowing even if you can't release to production every sprint. The goal is user feedback, not production deployment.
Involve three to five users, not the whole organisation. You don't need a room full of users. You need three to five people who use the current process daily, who are willing to test early versions, and who will tell you honestly when something doesn't work. Find them. Protect their time. Listen to what they say.
Renegotiate scope, not budget. Enterprise procurement needs a fixed price. That's fair. What's negotiable is what that price buys. We propose a fixed budget with a prioritised backlog and an agreement that the specific features may change as we learn. The client gets the same investment and the same number of development hours. What changes is which features are built, based on what we learn during delivery.
Keep ceremonies minimal. Sprint planning and retrospectives are valuable. Daily standups are valuable when the team is small enough that everyone's update matters. Everything else is optional. We've stripped our process to the ceremonies that generate decisions and eliminated the ones that generate meetings.
Demo working software, not designs. Every two weeks, we show something that works. Not a wireframe. Not a design concept. A functioning piece of software that someone can click through. It doesn't have to be polished. It has to be real. The quality of feedback you get from working software is categorically different from the feedback you get from a slide deck.
The Test
Here's a simple test for whether your enterprise team is actually doing agile.
Look at your backlog today. Compare it to your backlog three months ago. If it's the same list in the same order, you're not iterating. You're executing a fixed plan.
Look at your last five sprint reviews. Were real users present? Did their feedback change what you built next? If not, your feedback loop is broken.
Look at your last production release. How old was the oldest feature in it? If it was built four months ago and the user is seeing it for the first time, your cycle time is too long.
Agile isn't a process framework. It's a commitment to learning and adapting. The ceremonies are scaffolding. If the scaffolding is standing but the learning isn't happening, the ceremonies are just overhead.
Enterprise makes agile harder. It doesn't make it impossible. The teams that figure out how to get real feedback from real people within real enterprise constraints are the ones delivering software that actually works. Everyone else is doing waterfall with better vocabulary. Stop planning and start building. Just make sure you're building with your users, not just for them.