Большой камень трудно бросить. — Немецкая пословица.

Представьте, что вы должны разработать программное обеспечения под заказ, которое будет поддерживать трейдеров в фронт-офисе финансовой организации. Торговцы должны иметь возможность покупать и продавать товары и рассчитать риск каждой сделки. Одной из основных трудностей является то, что продукты, доступные для торговли постоянно меняются. Если сосредоточить внимание на рынке опционов, вы увидите, что почти каждый день, новый продукт (опция) доступен для торговли, торги проходят иначе, и, базовые риски также меняются. Поэтому, если вы спросите вашего клиента о системных требованиях сегодня, вы, вероятно, получить иной ответ, чем если бы вы спросили завтра.

С каждым днем, который проходит без вашего  приложения, компания заказчика теряет несколько сотен тысяч долларов. Заказчик уверяет вас, что любая поддержка с вашей стороны и готовность вашего приложения может поможет снизить потери..

Аналогичная ситуация может произойти в телекоммуникационном секторе, или в любом другом домене с акцентом на электронный бизнес. Большая разница между более современными приложениями и более традиционными приложениями в том, что современные должны быть доступны на рынке быстро. В противном случае, приложение может стать устаревшим к тому времени как его используют, или компания может быть запущена из бизнеса. Иногда, более важно, чтобы соответствовать основным потребностям клиента быстрее, чем выполнять все требования в долгий срок, что может в конечном итоге быть слишком поздно.

Сложные процессы 1980-х и 1990-х годов столкнулись с трудностями, касающимися этих новых требований. В то время как в условиях с постоянными требованиями они были успешно реализованы. В таких областях, все формализовано, и подробный план можно установить в самом начале. Кроме того, каждый проект может «вслепую» следовать этому плану, без необходимости беспокоиться о его обновлении или изменении. Примерами этого являются оборонные проекты, или проекты от авиапромышленности. Также, имея стабильные требования, эти проекты часто имеют ограничения в бюджете и времени. Из-за этого, более важно, чтобы выполнить все требования, чем доставить их подмножество в срок и вложившись в бюджет. Тем не менее, цель меняется и в этих областях. Например, в оборонном секторе, изменяющиеся требования поддержки становятся все более важными.

Гибкие процессы обещают гибко реагировать на эти постоянно меняющиеся требования. Именно поэтому гибкие методологии разработки ПО в настоящее время рассматриваются как панацея успешной разработки программного обеспечения. Тем не менее, гибкие методики почти всегда рекомендуются для небольших проектов и для небольших команд.