アジャイル開発プロセスでは1つの開発サイクルを小さく（1サイクルの要求を小さく）し、
開発の各サイクルをプロジェクトが完了するまで反復します。
問題を細分化し、段階的に開発を進めていきます。
アジャイルプロセスの中には、XP、アジャイル統一プロセス（RUP）、
SCRUM等のさまざまな方法論があります。

例えばRUPにおいては、ただやみくもにサイクルを実行するのではなく、各サイクルを
「方向付け」「推敲（すいこう）」「作成」「移行」という4つのフェーズに分類し、これらのフェーズを経て
リリースにいたります。各フェーズは1つ以上の反復で構成されます。
このように、短いスパンで成果物をリリースし、その都度評価を行うことにより、
リスクを最小化しようとしたのがRUPのアジャイルプロセスです。

このように書くと、前述の問題をきれいに解決するかに見えるアジャイル開発ですが、
実際に反復型のアプローチを実行していくのは言うほど簡単ではありません。
アジャイルでは以下の要素すべてが成り立たない限り、コミュニケーションコストだけが増大して
プロジェクトは崩壊します。

・メンバー間の意思疎通
・問題の理解
・解決策の提案

つまり、このプロセスはプロダクトオーナーに負担が掛かりやすいと言えます。
開発者を用意してプロセスに乗せるだけで、希望したものができてくるということはありません。

しかし、これは「アジャイルだから」という問題ではなく、アジャイルの本質を理解しないまま
似非（えせ）アジャイルを実践することによる問題です。アジャイルプロセスの理解は、
ウォーターフォールのそれよりもはるかに困難です。

ウォーターフォールプロセスは、従来のソフトウエア開発において最もポピュラーな開発プロセスであり、
「要求分析」「設計」「実装」「テスト」「結合」を順序通りにこなしていきます。
滝から水が落ちるように、前工程の成果物に基づき次の工程の作業を行い、前工程への手戻りを想定していません。

このウォーターフォールプロセスは、開発の早い段階で要求が固定しており、
ドキュメントレベルでの設計だけで正しい設計を得られること、
つまり前の工程には間違いがないことが前提とされています。
ちなみにこの手順は、建築等で適用されるプロセスを参考に作られています。

ウォーターフォール開発が得意とする状況とされるのは以下の通りです。
・高い可用性が求められるシステムである場合
・メンバーの開発経験が少ない場合
・要件がほとんど変わらない場合
・開発メンバーの数が多い場合
・組織的文化が秩序を重視するものである場合

アジャイルはその正反対の状況を得意とします。
・可用性よりも優先されるものがあるシステム
・メンバーとして開発に熟練した開発者が参加している場合
・要件が常に変化していく場合
・開発メンバーの数が少ない場合
・組織的文化がさまざまな状況に意欲を持って取り組む場合

（出典：『Balancing Agility and Discipline: A Guide for the Perplexed』）

開発手法は単純に度の手法が良い、悪い、というものではなく、
重要なのはプロジェクトを失敗させないことにあります。
どのような開発手法においても、プロジェクトには必ずリスクが存在します。
プロジェクト失敗の原因の多くは以下のようなものです。

・スケジュールの欠陥―強気過ぎるスケジュールは悪。予実の乖離（かいり）を生み出す。
・要求の増大（変更）―外的要因も影響し、時間の経過と共に要求は変わっていく。
・人員の離脱―見積もりの時点で、メンバー離職の可能性は大抵考慮されていない。
・仕様の崩壊―仕様はあいまいに作れるが、製品はあいまいに作れない。
・生産性の低迷―少人数チームでは平均値のブレが大きい。能力がマイナスに振れるリスク

（出典：『熊とワルツを』） 　

これらのリスクが担保できるのであれば、開発プロセスがアジャイルでもウォーターフォールで あっても構いません。
それぞれのメリット・デメリットを検討した上、よりプロジェクトが成功しやすい開発プロセスを選択すべきです。