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).