Меня, как человека сферы IT, давно интересовал вопрос что такое гибкие методики разработки и когда их выгодно применять и зачем оно вообще нужно.
Agile подается, как методика создания высокопроизводительных команд. Действительно, производительность может вырасти в разы. Только методика накладывает дополнительные требования к квалификации команды и заказчика.
1. В составе команды должны быть разработчики, желающие вникать в суть задачи, анализировать её, а не простые кодеры. Команда должна быть высокопрофессиональная. Каждый участник должен уметь работать в составе группы. Тут вроде бы всё просто — все мнят себя крутыми перцами. В крайнем случае можно научить кого-то или поменять.
2. С заказчиками сложнее. В отличии от классической схемы проведения анализа требований группой аналитиков в начале этапа разработки, гибкие методики требуют постоянного контакта с заказчиком. Представитель заказчика должен быть способен ответить на вопросы по конкретной реализации. Он принимает решения о реализации функциональности, приоритетах и прочее. В моей практике у заказчика в большинстве случаев дефицит людей, поэтому отвлекать сотрудников вредно. Как доказать окупаемость такого отвлечения да еще и того человека, который разбирается в предметной области и может принимать решения я не знаю.
3. Гибкие методики предъявляют более высокие требования к коммуникации внутри команды, чем формализованные подходы. Поэтому появляются ограничения на размер команды и работы команды в одном помещении. Эти ограничения можно преодолеть, что является отдельной задачей.

Agile — это всего лишь методика. Это ни панацея, ни серебряная пуля. Как и во всех методиках, её эффективность больше зависит от команды. Ни один нормальный менеджер проектов не станет внедрять методологию сразу. Это очень затратный проект для команды, лучше поочередно внедрять хорошие практики.

Все эти Agile, SCRUM, XP, RUP, Waterfall, MS, Linux, Mac — это религия, а не опыт.

По теме: Принципы agile (english)