10.7 アジャイル

概要と動機

アジャイルは、ソフトウェア(そして価値)を、反復的かつ増分的に、それを使う人々と密接に協力して届けるための心構えです。2001年のアジャイルソフトウェア開発宣言に体系化されたこれは、プロセスとしてではなく、価値と原則の集まりとして理解するのが最善です。それ以前の、計画重視、契約重視、文書重視の既定よりも、個人と対話、動くソフトウェア、顧客との協調、変化への対応を優先する。スクラム、カンバン、エクストリームプログラミング(XP)のような枠組みは、その心構えの実装です。有用な出発点ですが、心構えそのものではありません。この章は、方法を広く概観する1.4章(働き方)を、アジャイルに特化して深く掘り下げることで補完します。

アジャイルは、ディスカバリーとデリバリーのパイプライン(11.1–11.2章)を動かすのと同じ力に駆動されています。ソフトウェアの要件は最初からすべて知られているのではなく発見されるものであり、世界は長い計画が吸収できるより速く変わります。計画をすべて最初に立てる一斉のデリバリーは、繰り返し、遅く、予算を超え、そして何より悪いことに、間違ったシステムを生みます。すべての学びが最後、行動するのが最も高価な時に届くからです。アジャイルの中核の賭けは単純です。実際に動くソフトウェアを築き、本物のフィードバックを得る短いサイクルは、推測の長いサイクルに勝る。うまく行えば、リスクを先送りするのではなく、継続的に減らします。

大きなチーム、企業、政府にとって、アジャイルは強力であると同時に、しばしば歪められます。企業は数百のチームにわたってそれを採用し、意思決定の仕方や価値の測り方を変えないまま、しばしば儀式に矮小化します(「いまスタンドアップをやっている」)。政府は、反復的でユーザー中心のデリバリーが大きな公共プログラムのリスクを明らかに下げるので、意図してアジャイルを受け入れました。米国のデジタルサービス(USDS)とDigital Services Playbook、英国の政府デジタルサービス(GDS)とサービス標準、アジャイル調達の改革はすべて、注目を集めたウォーターフォールの失敗に部分的に応じて生まれました。得るものは本物です。「名ばかりのアジャイル」という失敗の様式も同じです。

主要原則

宣言の四つの価値(人、動くソフトウェア、協調、応答性)を、プロセスの成果物より重んじる。
動くソフトウェアを頻繁に小さな増分で届ける。動くソフトウェアが進捗の第一の尺度です。
変化を歓迎する。遅くてもです。適応性は失敗ではなく機能です。
意欲があり、権限を与えられた、自己組織化するチームの周りに築く。
ユーザーと利害関係者と継続的に協働する。
定期的な周期で振り返り、改善する。
人道的なペースと技術的卓越性を保つ。技巧のない速度は崩れます。

推奨事項

儀式ではなく価値と原則に錨を下ろす

アジャイルの最も重要な唯一の推奨は、なぜを先頭に置くことです。毎日のスタンドアップ、スプリントレビュー、振り返りを行いながら、それでも固定の日付に固定スコープでコミットし、悪い知らせを隠し、計画を決して変えないチームは、アジャイルではありません。会議のあるウォーターフォールです。真の俊敏さのチェックリストとして、12の原則を使ってください。動くソフトウェアを頻繁に届けているか。次のイテレーションで変更を歓迎できるか。チームが仕事をどう行うかを決めているか。顧客は実際にループにいるか。儀式がそれらの成果を生んでいないなら、儀式ではなく、成果を直してください。

枠組みを、宗教ではなく出発点として選ぶ

仕事に合う枠組みを選び、適応させます。

スクラム: 時間枠のあるスプリント、優先順位づけされたバックログ、定義された役割(プロダクトオーナー、スクラムマスター、開発者)。明確なプロダクトオーナーのいる機能のデリバリーに良く、仕事が非常に割り込み駆動のときは弱い。
カンバン: 明示的な仕掛かりの仕事(WIP)の制限とプル型システムによる継続的なフロー。サポート、運用、予測できない到着に良く(そしてフローと待ち行列理論に直接根ざしています。11.2章、11.3章を参照)、WIPを制限するとリードタイムが短くなります(リトルの法則)。
エクストリームプログラミング(XP): テスト駆動開発、ペアプログラミング、継続的インテグレーション、リファクタリング、小さなリリースを含むエンジニアリングの実践。どの枠組みも持続可能にする技術的な背骨。
スクラムバンと混合形: 多くの成熟したチームが行き着く、実用的な組み合わせ。

枠組みは足場です。役立つものを保ち、役立たないものを捨て、「枠組みがそう言うから」が「原則がなぜかを言う」を上書きするのを決して許さないでください。

技術的卓越性を主張する

エンジニアリングの規律のないアジャイルは、急速に、保守不能なコードの高速な生産、「ダークスクラム」へと劣化します。チームが、欠陥と技術的負債のタールピットにスプリントして落ち込む状態です。XPの実践は任意の追加ではありません。継続的インテグレーション(8.1章)、自動テスト(2.4章)、リファクタリング、トランクベース開発(2.6章)、クリーンな設計(2.2章)が、チームがソフトウェアを安く変更し続けられるようにするもので、それが俊敏さの前提のすべてです。持続可能なペースも同じ理由で重要です。燃え尽きたチームは、品質も応答性も保てません。

慎重にスケールし、デスケーリングを好む

SAFe(Scaled Agile Framework)、LeSS、Nexus、Scrum@Scaleのようなスケーリングの枠組みは、共有の目標に向けて多くのチームを調整します。役立ちえますが、警告を伴います(1.4章と同様に)。重いスケーリングの枠組みは、しばしば、アジャイルが取り除くはずだったまさに指揮統制と計画重視のオーバーヘッドを再導入します。大きな枠組みを採用する前に、デスケーリングを試してください。明確な所有と最小限のチーム間の依存関係を持つ、独立したストリームに揃ったチームを軸に組織し(1.2章)、そもそも必要な調整の仕組みを減らします。調整が本当に必要な所では、機能する最も軽い構造を加え、アウトプットではなくアウトカム(OKR、目標と主要な結果、11.1章)に結びつけます。

企業と政府で俊敏さを本物にする

適応型のデリバリーと制度的な制約は共存できますが、意図した設計が必要です。

ハイブリッドのガバナンス: イテレーションが監督と争わず満たすよう、予測型の資金/コンプライアンスの殻(10.6章)の内側にある、適応型のデリバリーの中核。
アジャイル調達: 一つの固定スコープの巨大契約ではなく、モジュール式で成果ベースの契約と、より短いインクリメント。公共部門のアジャイルが最も成功あるいは失敗する所です。
進めながらのコンプライアンス: 監査、アクセシビリティ(5.3章)、セキュリティ(4.1章)を、遅いゲートではなく、自動化とフィットネス関数(アーキテクチャと品質の性質を継続的に検証する自動化されたチェック。8.5章、1.6章)を通じてインクリメントに組み込む。
本物のユーザーへのアクセス: 最も難しく最も重要です。チームには、市民や顧客との本物の接触が必要で、調達とセキュリティの規則がしばしばそれを妨げます。

継続的に改善し、本気でそうする

振り返りはアジャイルの改善のエンジンで、変化を生まなければ無価値です。少数の具体的で所有された行動を生む振り返りを行い、次の振り返りの前に実際にそれを完了させます。アウトカム(その変更が主要な結果を動かしたか。11.1章を参照)とフロー(リードタイムは縮んでいるか。11.2章、11.3章を参照)を測定します。ベロシティは測定しないでください。それは容量のシグナルで、生産性の目標として使った瞬間に嘘になります。

トレードオフ: 長所と短所

決定	長所	短所
アジャイル(適応型)	速いフィードバック。変化を吸収。早期で継続的な価値	スコープ/コストを最初に固定しにくい。関与する顧客と規律を要求
ウォーターフォール(予測型)	予測可能なスコープ。契約/監査に優しい	遅いフィードバック。一斉のリスク。不確実な要件に不向き
スクラム	周期、役割、集中。広く理解されている	儀式のオーバーヘッド。割り込み駆動の仕事に苦労
カンバン	フロー、WIP制限、柔軟。運用に最適	構造が少ない。制限を保つ規律が必要
重いスケーリング(SAFe)	多くのチームを調整。大きな組織になじみがある	指揮統制を再導入しうる。儀式が重い
デスケーリング/チームの自律	調整のオーバーヘッドが少ない。チームが速い	低い結合と強いプラットフォーム/所有が必要

決定的な緊張は適応性対予測可能性で、古典的な誤読は、アジャイルが「計画なし」を意味するというものです。そうではありません。スコープを柔軟に保ちながら、継続的に計画し、成果と周期にコミットすることを意味します。もう一つの繰り返される罠は、アジャイルをプロセス(儀式)だけ、あるいはエンジニアリング(XP)だけとして扱うことです。両方が必要です。

チームで議論すべき問い

企業や政府の文脈で、契約はモジュール式で成果ベースですか。それともデリバリーは一つの固定スコープの巨大契約の中に閉じ込められていますか。アジャイル調達は、公共部門の俊敏さが最も成功あるいは失敗する所です。単一の固定価格で固定スコープの契約は、デリバリーチームが会議を何と呼ぼうと、ウォーターフォールを強いるからです。より短いインクリメントを伴うモジュール式で成果ベースの契約は、固定された資金の範囲でスコープを価値ある中核へと動かせるようにし、それはまさに現代の公共部門の成功の背後にあるパターンであり、過去の一斉の失敗への解毒剤です。証拠を持ち込んでください。現在の契約を見て、ベンダーが実証された動くソフトウェアに対して支払われているのか、何年も前に承認された固定スコープに対してなのかを尋ねます。答えは、チームが社内でどの枠組みを採用するかよりはるかに、次の調達の構造化を形づくるべきです。契約が遠く、全部かゼロかのゴーライブを義務づけている間は、デリバリーで適応的になれません。
監査、アクセシビリティ、セキュリティは、自動化を通じて各インクリメントに組み込まれていますか。それとも遅いゲートとして取り付けられていますか。進めながらのコンプライアンスが、適応型のデリバリーを制度的な制約と共存させます。リリース前の大慌てのために取っておくのではなく、自動化とフィットネス関数を通じて、チェックをインクリメントに組み込みます。遅いコンプライアンスのゲートは、アジャイルが取り除くために存在する一斉のリスクを再導入します。高価な問題が、最も直しにくい最後に表面化するからです。証拠を持ち込んでください。最後のインクリメントについて、アクセシビリティ、セキュリティ、監査の証拠がパイプラインで自動的に検証されたか、ローンチ前の手作業のレビューに先送りされたかを確認します。答えは、これらの性質を継続的な自動チェックに押し込み、監督が別の段階ではなく築く行為によって満たされるようにすべきです。それはまた、規制対象のプログラムを、監査の前の数週間だけでなく、監査の間も誠実に保つものです。
チームが技術的負債に向かってスプリントしているかどうかをどう知り、ローンチの圧力のもとで持続可能なペースを何が守りますか。 エンジニアリングの規律のないアジャイルは、チームが欠陥と保守不能なコードのタールピットに速く突っ込むダークスクラムへと劣化し、燃え尽きたチームは品質も応答性も保てません。XPの実践(継続的インテグレーション、自動テスト、リファクタリング、トランクベース開発)が、チームがソフトウェアを安く変更し続けられるようにするもので、それが俊敏さの前提のすべてなので、日付が迫ったときに手放す任意の追加ではありません。証拠を持ち込んでください。リードタイムが縮んでいるか伸びているか、欠陥率が上がっているか、チームが各スプリントに間に合わせるために静かに長く働いているかを追跡します。答えは、技術的卓越性と人道的なペースを交渉の余地のないものにすべきです。技巧を犠牲にして買われた速度は、数イテレーション以内に崩れるからです。フローとアウトカムを測定し、ベロシティを目標にしてはなりません。容量のシグナルを生産性の目標にした瞬間、それは嘘になるからです。
重いスケーリングの枠組みに手を伸ばす前に、そもそも調整の必要を生むチーム間の依存関係を減らそうとしましたか。 これは大きな組織にとって最も重要です。多くのチームが一緒に出荷しなければならないときの反射は、SAFe、LeSS、Scrum@Scaleのような枠組みを買うことで、重いスケーリングの仕組みは、アジャイルが取り除くために存在する指揮統制と計画重視のオーバーヘッドを、しばしばこっそり持ち込むからです。相反する考慮は本物です。ある調整は本当に必要で、独立したストリームに揃ったチームへのデスケーリングは、低い結合、明確な所有、チームがセルフサービスできる成熟したプラットフォームを要求し、まだそれがないかもしれません。議論に証拠を持ち込んでください。チームが互いを待たせる実際の依存関係を地図にし、チームの境界とサービスの所有を意図して再設計したら、いくつが生き残るかを尋ねます。数十のチームの組織図が普通の企業と政府のプログラムでは、誠実な問いは、単純化できるはずのアーキテクチャとチーム設計を補うために調整の構造を加えていないか、つまりそもそも調整を減らせないか、ということです。
チームは、築く対象の市民や顧客と本物の繰り返される接触を持っていますか。それともフィードバックは代理を通じて濾過されて届きますか。 顧客との協調は宣言の四つの価値の一つで、本物のユーザーの接触を欠くイテレーションは、静かに間違ったものを最適化し、それがアジャイルが防ぐはずの最も高価な失敗です。緊張は、直接のアクセスは規模で手配するのが難しく、大きな組織や公的な組織が尊重しなければならない調達、プライバシー、セキュリティの規則にまさに妨げられることが多いので、容易な道は、代理で代用することです。ビジネスアナリスト、利害関係者の委員会、前四半期の調査資料。証拠を持ち込んでください。最近のいくつかのインクリメントについて、実際に本物のユーザーがソフトウェアを使って検証されたものがいくつあり、ユーザーが何を望むかについての誰かの意見に頼ったものがいくつあったかを数えます。政府のサービスでは、ユーザビリティテストが最も影響を受ける人々に届いたか、支援技術のユーザーやデジタルの自信が低い人々を含めて確認を加えてください。自信のある多数派にしか機能しない公共サービスは、すべての儀式が予定通りに走っていても、説明責任の義務を果たせていないからです。
チームは、成果と周期を軸に資金を受けて統治されていますか。それとも、儀式の背後で静かにウォーターフォールを強いる固定スコープを軸にですか。これが本物の俊敏さと偽のアジャイルの違いで、チームの上、つまりお金がどう放出され成功がどう報告されるかで決まり、スタンドアップが行われるかどうかでは決まりません。相反する引力は、財務、ポートフォリオ、監督の機能が、何年も前に固定された予算に対して固定スコープを承認するよう築かれており、柔軟なスコープの成果に資金を出すよう求めることが、抵抗される制御の喪失に感じられることです。証拠を持ち込んでください。現在の取り組みがどう資金を受け、何を報告しているかをたどり、チームが届けられた成果とフローで測られているのか、ストーリーポイントと、はるか前に承認されたスコープの遵守で測られているのかを確認します。企業と政府の設定では、これを資金とコンプライアンスの殻(10.6章)に直接結びつけてください。お金が遠く、全部かゼロかのゴーライブにコミットされているなら、チームは儀式をどれだけ忠実に行っても適応的になれず、修正は、デリバリーチームではなくガバナンスのモデルに属します。

セクター別の視点

スタートアップ。 価値を生きて、枠組みの議論は飛ばしてください。毎週本物のユーザーに動くスライスを出荷し、フィードバックが毎日届くほど創業者と初期の顧客の近くに座り、証拠が現在の賭けが間違っていると言った瞬間に、方向転換を歓迎します。最も乏しい資源はエンジニアリングの注意なので、ローンチの圧力のもとでも技術的卓越性(継続的インテグレーション、自動テスト、トランクベース開発)を守ってください。その規律こそ、来週安く方向転換できる状態を保つものだからです。

小規模事業者。 アジャイルコーチはおらず予算も厳しいので、アジャイルを、人員を置く変革プログラムではなく、少数の習慣として扱ってください。短い週ごとのサイクル、WIP制限のある見えるボード、毎週実際に終える具体的な改善一つ。儀式がほとんど要らず割り込み駆動の仕事に合うカンバンに頼り、重いプロセスを立ち上げる代わりに、すでに買っているツールに組み込まれた実践を採用します。労力は、スクラムをどれだけ忠実に真似るかではなく、有用なソフトウェアをより頻繁に顧客に出荷しているかで判断してください。

大企業。 問題は、指揮統制を再導入せずに多くのチームを調整することです。重いスケーリングの枠組みを採用する前に、デスケーリング、つまりストリームに揃ったチーム設計と堅実なプラットフォームによるチーム間の依存関係の削減を好みます。固定の年次スコープとストーリーポイントではなく、アウトカム(OKR)と周期を軸に資金を出して統治し、XP式のエンジニアリングの実践をチーム間で交渉の余地のないものにし、グループが儀式ではなく証拠で改善するよう、フロー指標とアウトカムの指標を伴うポートフォリオとしてデリバリーを管理します。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。一つの固定スコープの巨大契約ではなく、より短いインクリメントを伴うモジュール式で成果ベースの契約を構造化してください。アジャイル調達こそ、公共部門の俊敏さが最も成功あるいは失敗する所だからです。監督が築く行為によって満たされるよう、自動化を通じて各インクリメントに監査、アクセシビリティ、セキュリティを組み込み、進捗と公的な価値の証拠を監督機関に公表し、各イテレーションで市民(支援技術のユーザーを含む)への本物のアクセスを求めて戦ってください。それが最も頻繁に交渉で手放される制約だからです。

事例

スタートアップ。 5人のスタートアップは、儀式の議論を飛ばして、アジャイルの価値を直接生きます。毎週本物のユーザーに動くスライスを出荷し、フィードバックが毎日届くほど創業者と初期の顧客の近くに座り、証拠が現在の賭けが間違っていると言ったとき、来週の方向転換を歓迎します。チームは速度のために技術的卓越性を手放すことを拒むので、ローンチの圧力のもとでも継続的インテグレーション、自動テスト、トランクベース開発は交渉の余地がなく、毎週金曜日の振り返りは、次の前にチームが実際に終える具体的な変更を一つ生みます。ベロシティを目標として追跡することはなく、代わりに、出荷した仕事がアクティベーションを動かしたかと、リードタイムが縮んでいるかを測定します。

大企業。 通信会社の60チームの変革は、最初は「スクラムをやる」が改善は見られません。チームは依然として固定の年次スコープを受け取り、ベロシティで報告しています。リセットが原則に焦点を戻します。四半期ごとのOKRが機能の義務づけに取って代わり、チームはチーム間の依存関係を減らすよう再編され(デスケーリング)、XPの実践(CI、TDD、トランクベース開発)が交渉の余地のないものにされます。リードタイムは下がり、欠陥は減り、そして決定的に、事業はストーリーポイントではなくアウトカムを測り始め、アジャイルのデリバリーをディスカバリーのパイプライン(11.1章)につなげます。

政府。 デジタルサービスのチームは、ハイブリッドのガバナンスの殻の内側でアジャイルを使って、市民向けの給付申請を作り直します。動いてユーザーテストされたソフトウェアを届ける2週間のインクリメント。すべてのインクリメントに組み込まれたアクセシビリティとセキュリティ。そして単一の固定価格契約に取って代わるモジュール式の調達。各イテレーションでの市民(支援技術のユーザーを含む)との本物のユーザビリティテストが、古いウォーターフォールのプロセスなら出荷していたはずの問題を捉えます。プログラムは使えるサービスを早期に届け、測定可能な公的な価値を監督機関に示します。これは現代の公共部門の成功の背後にあるパターンであり、過去の一斉の失敗への解毒剤です。

ビジネスケース: 動機、ROI、TCO

アジャイルの見返りは、リスクの低減とより速い価値の実現から来ます。動くソフトウェアを早く頻繁に届けることで、チームは不確実性を継続的に証拠に変え、遠く高価なゴーライブでではなく、安いうちに、間違ったものや動かないものの失敗を捉えます。現代のデリバリーの背後にある研究(11.2章のDORA、DevOps Research and Assessmentの発見)は、アジャイルが促す実践(小さなバッチ、頻繁なリリース、速いフィードバック、技術的卓越性)が、より良いデリバリーと安定性と組織のパフォーマンスに相関することを示します。早期のインクリメントはまた、より早く価値を返し始めるので、最後まで何も返さない一斉のリリースに比べて、ROIのタイミングと総量を改善します。

総所有コストでは、エンジニアリングの規律が本物であれば、アジャイルはシステムの寿命にわたる変更のコストを下げます。その支配的なリスクは偽のアジャイルです。原則も技巧もない儀式で、会議のオーバーヘッドを加えながら恩恵を何も届けず、誠実なウォーターフォールより悪くなりえます。したがってビジネスケースは条件つきです。アジャイルを心構えにエンジニアリングを加えたものとして採用するときROIは高く、儀式として採用するときほぼゼロ(あるいはマイナス)です。アジャイルを「速くなること」ではなく、継続的なリスクの低減とアウトカムの測定として枠づけ、投資に新しい会議だけでなく技術的な実践が含まれることを主張して、リーダーシップに論拠を示してください。

アンチパターンと落とし穴

偽/カーゴカルトのアジャイル: 決定、資金、心構えがウォーターフォールのままで、儀式が行われること。
生産性としてのベロシティ: 容量の見積もりを目標に変え、それを腐敗させること(グッドハートの法則)。
ダークスクラム: 技術的卓越性なしにスプリントし、保守不能で欠陥だらけのコードに至ること。
変化のない振り返り: 完了した行動を何も生まない内省。
スコープと日付とコストの固定: アジャイルと呼びながら、品質が静かに圧力を吸収すること。
不在の顧客: 本物のユーザーのフィードバックがなく、イテレーションが間違ったものを最適化すること。
枠組みの崇拝: 「SAFe/スクラムがそう言う」が、原則とチームの判断を上書きすること。
デスケーリングの前のスケーリング: 依存関係を減らす代わりに、重い調整の枠組みを加えること。

成熟度モデル

レベル1、開始。 ウォーターフォールあるいはその場しのぎのデリバリー。一斉のリリース。仕事は反応的で計画が重く、反復的なフィードバックも、アジャイルがなぜ役立ちうるかの共有の感覚もありません。
レベル2、発展。 少数のチームがアジャイルの儀式(スタンドアップ、スプリント、振り返り)を採用しますが、実践は組織全体で一貫していません。心構えとエンジニアリングの規律が儀式に遅れ、ベロシティはアウトプットとして扱われ、スコープは依然として最初に固定されます。
レベル3、標準化。 価値と原則が、すべてのチームに文書化され期待されて、組織全体で本当に仕事を導きます。XP式の技術的卓越性(CI、自動テスト、リファクタリング、トランクベース開発)は標準の実践で、チームは自己組織化し、顧客は各イテレーションで関与し、振り返りは具体的で完了した変更を生みます。
レベル4、管理。 デリバリーが、ベースラインに対して測定され制御されます。チームは、リードタイム、デプロイ頻度、変更失敗率、欠陥のすり抜け率(DORA式のフローと安定性の指標)を、主要な結果に結びついたアウトカムの指標と並べて追跡し、それぞれを既知のベースラインと比較します。振り返りの行動は完了まで追跡され、残業や燃え尽きのような持続可能なペースのシグナルが監視され、ベロシティが生産性の目標として使われることはありません。実行か中止かの決定は、意見ではなくこの証拠に基づきます。
レベル5、オーケストレーション。 適応型のデリバリーは、組織全体で事業とリスクの計画と統合されています。アウトカム(OKR)が資金と周期を駆動し、低依存のチーム設計(デスケーリング)が調整のオーバーヘッドを最小化し、ハイブリッドのガバナンスはデリバリーを遅くせずに監督を満たします。継続的な改善は儀式的ではなく文化的で、組織は証拠とリスクの状況が移るにつれて、ポートフォリオの範囲を日常的に見直し、チームを編成し直し、再均衡させます。

議論のためのアイデア

チームを12のアジャイルの原則に照らして採点してください。儀式ではアジャイルだが実質ではない所はどこですか。
チームでベロシティは予測として使われていますか、目標として使われていますか。そしてそれは行動に何をもたらしましたか。
XPのどの技術的な実践が欠けていて、その不在は欠陥や遅い変更としてどう現れていますか。
スケーリングの枠組みを採用する前に、代わりにチーム間の依存関係を減らせませんか。
あなたの文脈では、各イテレーションで本物のユーザーへのアクセスを具体的に何が妨げていて、どう取り除けますか。
振り返りが実際に生んだ最後の具体的な変更は何でしたか。

要点

アジャイルは、儀式の集まりではなく、価値と原則の心構えです。枠組みは出発点であって、目標ではありません。
動くソフトウェアを頻繁に届け、変化を歓迎し、自己組織化するチームに権限を与えます。
技術的卓越性(XPの実践)は交渉の余地がない。 それなしの俊敏さは速い劣化になります。
慎重にスケールし、デスケーリングを好む。 調整の枠組みを加える前に依存関係を減らします。
企業/政府では、適応型のデリバリーとハイブリッドのガバナンスとアジャイル調達を組み合わせ、本物のユーザーへのアクセスのために戦います。
ROIは継続的なリスクの低減とより早い価値ですが、アジャイルが儀式ではなく本物の場合に限ります。1.4章、11.1章、11.2章、10.6章、11.3章を参照してください。

参考文献とさらなる読み物

Kent Beck et al., Manifesto for Agile Software Development and its twelve principles (agilemanifesto.org, 2001).
Ken Schwaber and Jeff Sutherland, The Scrum Guide.
Kent Beck, Extreme Programming Explained: Embrace Change.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
Mike Cohn, User Stories Applied and Succeeding with Agile.
Jeff Patton, User Story Mapping.
Stephen Denning, The Age of Agile.
Matthew Skelton and Manuel Pais, Team Topologies (team design and descaling).
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (evidence for agile/DevOps practices).
U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.