複数チームでスクラムを実践する際の注意点
最近徐々にですが、日本のソフトウェア開発においても、アジャイル開発が採用されることが増えてきました。 2018年のAgile Japanは（私は参加しませんでしたが）参加者400名ほどのうち、250名ほどが新規参加者だったようです。
Agile Japanは日本の大手メーカーも参加するようなイベントになっています。 アジャイル開発が注目されつつある、ということなのでしょうか。
アジャイル開発で最もよく活用されているのが、スクラムです。6～7割。
http://www.agile247.pl/wp-content/uploads/2017/04/versionone-11th-annual-state-of-agile-report.pdf
1チームでのスクラムはうまくいくけど、複数チームになるとうまくいかなくなる、ということがあります。 これだからアジャイル開発は…と言われそうですが、アジャイルは大規模でもスケールしますし、組織や会社を変えていくチャンスとなります。
１チームでのスクラムを実践し、うまくいったのでスケールさせたい、複数チームでスクラムを行いたいと言った際の注意点をまとめます。 （『ドキュメンテーションをしっかりする』、とかじゃないからご心配なく！） 前提の確認ですが、ここで言う『複数チーム』は、2～8チームを想定しています。開発人数は合計で10～70人程度。 （それ以上になってくるとプロダクトバックログの扱いが変わってきます） 注意事項は7つです。
- 1人のPO。
- 1つのプロダクトバックログ。
- ユーザ体験ベースのプロダクトバックログアイテム
- スプリントの期間を（なるべく）各チーム同一にする。
- 各チームのスクラムのイベントは同じ時間に実施する。(振り返り・朝会は除く)
- スプリントバックログはチーム毎に作成する。
- スプリントレビューは全員で行う。
それぞれ見ていきましょう。
1人のPO。
プロダクトオーナーは1人です。チーム数が多くなったからといってプロダクトオーナーが増える訳ではありません。 1プロダクト、1プロダクトオーナー。これは揺るぎないです。 もし複数人になってしまった場合、優先順位付け時に混乱が生じる可能性が高まります。 『決定』の迅速性も失われます。プロダクトオーナー全員の予定をあわせる必要が出てきます。 大きなプロダクトを作っているプロダクトオーナーだから非常に忙しいと思います。 それをチームとスクラムマスターでサポートしましょう。プロダクトオーナーは、プロダクトに関する『最終』意思決定者です。 チームは、プロダクトオーナーが迅速に決定ができるようにサポートをします。 複数案あったとして、どんなメリット・デメリットがあるのか、技術的な視点だけではく、マーケットやコストなど様々な視点で土俵に載せましょう。 そうしないとプロダクトオーナーは『迅速に』『最終』決定できないかもしれません。 あくまで『最終』です。逆にいうと、決定に至る過程からプロダクトオーナーは介入すべきではないかもしれません。 そして、忙しいんだから敢えて、どんどん密にプロダクトオーナーと連携しましょう。 忙しいと声をかけづらくなるというのはわかります。プロダクトオーナーもそれに応えるべきです。 スクラムマスターは、プロダクトオーナーが忙しいのであれば、忙しさを除去できるために何かできることがないかを検討します。 プロダクトオーナーが行っている意思決定の種類を分析し、可能であれば、チームにより権限を移譲します。 また、プロダクトオーナーとチームがより密に連携できるような場作りも大切な仕事です。 プロダクトオーナを複数人にすることはお薦めできません。
1つのプロダクトバックログ。
プロダクトバックログが複数あると、一意な優先順位がつけられません。 一意な優先順位がつけられないと、チームが何に注力するべきかがわからなくなります。 チーム毎にプロダクトバックログが存在すると、各チームがそれぞれの目標に向かって進むことになります。 結局全体性が損なわれます。チームをまたいだ助け合いもしづらくなります。
ユーザ体験ベースのプロダクトバックログアイテム。
プロダクトバックログが、仮説検証型になっているかどうか、それがユーザ体験に基づいているかどうかがキモになります。 INVESTを意識して。 これが一番むずかしいかも。 INVESTは以下の記事を参考に。
スプリントの期間を（なるべく）各チーム同一にする。
以下のような状態を避けようということです。
チーム名 スプリント期間 Aチーム 2週間 Bチーム 3週間 Cチーム 4週間
この場合、最悪なのは、AチームとBチームのスプリントレビューで顔をあわせる機会が6週間に1回になってしまうことです。 複数チームの場合、どれだけコミュニケーションの密度を増やせるかが鍵となります。 Bチームが1週間スプリントになった場合は、AとBは2週間で同期が取れますが、Cチームは以前4週間またなくてはなりません。 キツイです。疎遠となります。 経験的には、苦しくてもスプリント期間は1週間か2週間が良いと思います。集中力が続くプランニングしきれる範囲となります。
チーム名 スプリント期間 Aチーム 1週間 Bチーム 1週間 Cチーム 2週間
本当は全チーム同一期間が良いとは思いますが、上記も許容できるかもしれません。
各チームのスクラムのイベントは同じ時間に実施する。(振り返り・朝会は除く)
振り返りと朝会はチームのためのものですので、チーム毎に時間を決めて頂いて構いません。 スプリントプランニング、プロダクトバックログリファインメント、スプリントレビューは各チーム同じ時間にやることが望ましいです。 なぜなら、チームをまたがる相談事項というものがでてきた際に、全チームがプランニングやリファインメントをしていれば非常に聞きやすくなりますし、 複数人同士での議論にも発展させやすいです。 これが時間がバラバラだと、会議招集をする必要が生じたり、会議の時間をとったりと、会議が増えていきます。 チーム間の壁って、スクラムだとしても出てきてしまいます。それを出さないようにする工夫は必要ですね。 5.スプリントバックログはチーム毎に作成する。 これはあまり間違わないと思いますが、念の為出しておきました。 チーム毎に、このスプリントで実施するプロダクトバックログ・アイテムを取ってきて、チーム毎にプランニングします。 当然、スプリントバックログはチーム毎に作成されます。
スプリントレビューは全員で行う。
スプリントレビューは全員で行い、様々な知見をプロダクトに反映させます。 プロダクトオーナーとチームだけではなく、ステークホルダーも含めて行いたいところです。 人数が多くなると会議形式だと非効率・かつ眠くなる・内職が多くなるので、なるべくワークショップ化しましょう。 LeSSでは『バザール』という形式をとって、見本市のようなやり方でスプリントレビューを行う手法が紹介されています。
Sprint Review - Large Scale Scrum (LeSS)
イメージはこんな感じ。 www.safaribooksonline.com
以上、複数チームでスクラムを実践する際の注意点を記載してみました。 可能であれば、Large Scale Scrum (LeSS) などの大規模スクラムのフレームワークを守破離の『守』として活用したほうがいいと思います。 次回は、LeSSを活用する上での注意点をまとめます。
