組織規模でアジャイルを採用している企業は，時としてアジャイルプラクティスの適用範囲を拡大する必要に迫られる。そのような場合には，複数の相互依存的なチームを組織するのが一般的な方法だ。チーム間のコラボレーションの実現を通じて，企業全体が同じやり方でアジャイルプラクティスを実践する方法を探すのだ。
Frank Langeveld氏がAgile Methods in the Finance Sector and Complex Environmentカンファレンスで行った30分のセッションでは，企業におけるアジャイルのスケーリングについて，参加者の間で経験や意見が交わされた。セッションはまず，アジャイルのスケーリングに関する実践経験の発表を希望する参加者に対して，起立を求めることから始まった。４人が立ち上がると，氏は彼らひとりひとりのプラクティスについて30秒間で説明するように求め，それらをフリップに書き留めた。プラクティスがわずか４つだったので，氏は各発表者に対して，プラクティスの説明と質疑応答の時間として５分間割り当てることにした。質問はプラクティスの明確化を目的とするものに限定した上で，ごく短時間に留めた。プラクティスの有効性に関する議論が起きた場合は，セッションリーダが停止することにした。
発表された４つのプラクティスは次のものだ：
- リスク値ライフサイクル
- ユースケースモデリング
- 2層プロジェクト構造
- ベストプラクティスの組み合わせ
以下は発表された各プラクティスの要約である：
プラクティス１: リスク値ライフサイクル(Risk-Value Lifecycle)は，Rational Unified Processで提唱されたリスク軽減手法だ。アジャイルプロジェクトにも適用可能なこの手法は，Eclipse Practiceとして知られている。プロジェクト開始における最大のリスクは，多くの場合において，すべての利害関係者の関与のもとに判断する必要がある。したがって(方向付け(inception)フェーズにおける)最初のイテレーションの中心は，問題解決において利害関係者すべての同意を得ることに置かれるべきだ。十分な関与が得られなければ，彼らの問題を解決し得るソリューションの提供は望めない。推敲(elaboration)フェーズのイテレーションではプロダクトの完成保証に，続く作成(construction)フェーズではプロダクトにおける要件機能の実現に，それぞれ重点を置く必要がある。さらに移行(transition)フェーズでは，ユーザに対するプロダクトの可用性保証がリスク管理の中心になる。すなわちリスク値ライフサイクルとは，プロジェクトのライフサイクルを通じた価値提供において発生する，さまざまなリスクの管理を支援するものなのだ。
プラクティス２: ユースケースモデリング(Use Case Modeling)は，アジャイルプロジェクトの要件管理をスケーリングするプラクティスとして利用することができる。ユーザストーリは仕様決定時には有効だが，システムのコンテキストの資料化や抽象性を扱う場合は役に立たない。ここはユースケースが真価を発揮する領域なのだ。ユースケース内におけるユーザストーリを捕捉することにより，ユーザストーリ間の関係を示すことができる。企業レベルのビジネスプロセスやビジネスルールにユーザストーリをマッチさせる上でも，ユースケースモデリングは効果的な手法だ。
プラクティス３: ２層プロジェクト構造(Two Layer Project Structure)は，PMO(Project Management Office)においてウォーターフォールとアジャイルの両方，さらには他の形式のプロジェクトの管理も可能にする。このプロジェクト構造は，プロジェクト管理レイヤと実行レイヤとから構成される。プロジェクト管理レイヤは，異なるプロジェクト形式に対して共通使用されることにより，関係者に対する同一形式の報告を可能にする。一方でプロジェクトマネージャには，自身のプロジェクトを管理しやすい方法に実行レイヤを定義する自由が与えられている。アジャイルのイテレーション，複数のプロダクトや大規模プロダクトのパーツを単一プロジェクト管理するためのマルチトラック，ウォーターフォールのフェーズなどが考えられるものだ。一方のプロジェクト管理レイヤにも “定義”，”実行”，”クローズ” というフェーズが存在する。ウォーターフォールを例にすれば，設計作業を実行層に，実装と構築の作業をプロジェクト管理層の実行フェーズに割り当てらればよいだろう。スクラムを採用するプロジェクトならば，スプリントを実行フェーズとするかも知れない。アジャイルのイテレーションを実行するユーザインターフェースチームと，ウォーターフォールでプロセスを運用するバックエンドチーム，というように，異なる実行層を持つチーム同士でプロジェクトを構成することも可能だろう。
プラクティス４: アジャイルを企業レベルにスケールする場合，異なったメソッドのプラクティスを組み合わせて，その企業独自の大規模アジャイルアプローチを構築できる組織ならば好都合だろう。"何でも少しずつ(a bit of everything)” と呼ぶべきこの方法は，企業内で利用可能なものを基本的に使って，ベストプラクティスの再利用と組み合わせを行い，アジャイルをスケールする，というものだ。
読者の企業でアジャイルのスケールするならば，どの方法を選択するだろう？