Dual-Track Agile

Marty CaganとJeff Patton によって普及したDual-Track Agileは、AliasにおけるDesiree Syの初期の仕事を基盤としており、「何を構築すべきかを見極める」という活動と「それを構築する」という活動を分離する——ただし人を分離することはない。ディスカバリートラックは、候補となるアイデアのリスクを減らすために、実験、インタビュー、プロトタイピング、分析を行う。デリバリートラックは、検証済みのアイデアを、出荷可能で本番品質のソフトウェアに変換する。両方とも継続的に、そして並行して、週を追って走り続ける。

つなぐ仕組みは、単一の優先順位づけられたバックログだ。ディスカバリーの仕事は、重要なリスク——価値（顧客はそれを求めるか）、使いやすさ、実現可能性、そして事業としての成立可能性——をすでに乗り越えた項目で、このバックログを満たすことだ。デリバリーはこのバックログの上位から取り出していく。チームは、異なる瞬間に異なる帽子をかぶる、同じ人々の集まりであって、2つの別々に配置されたユニットではない。

最大の失敗パターンは、このトラックを2つのチームとして扱うことだ：PM、デザイナー、リサーチャーからなる「ディスカバリーチーム」が、検証済みの仕様を壁の向こうへ投げて、エンジニアからなる「デリバリーチーム」に渡す、というものだ。これは、dual-trackが本来解消するはずだったウォーターフォール型の受け渡しを、そのまま再構築してしまう。エンジニアは、なぜそれが構築されているのかというコンテキストを失い、デザイナーは実際に何が実現可能かについてのフィードバックを失い、そしてバックログは、デリバリー側の誰も形作るのを手伝わなかった詳細なソリューションで埋まっていく。

トラックは同時進行の作業の流れであって、組織上の単位ではない。エンジニアはディスカバリーに参加する——実現可能性のスパイクでペアを組んだり、プロトタイプをレビューしたり、技術的なリスクを早い段階でフラグ立てしたりする。デザイナーとPMは、デリバリーの間もずっと関与を続ける。両者を並行して走らせる意味は、同じ頭脳が両方向にコンテキストを運ぶことで、ディスカバリーでの発見が、それが得られたその週のうちにデリバリーの方向を変えられる、ということにある。

ディスカバリーの飢餓状態は、よくある症状だ：デリバリーの圧力のもとで、ディスカバリートラックは静かに空になり、チームは最も声の大きいステークホルダーが要求したものを構築することに戻ってしまう。その対策は、ディスカバリーを、一つの段階ではなく、継続的なキャパシティとして保護することだ——「終わる」プロジェクトではなく、サイクルごとの一定のシェアとしてだ。

反対の失敗は、ディスカバリーがデリバリーよりもはるかに先を走り、リリースされる前に古くなってしまう、検証済みのアイデアの在庫を生み出すことだ。健全なペースは、この2つのトラックをおおよそ同じ足並みに保つ——ディスカバリーはデリバリーの1〜2サイクル先を保つが、10サイクル先ではない。もう一つのアンチパターンにも注意が必要だ——「検証シアター」であり、そこではディスカバリーが証拠ではなくスライドと意見を生み出す。ディスカバリーの項目は、それが取り除いた具体的なリスクを明示的に名指ししてバックログに入るべきだ（例えば「対象ユーザー8人中7人が支援なしでタスクを完了した」）。そうでなければ、それは本当に発見されたわけではない。

Dual-Trackは、ディスカバリーの発見とデリバリーの作業が単一の真実の源を共有しているときにのみ機能する——あるアイデアを検証した顧客インタビュー、それを要望した収益コホート、そしてそれを構築するスプリントカードが、リサーチのリポジトリ、フィードバックの受信箱、別々のトラッカーに散らばるのではなく、結合されているときのことだ。それらが別々に存在すると、トラック間の受け渡しでコンテキストが失われ、チームは検証されていない作業の構築に戻ってしまう。

共有基盤の上に構築されたプロダクトオペレーティングシステムは、これらを結合させて保持する：ディスカバリーで捉えられたインサイトは、そのオポチュニティ、その背後にいる顧客、そして最終的にそれがなるデリバリーのタスクと、常に結びついたままになる。AIOProductOSのフィードバック・ディスカバリーモジュール、PM Boards、そしてCustomer 360は同じ記録から読み取るため、デリバリーのカードはそれを正当化した証拠を示すことができ、ディスカバリーの発見はそれが引き起こした作業までたどることができる——これによって、バックログは本当に一つの事実の集合によって裏付けられたままになる。