アジャイルのアプローチを組織に導入し組み込むのは、アジャイルプロジェクトそのものであるように扱う必要がある、とAndreas Schliep氏は言う。ScALeD(Scaled Agile and Lean Development)は、アジャイルの方法論やフレームワークをテストするための原則を提供する。氏はScALeDについて、“実際の実践者が主導する動きであり、組織を助け、アジャイルへの移行やスケールについてのバランスのとれた素晴らしいアプローチを見けられるようにする”と考えている。
Andreas氏はScALeDについて1月22日にブリュッセルで開催されるScaling Agile for the Enterprise 2015で話す予定。このイベントはAgile Consortium Belgiumが主催し、UNICOMが実行する。InfoQもこのイベントをニュースや記事で取り上げる予定だ。
InfoQは、氏にインタビューをしてアジャイルをスケールするときの陥穽について、ScALeDについて、ScALeDのAgility PathやLeSSやSAFeやDaDとの比較、継続的改善や振り返りについて話を聞いた。
InfoQ: アジャイルをスケールするときの陥穽について教えてください。
Andreas: アジャイルを押し進めるのは、困難を伴う危険なミッションです。多くの組織はこれを理解できていません。成功例を聞くとその"成功の秘訣"を自分の文脈に導入したがりますが、なぜそうしてもうまくいかないのかと悩みます。これはリーンの導入で起きたことと同じです。多くの企業がトヨタの生産システムを模倣しましたが、その原則を理解せず、価値へコミットしませんでした。リーンとアジャイルは同じではありません。しかし、概念の根本を共有しています。理解の不足は独自の文脈への移植を妨げます。とくに環境が頻繁に変わる場合はそうです。変化する文脈に素早く適応するの能力をアジャイルと呼びます。バズワードを追いかけるのも良いですが、意味は関知しないほうがいいでしょう。不安定化を促す要因は美しい構造を破壊してしまいます。
アジャイルになることに対する抵抗と理解が欠けているが故に生まれる、典型的なスケーリングの失敗は次のようなものがあります。
- プロセスのための役割分担: プロダクトオーナはプロダクトの本当の所有者ではない。スクラムマスタは自己組織化する組織が最大限成長するために働いているように見えない。単にプロジェクトマネージャが新しい名前になっただけ。
- 役割の"最適化": スケーリングが"補助的"な役割のコストを削減するための機会となる。1人のスクラムマスタで4つのチームを見る。リームのリーダーにプロダクトオーナの役割を任せる。
- リモート制御: スケーリングによって作業の文脈が分散することになる。ひとつのチームの異なるロケーションで複数のスクラムマスタやプロダクトオーナが働くようになる。プロダクトオーナとしてはこれでもうまくいくかもしれないが、スクラムマスタやアジャイルコーチはうまくいかない。
- 難しいポジション: スクラムのようなアジャイルの手法は組織の根本的な変更を要求する。これは不可能。あるいは、組織階層によって拒絶される。または、エンタープライズアーキテクトや、上級ビジネスアナリスト、リードセキュリティエキスパート、プロジェクトマネージャによって邪魔される。
- 間違った注力: アジャイルをスケールする、またはスケールされたアジャイルは可能である。しかし、本当の問題の解決策にならない可能性がある。多くの企業は、スケールダウンするか開発チームを構成し直すことで改善する。アジャイルな製品開発は正しい製品を開発し、顧客を満足させることであり、雑なアウトプットを生むことではない。
InfoQ: イベントでは、ScALeDについて話すようですね。簡単に説明していただけますか。
Andreas: まず、ScALeD – Scaled Agile and Lean Development –は、スケーリングフレームワークのひとつではありません。ScALeDは実際の実践者が主導する動きであり、組織を助け、アジャイルへの移行やスケールについてのバランスのとれた素晴らしいアプローチを見けられるようにします。リーンとアジャイルから着想を得て、原則によって押し進められ、さまざま実践やフレームワークによって完成されられます。私たちの主要なミッションは組織にとってアジリティがどのような意味を持つのかを把握することです。
ScALeDの中核には13の原則があり、5つの柱に構造化されています。ScALeDのアウトラインである5つの柱はリーンの価値に似ています。
- 興奮する顧客
- 幸せで生産的な従業員
- 世界的な最適化
- 支えとなるリーダーシップ
- 継続的な改善
これらの原則はリーン、アジャイル開発マニュフェスト、スクラム、システムシンキングを踏まえています。組織が何を生み出しているかに関わらず、どのくらい大きくても、これらの原則は与えられた環境で有効に働く必要があります。これらの原則を読んでも、スケーリングについては何も解りません。したがって、ScALeDはそれだけでは、20チームでプロダクトを作る方法について教えてくれません。しかし、採用した方法が原則を支持するか違反するかは確かめることができます。
InfoQ: アジャイルをスケールしようとする場合、継続的な改善を確かなものにするためには、どうすればいいでしょうか。
Andreas: アジャイルのプロセスは短いフィードバックのサイクルに依存します。プロダクト開発のイテレーションが不要でも、一定のリズムで点検と適応を繰り返すのがおすすめです。これは振り返りによって実現するのが普通です。ScALeDやその他のスケーリングフレームワークによれば、この改善サイクルはチームレベルに限定されません。設計図に従ってフレームワークを展開するのではなく、アジャイルの手法と組織を統合し、アジャイルプロジェクトのように扱うのです。アジャイルの組織的開発は次はもっと良い方法があるということを前提にしています。アジャイルの組織的開発には担当者が必要です。ペースと変化の強度に責任をもつプロダクトオーナが必要です。バックログは定期的に見直し、優先順位を考え直す必要があります。組織的開発チームは改善の選択肢や問題、インシデントに対処するため自己組織化しなければなりません。そして、より良い組織の製品を増やしていきます。
InfoQ: アジャイルをスケーリングするためのフレームワークはいくつかあります。Agility Path、LeSS、SAFe、DaDなどです。組織はどのフレームワークを導入するべきか、どうやって決めたらいいのでしょうか。
Andreas: このなかには大きな図版を描くのに最適なものがあります。ScALeD Big Pictureが白紙なのには理由があるのです。私たちは、まずは価値と原則を理解し、そして、フレームワークとプロセスを探すようにアドバイスします。これらのフレームワークには知恵と知識が詰まっていますが、買って導入すればそのまま使える"準備万端"なものではありません。George Box氏は"すべてのモデルは間違っているが使えるものもある"と言っています。これらのモデルはすべて便利です。DaDはソフトウエアの品質を強調しています。SAFeは伝統的な組織にとって魅力的です。というのは、異なる組織のモデルをすりあわせるのに便利だからです。Agility Pathは原理を大事にしており、継続的改善という視点から見ると強力です。LeSSはScALeDに似ています。Bas Vodde氏とCraig Larman氏はScALeDの基礎から着想を得ています。
しかし、これらのモデルは生きているアジャイルな組織のモデルです。生きている人間にとっての人体模型のようなものです。着想は得られますし、構造や解剖についても学べます。しかし、生きている器官についての知識がなければ、モデルから恩恵を受けられないでしょう。一方、実際の実験やSAFeからのステップアップからは多くのことを得られます。私たちはScALeDの原則をどの程度実現しているかをもとにして、フレームワークをを比較しています。これによって各フレームワークの強みと弱みを簡単に把握できるでしょう。例えば、この比較では継続的改善という点でDaDよりもAgility Pathを高く位置づけています。Agility Pathは継続的統合をアジャイルへの転換の開発サイクルとして基礎にしているからです。一方、DaDはチームレベルの振り返りを重視し、マネージャとメトリクスを頼りにします。
InfoQ: アジャイルをスケールする場合、どのように振り返りを活用すればいいでしょうか。
Andreas: 振り返りは成功するチームの重要な要素であり、組織全体の継続的な改善を実現します。振り返りを有効に活用するには。各レベルでスキルのある訓練されたファシリテータが必要です。エンタープライズアジャイルコーチや、CSCなどが、時々組織全体をしっかりと振り返るだけでは不十分です。Jimdoは制度として振り返りのファシリテーターを教育している組織の代表例です。プロセスに関わらず、各チームは振り返りを主導できる人を最低1人は抱えています。振り返りは組織の変化についてのバックログの基礎になります。理想的には、"組織的な受け入れテスト"を伴う、振り返りはしっかりと公式化された改善のストーリーになります。
私のビジョンは基本的なPDCAサイクルとして"振る舞い駆動組織的開発"を確立することです。チームは改善の提案を受けます。その提案はチームの振り返りで議論され、利害関係者、移行チームのメンバで議論されます。そして、明確な受け入れテストを伴った実行可能なアイテムへと昇華されるのです。変化は移行チームによって"開発"され、組織はデモを受けます。そして、新しい改善の機会を見つけるのです。このサイクルは2週間から4週間しかかかりません。デモの後、移行チームは自身の振り返りを行います。これは働き方のモデルは静的ではなく、アジャイルであり続けることを明確にするために重要です。予期しない変化に対応できるようにするためです。
Andreas氏はアジャイルとリーンのスケーリングについてもっと知りたい人のためにいくつか記事を紹介してくれた。