The architecture and building construction analogy is useful at an IT architecture level. At an implementation level it is may be more questionable. However, consider an house architect and foreman working hand in hand; the construction crews are scheduled iteratively in a sense if you consider framing, wiring, plumbing, dry-walling, finish carpentry, tiling, painting, etc. all as different development requirements that build on prior results. In the end successful IT projects still need good architecture whether they work with Agile or waterfall implementation methodologies. The alternative is that requirements are gathered without guidance, from whomever the development team wants to talk to (maybe multiple times on each dev cycle) and the result may be a directionless mashup of 100 or 10,000 conflicting requirements with no real end point ever recognized, least of all met.
When introducing architecture to development teams who fear they may be overly constrained I sometimes relate a story from a summer job in construction in high school. I was working on high end house construction with a local crew and we arrived at a new site ready to begin. The very experienced foreman surveyed the site and examined the plans from the architect and made a call to the owner. He explained that if we built the house as designed any significant rainfall would flow into the garage and flood the basement. We ended up building the house flipped on the site, holding the plans upside down to figure out what went where. Some mistakes were made as a result, but waiting on a new architecture iteration would have been more costly than fixing those mistakes as we went... We couldn't have built the house without the plans, but practical implementation was not pre-ordained by those plans.
A lot of what is being discussed in this thread, is in my experience, preventable with good IT architecture. The analogy to construction holds at three levels: city planning, neighborhood plans, and individual buildings. The business equivalent being enterprise architecture, systems architecture and application architecture. Real enterprise architecture is rare in my experience but the best way to tackle disparate organizations with conflicting goals. At the Enterprise level I prefer the Zachman Framework: fill out who, what, when, where, why and how at the business goals, conceptual and logical design levels and you know you have plans for all aspects of the all the systems, people, geographic areas, etc. Drill down into physical design and implementation plans as needed. Doing that _is_ costly and time consuming. Not doing it is what leads to the problems discussed in this thread. If you know what you are doing you can skip filling in the entire grid, but that should be a decision that has buy-in from all the parties involved. Note that at this level Enterprise architecture is more than just IT, it looks at what people are involved in all parts of the business, in what geographic areas, when they need to be involved etc. and lays out the products they should deliver and the rational for doing so. IT may not even be involved in some cases (but those are not the projects that interest me!)
There are also Agile equivalents for Enterprise architectures. In particular, I like the "Scaled Agile Framework", which uses things like Scrum and Kanban type push / pull methodologies at the architecture level and details how to couple them to the implementation process in a traceable and iterative fashion. I'm not yet sure it works when you are trying to couple things like Amazon like planning horizons (5 to 10 years) to next weeks dev push, but I am starting to examine how to bridge that gap...
