It is very waterfall-y as someone I know said in a talk and therefore you probably need to be a little careful what "rules" you take away from it. That said, the "mythical man month" discussion itself as well as the idea of a 9x difference in effort between a program and a programming system product are worth the price of admission.

The latter arguably runs somewhat counter to a lot of MVP, etc. approaches but recognizing the difference is still useful.

I've heard an observation that Agile as practiced in the real world is often basically "tiny waterfalls."

Agile™, as I've encountered it, is collectivized micromanagement.

Ahhh...

You just put into words what’s been bothering me about the way my team works. The “process” people—while well-intentioned—seem to think that by breaking inherently complex tasks up in just the right way, they can make the complexity go away.

Well, no. If that’s really the idea, why are you paying me so much?

Exactly and it's almost perfectly orthogonal to engineering.

There's probably some truth to that. That's what a sprint basically is, right?

If you run your sprints right then no, nothing's set in stone. If something comes up in the middle of the sprint that takes priority, you address it. You don't mindlessly stick to the schedule set (that would be a "tiny waterfall.")

Fair enough. Although waterfalls usually weren't really set in stone either in my experience. Which had both good and bad points. (It's good to be adaptable but changing requirements all the time is also a good way to make a project late.)

This sounds is/ought-y? What is the prevalence of running sprints right in the real world? "As practiced" was the important part of my question/observation.

I feel that if there is a millennia old book or tablet from early days of mankind regarding management, many advices would still apply.