Ask most product teams if they're agile and they'll point to the standup, the sprint board, and the points on each ticket. Ask them the last time a sprint's scope genuinely changed because of something learned mid-sprint, and the room goes quiet. That's the tell. The ceremony survived; the actual agility (the willingness to change course based on new information) got quietly optimized away because it made velocity charts look messy.
What I found designing PakWheels' process across three markets
When we took the process from Pakistan into the UAE and Saudi Arabia, the instinct was to copy the ritual exactly (same ceremonies, same cadence, same board structure) because it was "working" at home. It wasn't working, it was just familiar. What we actually needed was the same principles applied to different constraints: discovery that accounted for a three-market backlog instead of one, specs that didn't assume the same buyer behavior, and a release cadence that matched three different regulatory and payment realities instead of one calendar.
Copying the ceremony across markets gives you the same meetings everywhere. Copying the principles gives you the same judgment applied to different facts, which is the entire point of being agile in the first place.
Where the ceremony quietly ate the principle
- Standups became status reports to whoever was most senior in the room, not a 10-minute sync for the team to re-route itself.
- Sprint commitments became promises defended against new information instead of hypotheses updated by it.
- Retrospectives became venting with no mechanism to actually change the next sprint's structure.
- Story points became a performance metric for individuals, which is the single fastest way to make a team stop reporting real blockers.
None of those are agile's fault. They're what happens when a team adopts the artifacts without re-deriving, for their own context, why each one exists.
What I rebuilt it around instead
Three rules survived the redesign, and they're not from any specific methodology book:
- Clear rules for discovery, prioritization, and specs, written down, so "agile" didn't mean "whatever the loudest person in planning wants this week."
- Smooth handoffs from design to QA to release (the actual mechanical plumbing that determines whether a two-week box is realistic or theatre).
- Goals, reviews, and rituals that stick after I leave. If the process only works while I'm personally enforcing it, I didn't design a process. I designed a dependency on me.
The question I now ask any team that says it's agile
"What did you change mid-sprint, recently, because you learned something?" If the honest answer is "nothing, we finish what we commit to," the team isn't being disciplined. It's running a waterfall project in two-week increments with better vocabulary. Agile was always supposed to be the opposite of that plan-and-defend posture. The standup, the board, and the points were just the easiest parts of it to copy.