Writing the wrong code, not writing what the employer client wants, we don't need daily meetings and layers of process to fix that.
We need design documents. Requirements and functional specifications at minimum, the latter used to QA to test and verify. At many companies I wrote the first design specs they had ever seen; at my most recent gig they regarded their bug list, some awful thing called ClickUp, as their design. Tone of time lost.
Since I double as a technical writer I usually took that responsibility, as well as writing user docs that were very highly praised. And while writing I thought of a lot of considerations that everyone else, me included, had overlooked. I've got an outline; I need a few paragraphs here ... hey! Nobody thought about ______.
But again I stick with fad. So many of the people who argue for agile are kids. They’ve never known anything else. They think pair programming and TDD are how you write software. If you take away the indisputable junk like the extra meetings, what is different from how we worked before?
But it’s in TDD where they really go over a cliff. They’re as fanatic as gun nuts.
However I’m not dismissing what you’re saying. This is what makes me laugh about outsourcing; even with a group from the same culture, speaking the same language, communicating regularly and with *ahem* the same work ethic, half the time the company doesn’t get what it wanted.