Doing Agile Is Not the Same as Understanding It
There is a question we have started asking at the beginning of certain training days, not as a trick, just as a genuine check: can you tell me what your last retrospective actually changed? Not what was discussed. Not what the action items were. What changed.
The silence is usually instructive.
Most people in the room can describe how a retrospective works. Several will have been running them for years. The format is not the issue; it is what you are supposed to do with the output that gets murkier. And that gap, between knowing how and understanding why, turns out to be rather widespread, rather consequential, and rather rarely admitted.
The cargo cult problem
There is a phrase for this that circulates in agile circles: cargo cult agile. It refers to a pattern observed in the Pacific during and after the Second World War, where local populations, having seen military supply operations during the conflict, built replica airstrips, wooden control towers, and bamboo aeroplanes in the hope of attracting the delivery flights back. The forms were reproduced faithfully. The understanding of what actually summoned the aeroplanes was entirely absent.
It is, somewhat uncomfortably, an accurate description of a lot of what passes for agile transformation in corporate technology organisations. The boards appear. The ceremonies get scheduled. Jira gets installed, or whatever the current equivalent is. Someone in leadership announces that the organisation has adopted agile. Then, roughly eighteen months later, a post-implementation review asks why delivery velocity has not improved, and agile takes the blame.
This is annoying, not primarily because it is unfair to agile, but because it forecloses the actual inquiry. If the conclusion is that agile does not work here, nobody needs to look harder at whether agile was ever genuinely applied. In our experience, when agile transformations fail, the principles are almost never the problem.
The social cost of admitting you don't know
Part of what sustains this is something organisations are rarely willing to name: the social cost of admitting uncertainty. In many technology teams there is an unspoken expectation that competent professionals should always have the answer, or at least be able to produce a convincing impression of one. Admitting that you are not entirely sure why you run a sprint review, or what you are supposed to do with the output of a retrospective, can feel professionally risky in a way that simply going through the motions does not.
A participant told one of our trainers a while back, quite matter-of-factly, that the retrospectives at his organisation had been producing the same three action items for the better part of a year. Nobody had raised it. It was not that the team lacked the intelligence to notice, they had all noticed almost immediately. It was that naming it carried a cost nobody was quite willing to pay. So the retrospectives continued, and the action items accumulated, unacted upon, and everyone nodded along.
That is not a failure of process. It is a failure of psychological safety, which is considerably harder to fix with a new tool or a tighter ceremony cadence.
Where the argument gets complicated
It is worth being honest about where this breaks down as a critique, because it does break down in places. There are individuals for whom informal, self-directed learning works extremely well. The developer who has a specific production problem, goes away and reads everything available on the subject, and comes back knowing more about it than anyone in the organisation, is a real type, not an invention. Self-directed learning can produce genuine depth.
The limitation is not that it cannot produce expertise. It is that it almost never produces shared expertise, and in a team that needs to work from common principles, shared understanding matters rather more than individual depth. You can have the most knowledgeable Scrum Master in the building, but if the product owner has a fundamentally different mental model of what a sprint review is for, the ceremony will drift regardless. We have seen this play out in teams where the individual competence was genuinely impressive and the collective coherence was almost nonexistent. They were all doing agile. They were not doing the same agile.
What genuine understanding actually looks like
Teams that have moved beyond surface compliance share a characteristic that is harder to describe than it sounds. It is not that they run better ceremonies. It is that the ceremonies become, in a sense, less necessary. A team that genuinely understands why retrospectives exist will often have the retrospective conversation informally over the course of a sprint, so that the formal event is confirming and capturing something rather than discovering it from scratch. The standup is short not because everyone has learned to keep updates brief, but because there is genuine shared clarity about what it is for.
In our experience, the surest sign that something has been understood rather than merely adopted is that the practice starts reshaping the work, rather than sitting alongside it. The people who get this right are usually the ones who, at some point, felt genuinely comfortable asking "but why do we do it this way?" and got a real answer.
The question worth asking
If you manage or commission agile teams, the retrospective test is a reasonable starting point: ask what has concretely changed in the last two or three sprints as a direct result of a retrospective. Not the spirit of it. What specifically changed. If the answer is not immediately obvious, or if it requires a conversation to establish whether anything changed at all, that is probably where to start.
Not with a new tool, not with a revised process. With a genuine conversation about whether the team understands what it is trying to do and why. Those conversations are sometimes uncomfortable. They are also, almost without exception, where improvement actually begins.