規模が大きすぎる–最適なスクラムチームサイズガイド

公開: 2022-03-11

この記事の音声バージョンを聞く

あなたが小さなスタートアップで働いているか、大企業で新製品に取り組んでいるかにかかわらず、1つのチームにあまりにも多くの人がいるときにポイントに達する可能性があります。早い段階で兆候を特定することで、チームの最も非効率的な段階に到達するのを防ぐことができます。

すべての製品は異なり、それらに取り組んでいるチームも異なります。したがって、チームを分割するには、状況を反映したいくつかの決定を行う必要もあります。考慮すべき点は次のとおりです。

チームメイトがもはや一緒に働いていないときにノウハウの完全性を維持する方法
機能（フロントエンドチームとバックエンドチームなど）に沿って分割する必要がありますか？
新しいチームには個別のバックログが必要ですか？
製品管理チームはそれに応じて成長する必要がありますか？

いつ2番目のチームの作成を開始する必要がありますか？

チームの分割や新しいチームの追加について考え始める最も明白な兆候は、予算が増えたときです。これは、スタートアップへの新たな投資ラウンドや、企業における製品の新たな目標に発生する可能性があります。予算の増加が非常に大きく、チームが3倍以上に成長する場合は、ノウハウを配布するために現在のチームを分割する必要があるのは簡単です。ただし、予算の増加が段階的であり、最終的に数人の新しい人を名簿に追加する場合、決定はそれほど明確になりません。たとえば、チームを7人から11人に増やす計画がある場合、分割が必要ですか？アジャイルは小さなチームを促進しますが、プロセスやツールを介した個人や相互作用も促進します。 2つ以上のチームがあると、必然的に、同期して作業できるようになるプロセスが増えます。

専門家は何と言っていますか？

Amazonの創設者であるJeffBezosは、会議とチームの両方に2つのピザのルールを使用してきました。つまり、それぞれの人は、2つのピザが昼食を食べられるのと同じくらいの人数でなければなりません。

スクラムガイドでは、実際にスプリントバックログを実行しているチームメンバーを3〜9人にすることを提案しています。つまり、どちらかがスプリントバックログアイテムを実装していない限り、プロダクトオーナーまたはスクラムマスターを合計に含めないということです。

これらの数値は直感的に理解できるようですが、その背後にはいくつかの数学もあります。チームについて考えると、すべての人はノードのようであり、他のノードにリンクしています。これらは、チームメート間の対人関係です。彼らは友好的、競争的、意地悪、または思いやりのあることができます。二人の関係がどうであれ、それでも一人一人の精神的能力を必要とするつながりです。チームが成長するにつれて、これらのリンクの数は直線的に増加しません。ノード間のリンクの式は\（n（n-1）/ 2 \）です。リンクの成長チャートは次のとおりです。

このグラフは、チームが大きすぎないときにチームが最も効率的に動作する理由を数学的な観点から明確に示しています。スクラムガイドによって提案された3〜9人のチームメンバーを採用すると、3〜36のリンクになります。 15人に成長した場合、100を超えるリンクがあります。このチームは、職務が非常に明確に定義されており、重複することはめったにない場合、または非公式のサブグループがいくつかある場合にのみ、効率的に運用できます。アジャイルの原則に基づいて作業する場合も、そうではなく、望ましいことでもありません。

チームが大きくなりすぎている兆候

デイリースクラム

デイリースタンドアップと呼ばれることもあるデイリースクラムは、スプリントの進捗状況と障害について話し合うためのチーム全体の集まりです。スクラムガイドは、これらの時間を15分に設定することを提案しており、これはチームサイズの優れたリトマス試験です。チームが15分のバーをオーバーランしていることに気づき始めた場合は、次の2つのいずれかを示している可能性があります。

毎日のスクラムは効率的ではありません。 人々はあまりにも多くの詳細に取り組んでいます。または、明確な発言順序がなく、チームメートが発言するのに時間がかかります。おそらく、プロダクトオーナーまたはスクラムマスターは、スプリントに関係のないさまざまな更新を提供する機会として毎日のスクラムを使用しています。
チームが大きすぎます。 毎日のスクラムが効率的であるにもかかわらず、それでも15分を超過している場合は、チームの人数が多すぎる可能性があります。また、人が取り込むことができる情報の量には制限があるため、人が興味を失っていることにも注意する必要があります。更新を提供する人が多すぎると、全員の進捗状況を追跡し、チームのステータスを理解することが難しくなります。。これにより、人々は内向きになり、他の人を助ける機会を探すのではなく、自分の進歩だけを振り返ることができます。

グルーミングとスプリントの計画

グルーミングとスプリント計画はどちらも、ユーザーストーリーを分類し、配信時間またはサイズを見積もることに関連するアクティビティです。より多くの人がいるとチームはより良い決定に到達するのに役立ちますが、人が多すぎるとチームが行き詰まる可能性があります。同じタスクを実行するには常にさまざまな方法があり、チーム内の人数に応じて、それぞれの側の議論の数が増えます。

毎日のスクラムと同様に、非効率的な計画セッションとチームが大きすぎることを混同しないでください。最終的には、スクラムセレモニーを効率的かつ効果的にすることがスクラムマスターの仕事です。

ふりかえり

ふりかえりの中で、チームメンバーは議論や対立を解決し、作業プロセスを改善する方法を考え出すことができます。レトロスペクティブは、さまざまな当事者間の共通点を探求するための妥協の芸術を教えてくれます。チームは、メンバーが彼らの違いについて妥協することをいとわないのと同じくらい強力です。

ただし、スプリント計画と同様に、チームメンバーが多すぎると、リンクが多すぎて、すべてが潜在的な競合ポイントになります。振り返りの間に、ますます一般的でない根拠を見つけているかどうかに気づき始めてください。チームが大きすぎて、分割することでメリットが得られることを示している可能性があります。

チームを分割する方法

一見すると、チームの分割は比較的簡単な作業です。チームメンバーを2つのグループに分け、それぞれが同じように経験豊富な人々を持っていることを確認し、新しいチームの目標を定義します。ただし、新しいチームの将来の成功に大きな影響を与える可能性のある考慮事項がかなりあります。

チーム士気

おそらく覚えておくべき最も重要なことの1つは、チームの士気です。結局のところ、新しい作曲で作業しなければならないのはチームの人々です。チームがアジャイルの原則に関して成熟している場合、チームは自分たちで分割を行うことができるはずです。チームメンバーは内部の関係を最もよく知っているため、これは最も望ましい結果です。誰が誰と最もよく連携し、誰が別々のチームに所属することで利益を得ることができるかです。

クロスファンクショナルチーム

スクラムは、「製品の増分を作成するために必要なチームとしてのすべてのスキルを備えた」クロスファンクショナルチームを促進します。これは、2つ以上のチームにスケーリングする場合にも当てはまります。多くの開発者にとって、特にアジャイルに不慣れな場合、自然な傾向は技術的な線と一緒に考えることです。たとえば、チームは多くの場合、バックエンドチームとフロントエンドチームに分割したいと考えています。これはまれに意味があるかもしれませんが、製品マネージャーとして、ほとんどの場合、これに反対するようアドバイスする必要があります。フロントエンダーでいっぱいのチームは、自分たちで製品の増分を提供することはできず、当然、彼らを結び付けるものである技術的能力についてもっと考え始めるでしょう。代わりに、彼らは顧客と彼らのニーズを満たす方法に焦点を合わせる必要があります。

もう1つの興味深い考慮事項は、チーム内の開発以外の役割です。さまざまな状況で、チームにはデザイナー、ビジネスアナリスト、またはQAスペシャリストが含まれる場合があります。チームを分割すると、特に多くの新しい人を採用していない場合は、これらの役割をどうするかというジレンマが発生します。彼らはチーム間で時間を分割する必要がありますか？ 1つのチームだけに専念する新しい人を雇うべきですか？彼らは開発チームと協力するべきですか、それとも製品チームの一員になるべきですか？

各製品は非常に異なるため、これについての良い単一のアドバイスは実際にはありません。これらの決定は、途中でコースを修正する必要があるかもしれないことを念頭に置いて、チームと一緒に行うのが最善です。

チームには個別のバックログが必要ですか？

チームが分割されている場合、自然な問題は、チームが同じバックログで作業する必要があるのか、それとも別々のバックログを持つべきかということです。ガイダンスとして、ScaledAgileFrameworkを参照できます。

Scrum @ Scale

Scrum @ Scaleは、スクラムガイドの作成者によって開発された方法論です。 Scrum @ Scaleはあまり規範的ではなく、製品のバックログを処理する方法を具体的に概説していません。ただし、次の2つの点に注意してください。

チームレベルのプロセスは、スクラムガイドに記載されているものと同じです。
プロダクトオーナーはプロダクトオーナーチームを形成し、そこで単一の統合されたバックログを作成します。これは、作業の重複を回避し、社内の可視性を高めるために行われます。同時に、チームには、統合されたバックログからアイテムをフィードする個別のバックログがあります。

つまり、本質的に、Scrum @ Scaleは、それぞれのPOとバックログを使用して新しいチームをイメージします。チーム間の作業を調整するために、いくつかの追加の構造を追加するだけです。 Scrum @ Scaleは、数、数十、または数百のチームで最適に機能しますが、2つのチームで作業している場合でも、いくつかの貴重な洞察を提供できます。

大規模スクラム（LeSS）

LeSSは、製品バックログへの興味深いアプローチを促進します。 LeSSでは、プロダクトオーナーは2〜8チームで作業します。 1つのPOが非常に多くのチームと連携することは不可能に思えるかもしれません。 LeSSの哲学は、POが抽象的なレベルで機能し、製品バックログアイテムの改良の責任をチームに委任することです。この場合、クロスファンクショナル開発チームは、製品の増分を提供できるようにするために、ビジネスドメインの知識も含める必要があります。 LeSSでは、バックログは1つだけです。

結論

チームが成長するにつれて、特に次の場合に、チームが大きくなりすぎている兆候に気づき始める可能性があります。

毎日のスクラム。 毎日のスクラム中に15分の時間枠を超過していて、人々が興味を失い始めているのを確認した場合。
スプリント計画。 スプリント計画中にデッドロックに陥った場合は、ますます頻繁になります。
ふりかえり。 振り返りの間に妥協点に到達することが難しくなっていることに気づき始めたら。

これらはすべて、チームを分割する必要があるかもしれないという事実を示しています。チームを分割することは一見簡単な作業のように見えますが、それはまた永続的な結果をもたらし、すべての製品マネージャーはそうするときに考慮すべきいくつかのことを持っています：

チームの士気。 理想的には、廃棄された良好な関係の数を最小限に抑えるために、チームにどのように分割するかを決定させる必要があります。
クロスファンクショナルチーム。 チームは、製品の増分を作成するために必要なすべてのスキルを持っている必要があります。
製品のバックログ。 チームに個別のバックログを作成するか、単一の統合バックログを作成するかを決定します。

2つ以上のチームを追跡するには、優先順位を付ける必要があります。効果的な製品マネージャーは、新しいチームをどのように最新の状態に保つかを計画する必要があります。

会議に優先順位を付けます。 どのアジャイルセレモニーがあなたの時間の価値があり、どれが無視できるかを考えてください。
スクラムマスターと交流する。 チームプロキシとしてスクラムマスターを使用し、そこから情報を収集します。
製品チームを拡大します。 あなたと一緒に働く人々を追加し、毎日の反復的なタスクを支援するか、ユーザー調査と市場分析を実施します。

これらの提案を利用することで、クリーンなチーム分割が可能になるはずです。チームが成長し続け、将来さらにチームを追加する場合は、Scaled Agile Frameworkについて読む必要があります。これは、大規模なアジャイルの構造とプロセスの提案を提供します。