There are many academic/industrial researchs about various development methods (Scrum, XP, waterfall, ect.), telling us how to do it right and stuff. But I never saw something that suggest how to choose a method, what will be better for a given project.I know that what the developers are used to is an very important aspect. But lets say that I am assembling a new group from scratch, and that every programmer in the world is willing to work with me. :)What aspects of the project should I consider to decide between Scrum, XP, TDD, ect.? Or is that an entirely human thing, regardless of what is being developed?I said that all programmers are available, but you may comment they're knowledge about the domain, or other characteristics in the answers. E.g. If you chose to hire people with no domain knowledge, MethodX is better than MathodY, beacause .... is a completely welcomed answer.
How to choose a development method?
development process
There is something like a continuum between agile methods and the old, rigid, strongly formal waterfall approach. The more you walk away from agile developement, the more you add structure and design to your development process. This means that moving closer to a waterfall model, you will need more knowledgable designers, more knowledgable programmers and more knwoledgable project managers. More important, the closer you move to a waterfall model, the more you need knowledgable customers.Customers are probably the deciding factor. If you have a customer that does not actually know what he/she really need or want, you are practically forced to adopt a development model that is able to accomodate for a large amount of change. This is usually the case for web development, for example. If you have a strongly technical, mature, knowledgable customer, as is usually the case in the embedded development field, you are usually requested to adopt a strongly formal method (something like a waterfall).Programmers are another major selection point. You cannot actually adopt a strongly formal method with a group of college part-time workers. The more you need a formal approach (waterfall as an extreme example), the more you will need seasoned programmers with a large and strong set of skills.The type of system being developed is less relevant. There are web application so complex they need a development model very similar to the one used by NASA to go on the Moon (Amazon.com, for example) and embedded systems so simple that a single college programmer can develop it in a few weeks alone with any dev method at all (like many Arduino-based toy projects).Despite this, usually the systems that imply some kind of hardware dependency (embedded systems of any type) require a strongly formal approach because any error will be paied in $ or  by the developing company.This is another continuum: the more you walk away form hardware, the less you need a formal approach. The more you move away from money-related stuff (bank systems, e-commerce systems, POS, etc.), the more you can have an agile, iteractive approach. The limit is probably represented by the typical web-based brochureware where you do not actually need any formal approach to development (as long as you have mature and conscientious people).