It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly label

It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning. I've seen it go wrong in both ways. One project did BDUF and then planned it out as a 2 year series of sprints, delivering increments. The scrum master's job was to keep an eye on this macro-schedule and make small course corrections along the way to keep things on track. There were weekly demo's, but since there was no slack in the schedule there was no way to act on the feedback unless the next sprint involved building out the same set of screens. That project went ridiculously over budget, and ended up so unsuitable for the customer's needs that they didn't adopt it. Another project avoided doing any design up front, because "that's not agile". In the course of the project it became apparent that several key architectural decisions were wrong due to requirements which were known at the start and which would have been apparent had an up-front design been made. These proved very costly to rework. My conclusion is: (1) if there are requirements set in stone up front, do the design work necessary to fit those requirements at the start, and (2) don't translate that design to a schedule, but instead to a prioritized backlog, then go one sprint at a time without planning too far ahead. Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working. (It doesn't fit into any way of working, which is why so many projects go over budget, but that's a whole different can of worms.)