組織がアジャイルに移行する理由のひとつとして，変化によりよく対応できるようになるため，というものがある。しばしば変わるユーザニーズは開発チームに対して，新たな製品要件への適応を要求する。アジャイルは開発チームにとって，顧客ニーズを満足する製品を提供する上で有効な手段であると同時に，必要のない(使用されない)機能を含まない製品を提供する手段でもある。そのような機能を表すものとして，リーンソフトウェア開発ではムダ(無駄，waste)という言葉が使われる – ユーザにとっての価値を付加しないものは，すべてムダとみなすのだ。ならば開発組織にとってのムダ削減には，ウォーターフォールからアジャイルへのソフトウェア開発の移行は役に立つのだろうか？
Ron Lichty氏はウォーターフォールからアジャイルに転向する上で，もっとも説得力のある理由をテーマとしたブログ記事 "The most convincing reason to change from waterfall to agile" を書いている。その理由とは，ムダに関するものだ：
しかしながら，私にとって決定的だったのは – 熱心なアジャイル信者から，ウォーターフォールに対する完全な幻滅へと転換させたのは – ムダでした。リソースのムダ，開発時間のムダ，労力のムダ。
氏は開発者やマネージャに対して，次のような質問をした時のことを説明する – 400ページの要件定義書が提示されたとき，実際に提供される機能はその中の何パーセントなのか。返ってきた答は：
(…) 45%を越えることはほとんどなく，大部分が15～25%，もっとも低いものでは，10%の要求仕様しか実現できていないというのもありました。
アジャイルとウォーターフォールとの大きな違いは，提供するものを決める意思決定の方法にあると氏は考えている。これは提供する価値にも影響する。
私がアジャイルでよいと思うことのひとつは，チームが取り組む要件の優先順位が明確であることです。チームは常に，バックログの一番上にある要件に最優先で取り組みます。バックログの順位はプロダクトオーナが，開発リーダとのコラボレーションのもとで，スプリント毎に設定するのです。
これに対してウォーターフォールのシナリオでは，価値が答になることは決してありません。戻ってくるのは "コーディングが一番簡単", "もっとも興味があった(一番派手だった!)", "要件を読む中で，一番ピンときた", "面白そうだった" というような答です。400ページのウォーターフォール要件の優先付けは，ほとんど例外なく開発者が行うのです。プロダクトオーナではありません。
Mary Poppendieck，Tom Poppendieck両氏のWebサイト "The Lean Mindset" には，リーンソフトウェア開発の原則についての説明がある。ひとつは"ムダの排除"だ：
製品開発における３大ムダは：
間違ったものを作る
"もともとやるべきでないことを効率的に行うことほど、無駄なものはない。 " – Peter Drucker間違った方法で作る
正しく作るために十分な時間がないのならば，正しく作らないために十分な時間もないはずです。バッチとキューの考え方
中途半端な作業は欠陥を隠し，陳腐化を招き，タスク切り替えを発生させ，価値の実現化を遅らせます。
Mike Cudemo氏のブログ記事 "Agile vs Waterfall - what is the big deal?" は， ウォーターフォールとアジャイルの要件処理の方法に関する違いを説明することから始まっている：
ウォーターフォールプロセスでは，計画を設計した後に "要件の凍結" を行おうとします。ご想像どおり，これは現実的ではありません。後になって要件の問題が発生し，(...) その修正はさらに高価なものになるだけでなく，場合によっては不可能なことさえあります。(...) アジャイルメソッドでは，事前に "要件の確定と凍結" を試みることは決してありません。ユーザ自身の目に要件が見え始めれば，要件は発展し変化するものだ，という前提に立っているからです。
アジャイルソフトウェア開発において，イテレーションは成果をコントロールする機会を与えてくれる，というのが氏の見解だ：
アジャイルメソッドでは要件と設計，コード，テストを，反復的で小規模な開発フェーズに集中しようとしています。本質的にアジャイルメソッドは，小さく完結したウォーターフォールの連続なのです。エンドユーザやビジネス上の関係者たちは，展開を続けるシステムを確認し，体験することができます。コース修正も明確で，ナビゲートも容易になります。
そして氏は，ウォーターフォールをIT予算の無駄遣いだと結論付ける：
CFOの多くは，運用コストの削減と技術投資の実践との間で，自分が複雑なジャグリングを強いられていると感じています。CFOはCIOに対して，既存の投資を活用しつつ，経営的な成長と競争上の変化に迅速に対応できる能力を開発するように迫ります。プロジェクトにおいて失敗は許されないものですが，それにも関わらず，統計上ではウォーターフォールアプローチの実に60%が，企業のITプロジェクト予算を無駄にしているのです。
"Agile Is Cheaper, Right?" という記事ではKenny Grant氏が，ムダを特定し処置する上で，チームにとってアジャイルアプローチがいかに役立つか，という説明をしている。アジャイルソフトウェア開発それ自体が，ソフトウェアを開発する上でウォーターフォールよりコスト的に有利なのではない，スコープの変更やプロジェクトの修正の扱い方が問題なのだ，と氏は言う。
アジャイルとウォーターフォールを比較するのは，リンゴとオレンジを比べるようなものです。アジャイルの原則やプロセスに従えば，そこで生み出される製品は，ウォーターフォール型の方法論を用いて同じビジネスニーズに対処した場合とは常に違うものになる，と私は思うからです。(...) ムダと判断される部分，あるいは提供する価値のない部分は，必ずと言っていいほど存在します。アジャイルのビジネス価値と作業の必要十分性への執拗なまでの集中は，このムダ – あるいは収益率(ROI)の低い要件 – を特定すると同時に，それを修正ないし除外する機会をチームに提供してくれます。
ビジネスニーズや要件がプロジェクト期間内に変更されるであろうことを念頭においた上で，氏は今一度，"アジャイルは経済的か？" という問いを繰り返す：
"特定のビジネスニーズを考えたとき，アジャイルの原則やプロセスに従うことによって，これらのニーズに(それ以上でも，以下でもなく)一致する製品の開発を，ウォーターフォール型の方法論よりも経済的に行うことが可能になるのでしょうか？" この場合の答は，"もちろんです！"