スクラムオブスクラム

「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」のプラクティスの一つにスクラムオブスクラムがある。
考えたことをメモ。

【元ネタ】
「塹壕よりScrumとXP」

大規模プロジェクトで複数の開発チームがScrumをベースにアジャイル開発していたとする。
その場合に注意すべき点は何だろうか？

「アジャイル開発のスケールアップ」という従来から長く指摘され続けた問題に対し、その解決のキーワードとなる概念は、アジャイルリリーストレインとスクラムオブスクラム。

まず、「アジャイルリリーストレイン」とは、複数の電車が同時刻に発車/到着するように、複数の開発チームのスプリントを同期させること。
「塹壕よりScrumとXP」では、スプリントを同期させる理由として、各チームの編成を行うタイミングが各チームのスプリントの間であること、スプリントを同期しているから他チームとスプリント計画ミーティングを一緒に実施出来ること、管理上のオーバーヘッドを減らせることの３つを指摘している。
これは重要な指摘だ。
何故なら、「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」にも書いているように、一つの開発チームのスプリントが遅れることによって、他のスプリントにも遅延が影響するからだ。
例えば、開発チームAがスプリントで作っているライブラリを他の開発チームが使う予定の場合、ライブラリの提供が遅れれば、他の開発チームにも悪影響を与えてしまう。
丁度、TOCの「作業が早く終わっても伝播しないが、遅延は伝播してしまう」言葉を思い出させる。

次に、「スクラムオブスクラム」とは、各チームのスクラムマスターが定期的に集まる課題管理会議。
「塹壕よりScrumとXP」では、Scrumマスタが集まる定期的なミーティングであり、自身のチームの進捗や問題点を他チームのScrumマスタと共有して議論する場だ。
この会議では、チームリードと呼ばれる人がいて、Scrumマスタの１個格上のリーダーが議論をコントロールする。
スクラムオブスクラムが必要な理由は、一つのチームで解決できない問題を全チームが共有して、解決する方向へ持って行くことだ。
例えば、他チームが作るライブラリを早く提供して欲しい、とか、自チームは技術ノウハウが少ないので他チームのメンバーにヘルプで来て欲しい、とか、自チームの課題が実は他チームのスプリントに影響する、とか、他チームと調整しなければ自チームの進捗が遅れる状況はよくある。
だから、課題管理会議を定期的に開き、その場で各チームの課題を棚卸する時が多いだろうと思う。

「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」では、大規模なアジャイル開発チームをアジャイルコンポーネントチーム・スクラムオブスクラム・ステアリングコミッティーの３つの階層に分けて編成することを推奨している。
最終的にはこのようなチーム構造になるだろうと思う。

同様の概念は、PMBOKのCCB、ITILのCABに相当する。
PMBOKのCCBは変更管理会議と呼ばれ、プロジェクトに発生する変更作業に対し、承認作業を行う委員会。プロジェクトのスコープ、成果物、WBSの変更は、公式な手続きを踏むことによって、ステークホルダー間の合意を取り、変更のトレーサビリティを容易にするために行う。
ITILのCABは変更諮問委員会と呼ばれ、ITの運用保守において、変更管理プロセスで行われ、変更要求とその対策(開発、テスト、リリース手順など)、作業計画を承認して、レビューを行う。

スクラムオブスクラムのような中間的な組織が必要になってくるのは、アジャイル開発だからというわけではなく、PMBOKでもITILでもCMMIでも同様に発生してくる問題なのだ。
システム開発でも、非機能要件と言うものが出てくるのと同じ。
小規模な開発なら無視できた非機能要件も、たくさんのコンポーネントを結合して一つの有機的なシステムとして捉えようとすると、非機能要件と言う全体最適な観点で解決しなくてはならない問題が出てくるのと同じなのだ。

「アジャイル開発のスケールアップ」には、従来のアジャイル開発では解決できなかった問題の本質がいくつか隠されているように思う。
色々考えてみたい。