I've spent the last couple of weeks preparing for the workshop William Pietri and I are going to be teaching in August. I'm really impressed with how you can take all of the references to writing code out of, for example, Agile Software Development Ecosystems and it still makes sense as a philosophy for how groups of people can collaboratively solve problems and make things. It may be the first fundamental rethinking of how things are made since Taylorism. That's not to imply that XP and the other agile methodologies are equivalent to Taylorism, but I think that they, as a philosophy of how to get groups of people to make stuff, are as profound a concept.
I'll write more about this as I finish reading and thinking about it, but I'm quite taken with the ideas at the moment.
Design patterns (whether literally Alexander's or from other fields, such as programming patterns) are an interesting explanatory mechanism for why some things work, and make for a good first-order approximation when there are no other constraints, but I don't think they're a very good predictive mechanism. In other words, I think that if you follow them slavishly and to the letter, the end result will merely avoid being bad in ways that we understand things can be bad, but that doesn't mean it'll be good and it doesn't avoid new ways of being bad.
If that makes any sense. ;-)
I'm not sure of the relationship to agile methods that you're trying to evoke. For me, as I said above, patterns are a place to start iterating and adjusting (refactoring in XP terminology).
this is christopher alexander's rules of design - replace the word 'building' for website:
http://thesea.uklinux.net/projects/seateam/seainside1/rules%20of%20design.pdf