The most important factor is probably project size. As size grows,
face-to-face communication becomes more difficult. Therefore, most agile methods
are more suitable for projects with small teams, with fewer than 20 to 40
people. Large scale agile software development remains an active research area.
Another serious problem is that initial assumptions or overly rapid
requirements gathering up front may result in a large drift from an optimal
solution, especially if the client defining the target product has poorly formed
ideas of their needs. Similarly, given the nature of human behaviour, it's easy
for a single "dominant" developer to influence or even pull the design of the
target in a direction not necessarily appropriate for the project. Historically,
the developers can, and often do, impose solutions on a client then convince the
client of the appropriateness of the solution, only to find at the end that the
solution is actually unworkable. In theory, the rapidly iterative nature should
limit this, but it assumes that there's a negative feedback, or even appropriate
feedback. If not, the error could be magnified rapidly.
This can be alleviated by separating the requirements gathering into a
separate phase (a common element of Agile systems), thus insulating it from the
developer's influence, or by keeping the client in the loop during development
by having them continuously trying each release. The problem there is that in
the real world, most clients are unwilling to invest this much time. It also
makes QAing a product difficult since there are no clear test goals that don't
change from release to release.
In order to determine the suitability of agile methods individually, a more
sophisticated analysis is required. The DSDM approach, for example, provides a
so-called �suitability-filter� for this purpose.
The DSDM and Feature Driven Development (FDD) methods, are claimed to be
suitable for any agile software development project, regardless of situational
characteristics.
