Dean Leffingwell らが取り組んでいる、Scaled Agile Framework (SAF) を用いてアジャイル開発をスケールさせる話。

SAF は以前から整備が進められていて、Agile2012 の会期にあわせて version1.0 がアナウンスされた。Dai が既に同セッションをレポートしているので、私の方は、Lean-Agile のマインドセットについて、いくつか取り上げたい。

• 参考：[8/15] Enterprise Agileを再考する – Agile2012 現地レポート(19)

スケーリングが直接関係しない方にも、Dean が挙げているマインドセットの From-To は参考になるところがあるかもしれない。

■Legacy MindsetからLean-Agileへ

Lean-Agileへ移行するために、8つのマインドセットの変化が挙げられている。

#1 多過ぎるプロジェクトから、かんばんによる WIP の制限へ

新しい要求を実現するために新しいプロジェクトを立てれば、小さなプロジェクトが数多くなり、管理のオーバーヘッドを招くことなる。チームはマルチタスクへと陥る。

これに対して、まずかんばんによって、WIP (仕掛り中の作業) を可視化し、チームが対応する WIP が増え過ぎないよう制限を行う。

#2 詳細なプロジェクト計画から、軽量なビジネスケースへ

あまりに詳細な計画を作ると、解決策を最初から (分かっていることが少ない状況から) 規定することにも繋がりかねない。ゆえに、計画を最低限必要な分まで軽量化せよ、という原則。

Lightweight Business Cases の具体的な内容が想像できなかったため、Dean の他の発表資料を参照したところ、以下のような特徴を持つもののようだ。

• 1〜2ページの、詳し過ぎないドキュメント
• 必要なイテレーションを回すだけの資金を得るためのもの
• 進捗がよくない場合、キャンセルできる

イメージ的には、Lean Startup で言う Pivot ができるような計画とマインドセットというところだろうか。

#3 年次予算から、IFMへ

年次で資金調達し予算を組むやり方ではなく、MMF (Minimum Marketable Features) 単位でリターンと予算管理を行い、ROI の最適化を図る。時間をかけて ROI を予測し、遠いところの着地点を見込んだところで作るものを変えていく開発では、期待する ROI も変わっていくことになる。資金調達もアジャイルに適応する。

IFM については『Software by Numbers』で紹介されている。

#5 WBS から、アジャイルな見積りと計画づくりへ

WBS は、タスクをできる限り細分化し、全てを洗い出した上で見積りをする、言わずと知れた特徴を持つ。

一方、SAF のアジャイルな見積りと計画作りでは、エピック、フィーチャー、ストーリーをそれぞれのバックログで管理する。バックログで管理するということは、必要なときに必要な分だけ見積りを行い、状況に応じて順序付けを変更するということだ。

エピックを構成するものがフィーチャー群、フィーチャーを構成するものがストーリー群、という3段構成になる。

1. エピックは、ビジネスまたは技術上必要とされる、最も粒度が大きい要求として定義される。
2. フィーチャーは、エピックを実現するための単位であり、マーケットやプロダクトにとって意味のあるものとして定義される。すなわち、リリース計画はこの単位で検討する。
3. ストーリーは、要求を表現するものとして最小の単位となる。

ストーリーだけでは、開発を行う単位として適切でも、ビジネス上の戦略的な判断 (例えば、マーケットにいつどのベネフィットを提供するかという判断) を行うには、粒度が小さすぎる。SAFは、要求の3段構成、3種類のバックログで実現することが狙いだ。

WBS の場合、最初のタスクばらしと見積りが、その後の計画実行を定めることとなり、これで顧客やビジネスオーナーとコミットメントすると、実績を計画に合わせようとする力が働く。あとで無駄なタスク、あるいは必要なタスクが見つかったとしても、全体としての計画変更が働きにくくなる。であるから、アジャイルな見積りと計画づくりに移行せよ、というわけである。(※注)

#7 PMBOK から、アジャイルプロジェクトマネジメントへ

• WBS から、ベロシティに基づいた見積りへ。
• ガントチャートスケジュールから、イテレーション計画へ。
• 進捗報告から、リリース/イテレーションレビュー、ふりかえりへ。

#8 ウォーターフォール型のマイルストーン管理から、ファクトベースのガバナンスへ

計画に事実を合わせるのではなく、事実に基づいて計画を行う。

※注：
実際のところ、WBS が全て悪いというわけではない。アジャイルな開発であっても、WBS は必要な作業や観点が足りているかのチェックリストにはなる。ただし、WBS で計画の管理はしない。