そう思うのです。
デザイン思考とアジャイル開発、そしてアジャイル開発フレームワーク（例：SCRUM）の関係性は、以下のように捉えることが出来ると思います。

デザイン思考とは何か、ググると関連記事がたくさん出来てきます。いくつか紹介。

デザイン思考では以下の要素を含むプロセスによってイノベーションが生まれると信じられています（いくつかのまとめ方がありますが、ソフトウェア開発との関わりとして最も自然だと思われるプロセスを紹介しています。曖昧さはデザイン思考の原理のひとつでもあります）

Empathy：共感すること
Problem： Framing 何が問題なのかを柔軟にとらえ定義する
Ideation：アイデア出し（出来るかどうかにはとらわれない）
Prototyping：動くもの触れるものを作る
Test & evaluate：問題の解決になったかテストして検証（フィードバックして学ぶ）

これらを実践し続けようとする心構え、態度、そしてそれらに価値を置くこと、そういう考え方がデザイン思考です。

アジャイルマニフェストのおさらい

デザイン思考とアジャイル開発の関連性について詳しく見ていく前に、そもそもアジャイル開発ってなんだったか思い出しましょう。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

デザイン思考はアジャイル開発の前提

下図は、デザイン思考のイノベーションプロセスの要素と、アジャイルソフトウェア開発マニフェストの項目の関連性を示しています。

変化への対応：　アジャイル開発は要するにChange Management（変化マネージメント）手法です。デザイン思考において「問題を解決する」とうことは変化する問題をに対して、解決という変化をもたらす営みということで、アジャイル開発の「変化への対応」との関連は全般的ということで線を引いていません。
個人と対話：人と人がコミュニケーションをするシーンすべてを含みます。共感を得ること、何をもって問題とするかのコンセンサスを得ること、アイデアを出し合うこと（brain storming, divergent thinking, convergent thinking)、そして実際に使って検証した結果の評価をフィードバックしてもらうこと。
動くソフトウェア：アジャイルでは末端のエンジニアもアイデアを出すことが推奨されています。エンジニアは実装・プロトタイピングを行います。検証評価をちょくせつ受け取ることでユーザーの痛み（喜び）を直接的に感じます。
顧客との協調：　使う人との関わりにおいて顧客に痛みをシェアしてもらい、問題定義に参加してもらい、解決の提案としての実装やプロトタイプを検証してもらいます。

次にアジャイル開発とSCRUMの関係をおさらいします。

アジャイル開発フレームワークの１つとしてのSCRUM

SCRUMはアジャイル開発手法のフレームワークのひとつにすぎません。フレームワークとは、アジャイル開発手法を実現する実践のあつまりのことです。より具体的な、人の役割、必要なもの（アーティファクト）、そしてプロセスなどを含みます。フレームワークが「お弁当箱」だとすると、実践はその中に詰めるご飯やおかずに相当します。

ポピュラーなものでは以下のようなフレームワークがあります

Extreme Programming (XP)
KANBAN
FDD

私個人はおもにSCRUMの経験を積みました。あとは少しだけXPとKANBANのスタイルを経験しましたが、それらをここで正確に解説出来るほどの経験はありませんので、これ以上の言及は控えます。アジャイルソフトウェア開発を実践するための方法であることは間違いありません。

デザイン思考とアジャイル開発とSCRUM

さて、以下はSCRUMの主要なプロセスや役割は方法などをデザイン思考とアジャイル開発のコンテクストで表してみました。（もともとは関連を表す線を引いていましたが、あまりにも複雑になったので、別個解説します）

ステークホルダー

SCRUMはチームで実践しますが、その構成メンバーに役割があります。

プロダクトオーナーは、顧客の視点を代表し、問題定義とアイデア出し、そして顧客を交えた検証評価などを担当します。
スクラムマスターはチームメンバーと後述するスプリントというプロセスを管理して、変化への対応を行いながら前に進めようとします。

開発者とテスター（そしてDevOpsと呼ばれる、開発とテスト、さらにオペレーションの全てに責任をもつ役割）は顧客の痛みを共感し、問題意識を共有し、アイデア出しに積極的に参加し、当然ながら実装を行い、検証評価を待ちます。

スプリント

スプリントとはSCRUMにおける、開発サイクルの単位のひとつです。（スプリントの詳細は割愛します）

デザイン思考というコンテクストで考えた時、スプリントはデザイン思考プロセスの1巡を表していると考えても差し支えないでしょう。

バックログには、顧客目線のユーザーストーリーが詰め込んであります。顧客の立場に立ち（共感して）優先順位をつけます。最優先とされたユーザーストーリーはプロジェクトバックログという大きな（長期的な）リストから、スプリントバックログという小さな（1周分）のバックログリストに、移動します。そのプロセスが、スプリントプランニングと呼ばれるものです。バックログは常に細かい問題に細分化されていきます。

デイリースクラムは数十分の全員参加スタイルの会議です。個人との対話を実践します。主に実装・プロトタイピングの進捗状況、優先順位の変更（変化への対応）、チームとして効率よく動くためのアイデア出し（アイデア出しはいつでも、だれからでも発信できます）。

CI（継続的インテグレーション）とCD（継続的デプロイメント）は、日々の実装の中で常に現段階での実装とプロトタイプの検証を可能にします。テストは可能な限り自動化され、CI/CDの一部として実行されます。テスト開発は実装の一部として当然視されます。

スプリントはスプリントレビューとレトロスペクティブで締めくくられます。問題定義、アイデア、実装やテスト、検証、評価、すべてを振り返り、次のスプリントに生かします。ここで学びが発生します。

オペレーション

アジャイル開発では、少しばかりの顧客にとっての価値がスプリント毎にリリースされます。リリースされた機能は、ソフトウェア全体の健康状態の一部としてモニターされます。モニターするのが具体的いはテレメトリが示すデータです。何人のユーザーがその機能を使ったか（人気のほどはどうか？）。ここではオペレーターという専門の役割がある場合もあればDevOpsというコードも書くテストもやる保守もやる、の人かもしれません。

アナリティクスはテレメトリの延長線上にあって、同義かもっとアグリゲートされた洞察なども含みます。スプリントを重なるにしたがって、ユーザー動向に変化はあるか、時間系、空間系でスライスしてみた場合どうなっているか、トレンドから未来を予測できるか、など。これらはチームと共有され、共感を引き起こし（喜びや悲しみ）、次のスプリントに行かされるでしょう。

ダッシュボードはテレメトリやアナリティクスと同義か、それをもっと整理された状態で通常1ページぐらいにまとめてレイアウトしたものです。ダッシュボードは開発者も含めたチームがよく見える場所に表示することで、顧客との共感や問題解決へのヒントや新たなアイデア出しの役に立つこともあるかもしれません。

プロトタイピングの誤解

ここで、デザイン思考にあるプロトタイピングに関連する「誤解」を解いておこうと思います。プロトタイピングは定義としては、試作であり、不完全なものであり、ハックされた、最適化されていない、使い捨ての、とてもエンドユーザーに見てもらえるようなものではありません。アジャイル開発とSCRUMではプロトタイピングされたものをスプリント終了の段階でリリースするというわけではありません。この点は私自身も、デザイン思考をソフトウェア開発と基礎とした場合に起こってしまう不都合だと感じます。

これは私の解釈なんですが、デザイン思考でいうプロトタイピングは、ソフトウェア開発におけるプロトタイピングとは異なり、もっと広い意味での「実験」のための「試作」だと思います。例えば、Google社はよく、全く新しいサービスを出して世に問います「どうですか？便利ですか？不便は解決しましたか？」と。試作とはいえ、機能が安定していなければ問題が解決されるはずはありません（されたとしても、時々それ以前に別の問題が起こってしまいます）。デザイン思考は、顧客と一緒に「真の解決を探る」プロセスです。そのプロセスに置いて、顧客が実際に使ってみることが出来るものが絶対に必要になります。触れるもの、使えるもの無しで、頭の中だけで、会議だけで、ソフトウェアを作るのは止めましょうということなのです。なので、プロトタイプは不完全で不十分でセキュリティーも穴だらけのものではなく、ソフトウェアとしての最低限の品質を保ちながら、顧客に実際に使ってもらえる程度のもの、と考えるべきでしょう。

プロトタイプは、Minimum Viable Product （MVP 実用最小限の製品）に置き換えて考えてみると納得がいくかもしれません。

デザイン思考を前提としていない、開発手法ウォーターフォール型開発

あることを理解するために、そうでないものを理解することが役に立つことがあります。
よくアジャイルと比較されるのが、ウォーターフォール型開発手法です。

ベースとなる考え方が、デザイン思考ではないことは間違いないですが、それに対する名前が見当たりません。ですから勝手に「工業・製造業的な思考」とここでは呼んでいます。

これは、工業・製造業でよくみられる、そしてそこでは素晴らしい結果をだしている手法です。私はこちらは完全に素人なので、何も言えませんが、少なくともウォーターフォール型に関して言うと：

直線的な開発工程
それぞれの段階が、前の段階の完了・完成を前提にしている（サイクルは原則無いし）
包括的な要求がある前提
仕様がプロセスをドライブする
役割が分かれている
リリース前に検証が行われる

そういった雰囲気を支える思考です。

おそらく、日本人は気質としても実績としてもこの考え方を自然に受け入れて、かつ実践してきたのではないかと思います。

アジャイルマニフェストで「アジャイルじゃない」とされたもの

もうひとつ、そうでないものを理解して、本来の目的をより深く理解するために、アジャイルマニフェストで否定された、というか推奨されていない実践を先ほどの全体像に入れ直して、見てみましょう。狙いとしては、それがいかにデザイン思考とSCRUMと相いれないかに気づくことです。

計画に重点を置くと製品を複数のスプリントで作ることは不可能になります。なぜなら、現在のスプリント以外は厳密には計画されていないからです。別の言い方をすると次のスプリントの計画は固定化されていないので、長期の計画がとても難しくなります。もちろん、アジャイル/SCRUMでも、長期的にどのような成果物を出せるかを示す必要が出て来るので、ユーザーストーリより粒度の高いエピックという単位で表すことが一般的です。

プロセスやツールは、オーバーヘッドを生みやすいです。日本人の好きなハンコはどうでしょう？ハンコやツールです。承認のハンコを押してもらうはプロセスです。アジャイル開発ではハンコはいりません。代わりに個人同士が会話すれば終わるのです。

包括的なドキュメント。仕様書、外部仕様、内部仕様、仕様書のレビュー、承認・・・コードを1行も書いていない日々が数週間も続いていたらそれはまったくもってアジャイルではないです。

契約交渉計画のために必須です。最終的にデリバーするものが何なのか、顧客に同意してもらわなくてはいけません。それが顧客にとって本当の解決なのか、デリバーされる6カ月後、1年後、2年後に前提となる技術が大きく変わってしまうかもしれませんが、そんなことはお構いなしです。そして、契約してもらったら顧客の痛みを共感することも、問題を別の角度からとらえなおすことも、さらなるアイデアやひらめきを出すことも必要ありません。契約通りにデリバーすれば成功です。アジャイル開発はこれが良いソフトウェアの作り方ではないと言っているのです。

まとめ

デザイン思考は考え方です。イノベーションの多くが、デザイン思考の実践から産まれています。また全く新しいイノベーションのためだけでなく、日々変わる技術やマーケットという「変化」に対応するためにも、デザイン思考がもはや必須となりつつあります。
ソフトウェア開発で、メインストリームのひとつになったアジャイル開発とそのフレームワークであるSCRUMを、ただプロセスとしてのみ捉えて実践を試みても、デザイン思考が実践できていなかったら成功するのは奇跡に近いでしょう。

アジャイル開発を実践すること、そしてさらにウォーターフォール型からアジャイルに変えることは勇気がいることかもしれません。考え方を変える時、勇気が必要なように。逆に言えば、考え方を変えればアジャイル開発は思ったよりもずっと簡単なものに思えるかもしれません。