はじめに
わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。
興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。
スケーリング・アジャイル
これまで、最大9人のチームメンバーでスクラムチームを運営する方法について説明しました。しかし、
- チームの規模がそれ以上になったら、どうすればいいのでしょうか？
- あるいは、製品やソリューションの規模が大きく、複数のチームで作業を行う必要がある場合はどうすればよいのでしょうか?
今回、大規模な取り組みやソリューションのニーズに対応するために、アジャイルアプローチを拡張するフレームワークを探ります。
Scaled Agile Framework (SAFe)
最も人気のあるスケーリングフレームワークは、スケーリングアジャイルフレームワーク（SAFe）である。SAFeは、リーン-アジャイルのスケーリングフレームワークであり、カンバン、スクラム、エクストリームプログラミング（XP）、DevOps、およびデザイン思考の方法論の概念に大きく依存している。
SAFeは、価値を提供するという目標を何よりも優先します。SAFeの最初の原則は、"経済的な視点を持つ "ことです。このフレームワークは、すべての作業とチームを、例えば販売などの価値の流れに基づいて「アジャイルリリース列車」に組織化する。SAFeフレームワークは成熟しており、SAFeを使用するためのすべての要素に関する詳細なガイダンスを提供していますが、いくつかの要素は他の要素よりも重要です。アジリティを維持するために、マニフェストのアジャイルの原則と価値観に必ず戻って確認すること。
SAFeは、多くのアジャイルプラクティスと同様に、一連のコアバリューを基盤としています。
- アライメント: 組織の全レベルでSAFe活動の計画と実行を同期させる。
- 組み込みの品質: ソリューション開発の全段階に品質を組み込む。
- 透明性: 実行活動をすべてのレベルで可視化し、チーム間および組織全体の信頼を構築する。
- プログラムの実行: システムおよびビジネス成果を重視する
- リーダーシップ: SAFeの価値観と原則を模範とする。
SAFeのコアバリューの詳細については、この記事をお読みください。
Scrum of Scrums
スクラム・オブ・スクラムは、同じプロジェクトやソリューションに取り組んでいる複数の小規模なスクラムチームの作業を統合するための手法です。チーム間の調整は、各チームからの成果物をより大きな、まとまった成果物に統合できるようにするために重要です。
スクラム・オブ・スクラムには、以下の要素が含まれます。
- 少なくとも12人以上の集団 、あるいは5〜10人程度のスクラムチームに分けられる。
-
スクラム・オブ・スクラム・ミーティング、週1回、週2回、または毎日開催される。これらのミーティングは、デイリースクラムミーティングと同じ形式を取りますが、 スクラムチームに焦点 を当てます。これらのミーティングでは、次のような質問について話し合います。
- 昨日、チームは何をしたのか？
- もしあれば、チームに悪影響を与えるような問題は発生したか
- ？あなたのチームは、再び会うまでに何を達成したいですか？
- あなたのチームは、何かタスクを進めるのを妨げられていますか？"
- スクラム・オブ・スクラム・ミーティングに参加する各チームのスクラム・マスターまたは指定された「大使」と、複数のチームにわたるスクラム・プロセス全体に焦点を当てるスクラム・オブ・スクラム・マスター
- スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブミーティング
これらの非常に基本的なガイドラインを越えて、スクラム・オブ・スクラムを実装するための公式なフレームワークや方法論は存在しません。
スクラム・オブ・スクラムは、チームがスクラムを十分に理解し、自分たちの仕事のやり方にスケーリング原則を適用できることを前提としている。この知識に基づいて、同じ製品に取り組む複数のチームを調整するための独自のアプローチを設計し、反復します。
他にも次のようなフレームワークが存在します。
- Large-Scale Scrum (LeSS)
- Disciplined Agile Delivery (DAD)
- The Spotify Model
スケーリング・アジャイルのベストプラクティス
どのフレームワークを選択するにしても、いくつかの基本原則を心に留めておくことが重要である。
- SAFe、Scrum of Scrumsなどのスケーリングモデルは、一般的なフレームワークとして扱い、取扱説明書ではありません。
- 状況が異なれば、異なるソリューションが必要になります。アジャイルマニフェストの原則と価値を適用する限り、複数のフレームワークの要素を混ぜて使ってもかまいません。
- アジャイルの経験がないのに規模を拡大しようとしないでください 。ウォーターフォールからスケールしたアジャイルに直行するのは、知識のあるガイドなしには危険です。
- そして最も重要なことは、必要でない場合はスケーリングしない ことです。チームが大きくなればなるほど、プロジェクトはより複雑で困難になります。
Google SRE（Site Reliability Engineer）のコメント
基本的に、アジャイルとDevOpsは複雑な問題を解決するためのものです。大きな問題を解決するには、それを 小さなチャンクに分割し、どのチャンクを最初に提供すれば、得られる情報が最大になり、大きな問題の解決に役立つかを検討し、それを反復して継続すること である。
そうすれば、ユーザーの生活をより良くし、彼らの仕事をより素晴らしくするような方法で問題を解決する方法をより良く発見できるだけでなく、その方法、例えば どのプロセスが最も効果的に機能するかなどを発見 することができます。
ここに解決したいユーザーの問題があります。それをどう実現するか。この10年間で私が見てきたのは、このプロセスのフロントエンド、つまり企画プロセスをチームに取り入れることです。リリースや運用の部分をチームに取り込み、それを非常に徹底して ユーザー中心 にするのです。どうすれば、すべてをユーザー中心にして、それをチームに取り込むことができるのか。これが大きな変革であり、それが完了するのはまだまだ先の話だと思います。
アジャイルで成功するためのもう1つの要素は、特に新人であれば、大量のミスを犯すことになるでしょう。それはそれでいいんです。 失敗をしないことには、学ぶことはできません 。まず第一に、一回目や二回目、あるいはこれまで通りにうまくいくと期待しないことです。私は今でもよく失敗をします。私は、15年間、世界中のさまざまな種類の組織でアジャイルに関わり、実際に多くの進化を見てきました。