The roots of the Agile methodology come from rapid prototyping. It started under the RAD (rapid application development) style, an early development model for very quickly prototyping a concept, so you could show users something and get their feedback. You take their feedback and iterate. This is still the core of agile, rapid iterative experimentation/evolution.
The other problem is, agile is not really defined. It's elusive, hard to explain, and thus hard to do. In fact, agile is intentionally 'agile' (elusive). If management can't understand the methodology, staff can't be held to it. Or staff can simply say "management never really understood it, and never really implemented it". It's a cop-out, yes. But the problem is, it's designed this way intentionally.
The article says it best "...there are 10 guiding principles. First is that agile is not just one thing alone."
This says agile is basically undefined, a mishmash. Not a good position to start from. If the adherents can't decide or agree on what it is, how can the rest of us?
Next the article says "you can't just pick and mix certain aspects of agile, but must use them all in a continuous stream to gain success."
Really? How so? If you can't define agile's parts, how do we use them "all"?
The article mentions "technical debt". This concept creates the "rapid" push in agile work. But it's also its achile's heel. Technical debt is how far you are from your goal. When technical debt is largest (i.e., at the start of a project), the greatest is the pressure to do something. To take risks... to try something experimental, to skip prudence, to cut corners, to ignore quality, to just so something. Anything.
This is the serious problem with agile. It eschews quality-based controlled development over rapid delivery/development. It pushes developers to deliver something quickly, rather than to deliver quality.
I work in the medical device field, where software has a critical role. Sometimes life-critical. Software must be failsafe, faultless, and validated to ensure with high statistical certainty a patient (or clinician's) health will not be compromised. EVER! And agile is NOT good in my industry. The medical device industry relies on quality as a cornerstone, but agile is in conflict with quality.
Agile is good for some industries, mainly consumer industries where coding errors, mis-designed software, inefficienct code, etc. are tolerated or even desired in order to reduce the net cost to the consumer. Examples are Game development, consumer apps (those that don't process financial, health, or critical data), and in instances where users accept buggy software (freeware/shareware).
In my experience, agile teams succeed only when they include very good developers who previously learned quality when they were earlier on non-agile project teams.
Agile is flawed because it doesn't embrace that software, especially complex software, requires ways to tackle and increase quality.
Agile also requires star developers who've learned quality skills from prior non-agile experiences. Developers who've never worked outside of agile don't embrace quality (they might say they do). Because agile doesn't embrace quality.
Agile is good when software quality isn't important.