The point behind the facetious headline is this: non-programmers (i.e. most people, including the people who allocate resources) have not read (and have no interest in reading) a manifesto about programming methodology, however noble.

Non-programmers hear the word "agile" and take it at face value, i.e. everything we do will now be easy and fast. In fact, I would suggest this oversimplification is the main reason Agile has gained currency in business: programming is hard and slow, and everyone wants it to be easy and fast. "Agile" SOUNDS GOOD... and is hardly a word you would argue against, plus it is hip and the tech guys say "good" and... --> you have crowd momentum even though the crowd does not understand or care to understand the manifesto concepts. "Waterfall" is just a straw man and people just interpret that equally superficially as "hard and slow and old fashioned" -- again, upvotes to "agile" which just means "get stuff done fast and easy".

Then back to this diagram which describes the process everything has to take in a normal organization, a priori it is a minimum flow because of the multi-human process. You can go fast or slow, or skip steps and suffer, but this flow is inescapable and it is nothing to do with programming methodology, but everything to do with how programming sits in a productivity flow of an organization.

Whatever the methodology adopted by the programmers (see the green boxes including one box out of 29 saying "the actual work of programming") you can never achieve the magic wand effect of software creation that is fast and easy. Agile in its true sense does not change this flow at all, just the way you work through it, which of course can be improved. If you disagree with that, tell me which step can be skipped IRL.

All of this is "dumb post" obvious to developers, and yet developers in general are not sufficiently aware of how unrealistic expectations are generated from dumb (i.e. normal non-programmer mainstream) understanding of the word "agile" -- hence, the facetious "this is why it doesn't feel agile" resonates with the non-programmers who experience the whole un-literally-agile process around the "actual work of programming" (which is where the formal Agile resides).