Perspective

Agile in name is not agile in practice

Engineering delivery

Most technology teams have adopted the vocabulary of agile. Far fewer have adopted the operating model underneath it. You can tell the difference quickly. The standups happen, the sprint planning happens, the board has the right columns, and none of it is producing what agile is supposed to produce: faster delivery, sharper prioritization, and a tight loop between what gets built and what the business actually needs.

This is common enough that the agile community has a name for it. Scrum.org calls it agile in name only, where an organization cherry-picks the ceremonies and the terminology without the principles that make them work. The pattern they describe matches what I see: rituals performed on schedule, but decisions still made top-down, requirements still frozen early, and leadership still treating the whole thing as a process the engineers do rather than a way the company operates. When the rest of the business has not changed how it sets priorities and tolerates change, the team is left doing the motions of agile inside an organization that is not agile. The result is overhead without the payoff.

So when I look at a team that says it is agile, I do not check whether the ceremonies are happening. I check whether they connect to anything. Is prioritization actually changing based on the feedback loop, or is the backlog set in stone three quarters out? When something the business needs shifts, does the work shift with it, or does everyone wait for the next planning cycle? Real agile is visible in the results, not the calendar. If the rituals are there and the outcomes are not, the rituals are not the thing to fix.