For successful IT projects, a method choice is just one detail in a much greater picture.
There's a reason why your project's lead architect (the tech lead) looks like a nervous wreck. Projects are crazy hard. You must employ dozens of best practices and methods to succeed. Which combination from the hundreds do you use and how? Which ones are right for the resources on hand? Which work products do you keep and which ones do you throw out? And what's the right level of detail? Your lead must work through all of this, find the right mix, and adapt them to the unique characteristics of your project. This is where the magic happens.
It's incredibly difficult to strike the right balance. To navigate, you focus on the project's critical success factors / properties (I like Alistair Cockburn's description here). You fight like hell to make those the properties of your project. And you use any tool, method, or expert you can find to do so.
That's what lead architects do. They rarely engage in lengthy debates about this method or that. Not because it's not interesting or valuable, but because it's usually at a level of detail they don't have the luxury to fuss over.
Lesson Learned: IT projects need great technical leadership to succeed. The application of agile methods is just one element of this.
