Your Sprint Ceremonies Are Not Making You Agile

Agile is a property of decision-making speed, not of calendar invites.

The hook

I sat in a retrospective last month. Their forty-eighth consecutive sprint retro, held every two weeks for nearly two years. The top item under "What didn't go well" was the same item from six retros ago: "Cross-team dependencies block us mid-sprint." The action item was the same too. I looked around the room. Nobody flinched.

सकळ चिंतामणी शरीर · The Whole Body Is a Wish-Fulfilling Gem

सकळ चिंतामणी शरीर । जरी जाय अहंकार आशा समूळ ॥
मन शुद्ध तया काय करिसी माळा ॥
तुका म्हणे तो परिसाहून आगळा ॥
If the mind is already pure, the prayer beads are pointless. The substance makes the ritual unnecessary; the ritual cannot create the substance.

What I keep seeing

After that retro I pulled up their Jira workflow. A feature one engineer could build in three days required sign-off from the product manager, the tech lead, the engineering manager, and a "stakeholder review" with a director who attended one meeting per week. On Thursdays. The median cycle time from "ready for development" to "merged to main" was fourteen days. Seven of those days were waiting for approvals.

They had every ceremony. Sprint planning on Mondays, daily standups at 9:15, backlog refinement on Wednesdays, demo on the last Friday, retro right after. They had a certified Scrum Master. They could not ship a button color change without four signatures. I have been in some version of this room at least a dozen times now, and the script never changes: impeccable process, glacial output.

The mechanics

The Agile Manifesto's first principle says: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." The operating word is "delivery." Not "planning for delivery." Delivery.

Cycle time, the duration from work starting to reaching a user, is the metric that actually measures agility. The DORA research program (now part of Google Cloud) has tracked this across thousands of teams since 2014. Elite teams have cycle times measured in hours or single-digit days. Low performers measure in weeks. The finding that matters: ceremony compliance does not correlate with cycle time. What correlates is deployment frequency, trunk-based development, small batch sizes, and low change-approval overhead.

An approval chain is a queue. When a feature needs four human approvals and each approver checks their queue once a day, the expected wait time is four days, even if each approval takes five minutes. This is not a people problem. It is a systems problem. No number of well-run standups will fix a queue with four serial dependencies.

Where Tuka comes in

Tukaram's claim is one of the most structurally precise in the Abhanga tradition. "मन शुद्ध तया काय करिसी माळा" (if the mind is pure, what will you do with prayer beads?) is not anti-ritual as a general stance. It is a specific claim about causal direction. The beads do not produce the pure mind. The pure mind makes the beads redundant. You cannot reverse the arrow.

This is exactly the error in ceremony-first Agile adoption. Teams install the rituals hoping the rituals will produce the capability: fast, autonomous decision-making. But the rituals are the beads. The pure mind is the organizational structure that lets a developer merge a change without waiting four days for approval. If you have the structure, the ceremonies become lightweight coordination. If you do not, they become theater. A team performing agility while their cycle time says otherwise.

What I would actually do

Measure your cycle time for the last thirty pull requests. If the median is above five business days, your problem is not sprint structure. It is approval latency. Cut the approval chain: any change under two hundred lines with passing CI should be mergeable by the author plus one peer reviewer, no manager sign-off. Move to trunk-based development with feature flags (LaunchDarkly, Unleash), so shipping and releasing are decoupled. Then audit your ceremonies. Keep the ones that surface real blockers. Kill the ones that exist because a framework told you to have them. A retrospective where the same item appears for six consecutive sprints is not a feedback loop. It is a rosary. Tukaram would put down the beads.

Chetan Dhandal