Agile を scale するとは、heavyweight で top-down な control を再導入せずに、1 つの product に取り組む多くのチームを調整することです。中心的な challenge は、autonomy と速い feedback を保ちながら、shared goals に alignment し、dependency を管理することです。いくつかの framework がこれに異なる方法で対応します。
Agile を scale するとは、heavyweight で top-down な control を再導入せずに、1 つの product に取り組む多くのチームを調整することです。中心的な challenge は、autonomy と速い feedback を保ちながら、shared goals に alignment し、dependency を管理することです。いくつかの framework がこれに異なる方法で対応します。
| Framework | Idea | Trade-off |
|---|
| SAFe | layered structure, Agile Release Trains, PI planning | alignment は強いが、heavy/prescriptive に感じることがある |
| LeSS | 最小限の追加 process で Scrum を scale する | lightweight だが、本当の org change を要求する |
| Spotify model | squads, tribes, chapters, guilds | cultural pattern であり、copy-paste framework ではない |
COMMON GOALS WHEN SCALING
- shared product vision/roadmap に teams を align する
- cross-team dependencies を visible かつ managed にする
- 各 team を可能な限り autonomous に保つ
- coordination が増えても fast feedback を維持する
1 つの platform に取り組む 8 チームが、objective を揃え dependency を表面化するために quarterly big-room planning event を導入しつつ、各チームは自分たちの Sprint cadence と backlog を維持します。
scale を誤ると、Agile が取り除くはずだった bureaucracy を再現し、変革を正当化した speed を殺します。
適切な framework は context に依存します。skill は、チーム間 dependency の実際の level に coordination overhead を合わせることです。