タイトルの質問。イノベーションは、アジャイルですでに成功しているチームの小規模な創造的進歩を指します。
最良の答えは、「ゴールドカードの日数」に関するこの記事にまとめられています。
要約（言い換え、著者の意図を反映していない可能性のある私自身の解釈）：
- 開発者は、自分が取り組みたい仕事関連の興味深い（知的に刺激的な）ストレッチ目標を特定できます。
- これらのストレッチ目標は、チーム（製品所有者を含む）によって承認された後、「ゴールドカード」になります。
- チームは、これらの「ゴールドカード」の作成に1日かかることをお勧めします。
- 通常、これは金曜日に行われるため、「ゴールドカードの日」になります。
- スクラムに関しては、ゴールドカードは他のバックログアイテムと同様にスケジュールおよび追跡されます。チームは結果を実証する必要があります。
「ゴールドカード」の適用に関しては、他にもいくつかのポイントがあります（その記事にはありません）。
- 一人のチームメンバーにすべての楽しみを奪わせないでください。すべてのチームメンバーは、「ゴールドカードの日」をたまに取ることにより、創造的な時間を過ごすよう奨励されるべきです。
- 同じ方針に沿って、「単独のタスクではなく」チームの努力として「ゴールドカード」を作成し、そのタスクを社交的（チームビルディング）の瞬間として活用します。
革新とは、有用な解決策を見つけられないという本当のリスクがある研究（数か月から数年の恐ろしい作業）を指す実質的な質問です。
この先ほどの質問、研究環境での使用に適した極端なプログラミング手法はどれですか？この質問の根拠の多くをカバーしています。
（免責事項：選択したものではないが、私はその質問に対する回答の1つを書いた。）
要約すると、ソフトウェアの研究作業はペースが速いことがあります。参加者には、新しい情報に基づいて優先順位を付ける必要があります（発見/学習したアイデアを吸収し、新しいアイデアを合成することにより）。「成功の成果を示すのが遅く、成功した場合のみ」であるため、「遅い」という外観を与えます。
プロジェクト管理ベータに関するこの質問- プロジェクトマネージャーを研究チームに組み込むことの長所と短所は何ですか？-同じ理由もカバーしています。
精神で、はい。
mouvicielの回答で指摘されているように、ソフトウェア研究の精神はアジャイル宣言の精神と一致しています。次に議論するのは、リスクの高い研究を組織または管理方法論としてのアジャイルに適合させることができるかどうかです（「アジャイルの実践」）。
実際には、いくつかの質問に答える必要があります。
このリストは完全ではありません...
アジャイル手法がどのように生まれたのかを少し追跡する必要があります。
プロジェクトのスポンサーがいる場合、通常、アジャイル手法が使用されます。さらに、プロジェクトに資金を提供するスポンサーの意欲は限られています。プロジェクトにしばらく資金を提供した後、使用可能な（出荷可能な）品質のソフトウェアが定期的に配信されることを期待しています。
この質問における研究の種類は、「解決できない可能性のある努力」を指します。言い換えれば、この種の作業の本質には、関係者の意図と勤勉さのすべてにもかかわらず、最終的に失敗するリスクが伴います。
これはScrumButtスタイルのチェックリストではありません。
これは、「Que Sera、Sera」の方が良いかどうかを予測するプリフライトチェックリストです。
1.事前の透明性。プロジェクトのスポンサーは、プロジェクトの危険性について真実を語られていますか？
2.スポンサーの意欲。スポンサーはリスクを認識しており、資金提供を続けますか？
スポンサーは、一般的なビジネスプロジェクト、または一般的なソフトウェア/ IT /アジャイルプロジェクトよりも高いリスク許容度を持っている必要があります。すべてのスポンサーがこの基準に適合するわけではありません。それが合わない場合、プロがプロジェクトから撤退するのは良いことです。
3.プロジェクト全体の透明性。スポンサーはプロジェクトの真のステータスを定期的に通知されていますか？
これは、ステータス更新間の時間経過を誤って使用することにより、プロジェクトの後退や迫り来る障害を隠そうとする試みを阻止するためです。
4.スポンサーの積極的な参加。スポンサーは、それぞれの試みの細部、浮き沈み、約束、制限を知ることに興味がありますか？
ソフトウェア研究の問題は、多くの偽のリードが存在する可能性があることです-偽陽性（アプローチは機能すると信じていても成功しませんでした）と偽陰性（何かが不可能であると主張するだけで、他の誰かによって反証される） 。
アジャイルプロジェクトでは、チーム（スポンサーと利害関係者を含む）が計算されたリスクを取ることができます。「計算された」とは、リスクを負う人が十分な情報を得ていることを意味します。スポンサーがプロジェクトの詳細を知りたくない場合、スポンサーは自分でリスクを計算（判断）するための完全な情報を持っていません。
スポンサーが金銭的リスクを引き受けようとしても、意思決定リスクにも参加したくない（そして自身の選択に対する結果を受け入れる）ことを望まない場合、スポンサーはそのようなハイリスクの研究プロジェクトにも適さない。
5.研究チームは、プレゼンテーションのスライドとは対照的に、ソフトウェアの実行という形で進捗状況を示す（実証する）ことができますか？
この質問は、最終結果がソフトウェアを実行すると予想される研究プロジェクトに適しています。プレゼンテーションスライドは、CS理論を説明するのに役立ちますが、ソフトウェアの実装のset折を隠すために誤用される可能性もあります（または完全に欠如しています）。ソフトウェアデモは、このような誤用を防ぐことを目的としています。
6.スポンサーがプロジェクトの任意の時点で資金提供を停止することを決定した場合でも、研究チームは部分的に価値のあるソフトウェア製品を提供できますか？
この質問は、ケースバイケースでのみ関連します。一部の研究プロジェクトは漸進的です。複数のマイルストーンと成果物がある場合があります。研究チームは、アプローチを優先して「最も低いぶら下げ果物」を優先するか、「実行可能性を実証するための最小コストのアプローチ」を必要とします。
一部の研究プロジェクトはインクリメンタルではありません。単一の非常に具体的な技術的ブレークスルーを提供します。それはヒットかミスです。このタイプのプロジェクトの場合、唯一の漸進的な成果は、研究作業とプロトタイピング、そしておそらく学術出版物です。それにもかかわらず、これらの「非消耗品」のインクリメンタルな成果物は、大学、研究資金提供機関、および学術的な信用を築こうとしている大企業など、一部のタイプのスポンサーにとって価値があります。
ただし、このような特性を持つ研究プロジェクトは、以下でさらに説明するように、「カウボーイコーディング」アプローチも好む可能性があります。これらは適切に「ハック」と呼ばれ、学界で発生します。
ほとんどの学術研究の時間スケールのため、学術スタイルの研究資金は通常1年以上のコミットメントで提供されます。医学研究資金（学術的および商業的）は、さらに長期間にわたってコミットされる可能性があります。一方、典型的な商業資金による研究は、予告なしに終了したり、他のプロジェクトにリソース（人的資源）を完全に再割り当てしたりする場合があります。
7.サイロ対クロスファンクショナルの規模で研究チームはどのように測定しますか？
ある種の研究チームは非常にサイロ化されています。多くの場合、これは「学際的な」プロジェクトで発生します-各専門分野から1人のメンバーが関与しています。その結果、知識とスキルが重複しないため、1人のメンバーが他のメンバーのタスクを、非常に小さなタスクでも、引き継ぐことはできません。難易度は、コミュニケーションとタスクの定義にも拡大します。
非常にサイロ化されたチームは、毎日のスタンドアップミーティングなどのスクラムの儀式の恩恵を引き続き受けますが、「儀式」以外の相互作用はあまりないかもしれません。チームが話し合い、信頼を築くには、非常に社交的なアジャイルコーチが必要です。
8.アジャイルコーチが存在する場合、コーチは短い反復サイクル、タイムボクシング、および時間推定の提供を規定していますか？
これらのアジャイルプラクティスのそれぞれは、特定のタイプの研究プロジェクトに困難をもたらします。それにも関わらず、いくつかの熟練した研究グループがこれらの実践を高度な研究に適用できることが報告されました。これらの専門家チーム内でアジャイルコーチングがどのように行われるかについての詳細はないため、これらの各困難をどのように克服できるかを知ることができない場合があります。
9.研究チームは、Solo開発スタイルを他の方法論よりも採用することに全会一致で投票しますか？
編集済み： 以前のバージョンでは「カウボーイコーディング」というフレーズが使用されていましたが、これはプロ意識の欠如を暗示しています。ただし、ソロ開発とカウボーイコーディングには違いがあり、このチェックリスト項目の状況により、ソロ開発が正当な選択になる場合があります。
この質問は、開発の大部分を所有することを好むプログラマーがいることを示しています。研究チームが主にこのタイプのプログラマーで構成されている場合、チームメンバーのスキルセットはかけがえのないものである（以前のスキルサイロのポイントを参照）ため、チームメンバーは希望するものを交換する必要があります彼らのスキルと労働力のために。
ソロ開発とカウボーイコーディングの主な違いは、ソロ開発では、新しい機能を追加する前に、バージョン管理、ビルドの自動化、バグの修正など、「ジョエルテスト：より良いコードへの12ステップ」にリストされているプラクティスを採用できることです。
ソロ開発を行う各メンバーに有利な状況もあれば、カウボーイコーディングに有利な状況もあります。
カウボーイコーディングは、最終目標が「ポイントを作る」ことである場合、何かが技術的に可能であることを示すことによって好まれます。次のDEF CON®での優れたプレゼンテーションを除けば、配信や品質に関する要件はありません。
最後の質問。状況によってアジャイルチームが画期的な研究を実行できない場合、革新的な技術をどのように活用しますか？
いつものようにビジネス。他の企業（または学者、個人、ハッカー、スタートアップなどのチーム）が最初に困難な問題に取り組み、次にそれらから技術を購入/ライセンス供与します。ソフトウェア業界は何十年もの間、これらの原則に基づいて運営されています。
アジャイル手法で初期作業プロトタイプを表示することに重点を置いているため、チームは既存のソリューションを最初に探す必要があります。これは、チームを冗長な作業から救う可能性があるため、良いことです。