See, this kind of vague, fuzzy feel-good description is exactly why it seems to me that the one thing everyone seems to agree on about Agile is that everyone else is doing it incorrectly.
A lot of things work well in theory. That doesn't really make them good ideas if they can almost-never be implemented properly.
That's a fantastic quote, thanks.
"0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something.
1st Order Ignorance: Lack of Knowledge. I have 1OI when I don't know something. With 1OI we have the question in a well-factored form.
2nd Order Ignorance: Lack of Awareness. I have 2OI when I don't know that I don't know something.
3rd Order Ignorance: Lack of Process. I have 3OI when I don't know a suitably efficient way to find out I don't know that I don't know something.
4th Order Ignorance: Meta-ignorance. I have 4OI when I don't know about the Five Orders of Ignorance. "
that couldn't stand doing group projects in school
But big-A Agile is a management school with its own dysfunctions. It diverges from small-a agile, which is basically a set of principles to help critique yourself with.
When you hire a manager (or "Scrum Master" whatever), they must convince top management to give them a job. Which is why Scrum Masters brag about their bosses "believing in" Agile, like a bishop happy that the king loves god. Then they impose some system which requires their highly visible involvement.
(That said, the Agile described in this article diverges from my personal experience.)
Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing with teammates to produce something bigger and better than I could on my own is totally foreign.
If you don't explicitly name your development methodology, you still have one: you're practicing something called ad-hoc development. Unless you and your entire team are superheroes, there's an awful lot of knowledge being leaked away.
Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake.
Don't confuse some company's crappy engineering practices for agile just because they call them that. Stand ups are short. Period. If it feels like a "permanent PIP" your team could use some improvement. If it feels like a surveillance state it's probably not a very good implementation of agile.
Agile development is about making connections to your team members: individuals and interactions over process and tools. It sounds like the author's experience (as well as many other devs') is unfortunately in an organization that doesn't pay heed to that very first, most important agile principle.