Architecture is one of my biggest beefs with Agile. Combination of lack of processes and documentation and faux egalitarianism is particularly deadly.

I have an experience in a relatively big corporation. Before Agile (around a decade back), it was more or less waterfall, we documented what we wanted to code as a feature, how it should work, did several rounds of review, and then we coded it to that spec.

Today, I am lucky if we have time to do the spec before coding. The most important thing is to have stories in our project management tool, which contain no real information about the specification. Customer validation is paramount but the technical soundness is mostly lacking.

I had many discussions with Agile proponents about this problem, with different suggestions, but it never changed our actual processes (or general lack of thereof).

If I had to make an analogy with house construction, it would go as this. In the old days, we did what is usually done, you have a picture of a house you want and from that, architect (or engineers) create actual blueprints, engineering documentation, which describes what is to be built. Then based on that you create estimates, timelines and manage the project. (And in real construction, they actually also create "as-built" documentation, for maintenance.)

Today, it's like no actual engineering documentation is created. So basically, product owner draws a picture of the future house, gives it to each of the workers (not to mention another problem of Agile, lack of specialization, there is no distinction between masons and welders and plumbers and electricians), and tell them, look this what you should build, go ahead and somehow do it.

What usually happens is they all start frantically working at something, and before you know it, you have ceiling on side of the house 10 cm below the other side. Or two sets of electrical wiring.

Now it's important to understand I am in no way dissing the workers (or coders), on the contrary. This happens despite (or maybe because) they are all very smart and productive and well-meaning. I certainly think that architect throwing design over the wall to be "coded" is an anti-pattern. People need to cooperate, but there needs to be process, reviews and documentation, otherwise it's gonna end up real messy. And the calls for "team responsibility" seem to be rather utopian to me.

Also, I am very much in favor of Agile as a project management method, especially Kanban (see also Steve Yegge's Good Agile, Bad Agile) - of course if you don't need deadlines.

But I don't believe, as Agile seems to claim, that you can build a two-story house (something that requires a foundation, which is famously not customer facing) by quickly iterating on a tent or a wooden shed. At some point, you need to demolish it all and build the damn foundation. The product management cannot excuse themselves, we don't know whether we end up building a bungalow or a skyscraper, just be flexible. The engineers need to know, in advance.

Which brings me to an interesting point. There is an old wisdom, that the problems you find earlier in the design cycle are easier (and less expensive) to fix. Agile claims, that it's easier (and less expensive) to write and refactor the wrong code, than to properly discuss and review architecture. I call BS on that. (The other point that Fred Brooks makes is there should be a responsible design leader, i.e. architect. This is not contradictory to egalitarianism - developers should be involved in the design of the features they will work on and they should all try to lead the design of a feature from time to time.)

To conclude, I think with Agile, SW engineering has gotten much more away from actual engineering than it used to be. I think this is fixable, but people need to accept that proper engineering documentation (AKA architectural specification) is required, and stories and acceptance criteria are no replacement for that.