バリューストリームマッピングはリーン(lean)生産技法のひとつであり，製品やサービスを消費者に届けるのに必要な，材料と情報の流れを分析するために使用される。製造業において Toyota が実施に成功したこのプロセスが，ソフトウェア開発においても適用されている。ソフトウェア開発は製造業と同じ道をたどるのだろうか？
Alan Cyment 氏は，自身が体験したソストウェアにおけるバリューストリームマッピングへの失望について述べる中で，それをむしろ自己矛盾した言葉である，と考えている。氏によれば，
確かにプロセスには最適化が必要です。無駄を見つけるように努め，それを排除できるならばすばらしいことです。行ったことを書き留めるのもよいでしょう。それが無駄なステップを見つけるのに役立つならばなおさらです。しかしスクラムチームがソフトウェアを開発するごとに，彼らの実施したプロセスをいちいち報告させるのは単にナンセンスなだけです。この種のゲームをプレイする上で肝心なのは，実行中のプロセスに適用することなのです。
このプロセスは製造業には適切だが，同じ感覚でソフトウェアに適用することはできない，と氏は述べている。
カイゼン研究所 (Kaizen Institute) によると，真のバリューストリームを確認できるのは反復的な作業を行っている場所である。彼らの取り上げているシナリオは，郵便局を通して配達される手紙，鉄片から冷蔵庫の筐体を製造する工程，病院内での患者の移動，承認手順に従って処理される保険書類，請求手続きを通過する購買発注，などといったものだ。彼らによれば，製品開発などのプロセスにはバリューストリームは適用できないし，するべきでもない。
仕様や設計を作り出す作業の手順が連続していることは，まずありません。ステップ１，ステップ２，ステップ１，ステップ３に戻ってステップ１ ... といった具合です。１ステップを終えて次のステップへ，というような固定した依存性はないのです。例えば設計作業を始めるときに，顧客の要求がすべて分かっていないこともあるでしょう。設計作業というのは，非常に反復的なプロセスなのです。アウトプットが知識であることもあります。従来型の VS マップを使って，製品開発のすべてのニュアンスをマップしようとする行為は正気の沙汰ではありません。うまく行くはずがないのです！
Julgen Appelo 氏はさらに，バリューストリームはまったく不適切なメタフォなのかも知れない，と指摘する。それによると，バリューストリームには A から B への一方向のバリューの流れ，という前提がある。しかし現実には，これはレアケースだ。氏はそれを，一方が他方の価値生産に取り組む，というバリューフローよりも，異なるステークホルダーたちが自身の価値創造を実現する共同作業，すなわちバリューネットワークなのだ，としている。
工場におけるバリューストリームのようにビジネスを表現するのは，よい方法ではありません。一方向に流れる “価値のストリーム” といったものは，ビジネスには存在しないのです。バリューストリームのメタフォは誤解を招きます。ビジネスとは，お互いの価値を創造するステークホルダ同士のネットワークなのです。すべてのステークホルダ (株主，従業員，顧客，サプライヤ，地域社会) が，相互のコラボレーションを通じて，自身の価値を作り出そうと努力します。ビジネスはバリューストリームではなく，バリューネットワークなのです。
バリューストリームマッピングを強く推奨する Mary Poppendieck，Tom Poppendieck の両氏 は，プロセスの無駄を発見する手段としてバリューストリームマップを利用するように勧めている。バリューストリームの概念を利用したチームのサクセスストーリはいくつもある。しかし変化を率先して受け入れ，自身も外部の影響とバリューネットワークの創造に基づいて変化する，という Agile 性を本質とするソフトウェア開発に対して，バリューストリームが本当に適用可能なのか，その点については疑問も残る。
製造業のメタファで考え続けることは，製造業務的な思考に縛られ続ける結果になります。違う考え方をしましょう。