チームを一気にスケールさせるためのアジャイルプロジェクトマネジメント
キーノートでは仕事の未来と健康的なチーム作りが紹介されました。続いて参加した「Linear Scalability of Teams: The Holy Grail of Agile Project Management」は、スクラムの生みの親であるJeff Sutherland氏によるトークセッションです。
まずは、スクラムチームにおけるスケールとはなにか？ 開発に配置されるチームの数であることは間違いないでしょう。組織が大きくなると、チーム数もどんどん増えていきます。しかしながら、人数の増加が生産性向上につながるとは限りません。
そのため、スケール以外の軸であるDistribution（チームの分散性）やSaturation（アジャイル開発の浸透性）も同時に考慮する必要があります。そして、この3軸が作り出す立方体がベロシティ（Velocity。生産性に近い意味）を指しています。スクラムのプロセスを活用して価値を提供するためには、このベロシティがとても重要になります。
セッションでは日本でもなじみ深いAmazonの事例が紹介されていました。データを見るととても大規模なスクラムになっていることが分かります。
- 3300のスクラムチーム
- 少人数のチーム構成となっており、それぞれがマイクロサービスを担当する
- コミュニケーションを取らなくてもすむように、権限をチームに依存した摩擦の少ない構成
そして、組織をスケールするためには、成長に必要な部分は官僚的にならざるを得ず、以下のように階層的に管理する必要性があると氏は説きます。
- Executive Action Team
- Enterprise MetaScrum
- Scrum of Scrum
Executive Action Teamは、Transformation Backlogのオーナーとなり、組織がスクラムを活用できるようになるためにトップレベルで支援するチームです。
Enterprise MetaScrumは、プロダクトオーナーレベルと、Executiveレベルで行われるバックログの整理整頓を指しています。
Scrum of Scrumは、複数のチームで1つのプロダクトをリリースしていく形です。それぞれのチームにはスクラムマスターが配置されており、互いに連携しながら1つのプロダクトを磨いていきます。
結果的に、アジャイルなプロジェクトの成功率は従来型のものと比べ倍近くまで高まるという報告も出ています。
一方で、スクラムのスケールが失敗する事例についての考察も紹介されていました。問題として顕著に現れるのが意思決定の遅延です。わずか数時間の意思決定の差で、プロジェクトの成功率はぐんとあがります。
スクラムでは、意思決定をチームレベルで行うため、この遅延をできるだけ少なくしようと努力します。特にプロダクトオーナーの素早い意思決定は成功の鍵になり、前述のEnterprise Action TeamやScrum of Scrumによって、問題や課題をすばやくとりのぞき、アジリティを高めていくのです。
