製品の担当者とチーム

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

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

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

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

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

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

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

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

アマゾンの創設者であるジェフ・ベゾスは、 2つのピザのルール会議とチームの両方に。つまり、それぞれの人は、2つのピザが昼食を食べられるのと同じくらいの人数でなければなりません。

スクラムチームのための2つのピザのルール

ザ・スクラムガイド実際にスプリントバックログを実行している3〜9人のチームメンバーがいることをお勧めします。つまり、どちらかがスプリントバックログアイテムを実装していない限り、製品の所有者またはスクラムマスターを合計に含めることはありません。

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

チームメンバー間のリンクの数

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

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

デイリースクラム

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

コミュニケーションデザインvsグラフィックデザイン

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

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

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

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

回顧展

ふりかえりの間に、チームメンバーは議論や対立を解決し、作業プロセスを改善する方法を考え出すことができます。回顧展は、私たちに妥協の芸術を教えてくれます。それは、私たちが異なる当事者間の共通の基盤を探求するようにするからです。チームは、メンバーが彼らの違いについて妥協することをいとわないのと同じくらい強力です。

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

チームを分割する方法

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

チームを分割する際の考慮事項

チーム士気

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

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

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

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

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

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

チームが分割されている場合、自然な問題は、チームが同じバックログで作業する必要があるのか、それとも別々のバックログを持つべきかということです。私たちは見ることができますスケーリングされたアジャイルフレームワークガイダンスのため。

[メール保護]

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

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

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

大規模スクラム（LeSS）

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