Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).
Now, most people who say they do Waterfall are quite mistaken. They don't, they do some sort of iterative method as you say. But they report as if they have distinct, linear phases with distinct linear steps, as if Waterfall were the reality and not an imagining. Which is itself problematic. This means that upper managemnet comes to believe that Waterfall works because they see it working, not realizing that the reports themselves are misleading.
Everytime one of the project managers tells me they're doing Waterfall I press until they admit it's "Modified Waterfall", by which they mean the V-model or Spiral or other models with explicit feedback loops/mechanisms. And it frustrates me to no end that they keep using the wrong terms rather than the precise ones, because now upper management has begun enshrining Waterfall again after two decades of improvements. Now we have to fight the same battles, to impress upon them that iterative methods are what we actually do, and that a strict linear flow is impossible.
It feels like the Bruce Lee idea of "take what is useful and leave the rest" but either the opposite or a bastardized version. Like, take what is easy and leave the nuance
I see, whatever this idea/principle would be called, all over.
Then like evolution, it's survival of the fittest with the entrenched old idea having the heavyweight advantage.
BTW, this is a great point you make! I hope my comment doesn't seem to discount it as your thought made my mind go to the experiences I have seen that led to this comment.
> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.
> Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution
> The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position.
Why does Kanban help in some offices and do nothing or hurt in others?
Two reasons for success: Luck or understanding. Two reasons for failure: lack of understanding or lack of commitment.
What does Kanban assist with, what principles?
It assists in elaborating and clarifying the workflow or processes in the organization or unit. This can be done many ways, Kanban is just one. But without understanding the, often unwritten, processes you cannot effect meaningful change (at best you're stabbing in the dark).
It also emphasizes focus by setting limits on "work in progress" which improves overall flow/throughput. It turns out that this is, generally, a good idea.
The ones who succeed don't succeed because of Kanban. They succeed because of those two basic principles (and other related principles and concepts that I'm not elaborating on here). Kanban was a mechanism which led to success by drawing on these ideas.
The ones who fail don't fail because of Kanban. They fail because they don't control WIP, or failed to describe their process accurately, so it provided no, or perhaps even negative, value. Why don't they control WIP? Maybe they aren't aware of that element of Kanban, or they don't believe that it can bring value and ignore it. They're too busy fighting fires so they don't have time to focus. Why don't they have an accurate process description? Often, because the process is dictated rather than discovered (You are doing X, even though you actually do A, B, and C).
That's just one practice and two principles that it is related to (there are others). This is the problem with Big-M Methodologies like Big-S Scrum and Big-W Waterfall and Big-A Agile, the easy part is the visible practices. So they're imitated. The hard part is the invisible principles and hidden practices (all the work that went into identifying the workflow, for instance). Repeat this across all the practices in these methodologies and you'll end up with a mess that succeeds by luck, or at least doesn't harm you so badly that you fail, but certainly doesn't offer significant assistance.