スクラム・オブ・スクラム - スケールアップの基盤となる最適なチーム開発

チーム開発とスクラム・オブ・スクラムの共通点は何か？それらはチームの成長と最適化を扱っている。基本的に、アジャイル手法を拡張する前に、チームは最適に開発されるべきだ。チームが最適に開発されるタイミングは、ここや私たちの ブログ記事  

スクラム・オブ・スクラムとは何か？

スクラム・オブ・スクラム（Scrums of Scrums）とは、スクラムを多くのチームや適切な場合にはトレインズ（Trains）に拡大する方法である。他の方法としては、例えば次のようなものがある。 セーフ, LeSS あるいはネクサスだ。

スクラム・オブ・スクラム スクラムチームのメンバー全員が共通の目標に向かって努力し、お互いを信頼し、尊重し、力を合わせれば、特に成功する。そのためには、事前にチーム開発をしておく必要がある。

という文章がある。 

「スプリントで重要な仕事をこなすには十分な大きさである。 

知っているかもしれない。では、規模を拡大する適切なタイミングはいつなのか？最適なチームサイズとは何なのか、チームを開発する際には何を考慮する必要があるのか。そのために推奨されるチーム開発はあるのだろうか？

最初にスクラム・オブ・スクラムの話をしよう。

ジェフ・サザーランドとケン・シュワバーは、複数のチームでアジャイルに仕事ができる方法を探していた。全員が単独で作業するのではなく、全員が協調して作業することが重要だった。これはアジャイル開発における画期的な出来事だった。ジェフ・サザーランドもこれについて本を書いている。 “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”2001年に登場した。 

Scrum of Scrums und die Skalierbarkeit agiler Methoden setzen sich seither mehr und mehr durch. Man kann aber sagen, dass die COVID-19 Pandemie wohl den größten Schub für die agile Entwicklung gegeben hat - zumindest für die Anwendung in anderen Bereichen als der Softwareentwicklung. Grundsätzlich kann man agile Methoden immer anwenden, wenn Anforderungen und Technologien komplex sind. Die ステイシー・マトリックス そして サイネフィン・フレームワーク それらを分類するのに役立つ。で スクラム@スケールガイド をクリックすると、スケーリングに関するすべての情報が得られる。

ヒントとして、個々のチームがうまく連携して機能しているときにのみ、規模を拡大すべきである。個々のチームレベルですでにスクラムに問題を抱えているのであれば、規模を拡大すべきではない。私のチーム開発の推奨はこちらだ：スケールを始める前に、まずチームを成長させ、その問題に対処する。

Übrigens, ein kurzer Hinweis im Kontext agile Transformation: Willst du sicher gehen, dass ihr aktuell die richtigen Prioritäten in eurer agilen Transformation setzt? 

Dann mach unseren Reifegrad-Check für eure agile Transformation - dauert nur 3 Minuten. Du bekommst sogar einen Benchmark auf Basis der über dreihundert anderen Teilnehmer*innen. Siehe Button 🙂

スクラム・オブ・スクラムの目的

スクラム・オブ・スクラムは、チーム内のアジリティから企業全体のアジリティに移行する際のスクラムの最初の論理的拡張である。スケーリングのための重要な前提条件は、適切なチーム構成である。以下の質問に答える必要がある： 

• チーム内で誰がどのポジションに就いているのか？
• 誰が誰と仕事をするのか？
• 誰が特によく調和するのか？
• 誰がどの役割を担っているのか？

私たちは、役割の明確化が非常に重要な役割を果たすことを発見した。ちなみに、チーム内にイノベーションを起こすためにどのようなレバーが使えるか知りたい場合は、こちらをチェックしてほしい。 ビデオ アン。また、チームが成長するためには、常に十分な時間とスペースが必要だ。ここでは、タックマンの チーム開発のフェーズ・モデル お互いを知るためだ： 

1. 成形 (エントリーおよびディスカバリー段階）、
2. ストリーミング (論争・論争段階）
3. ノルミング (規制・条約段階）
4. パフォーミング (仕事とパフォーマンスの段階）。

ソースはこちらだ： Tuckman’s Phasenmodell zur Teamentwicklung

目標は、顧客のニーズと欲求に完全に焦点を合わせた、小規模で機敏かつ自律的なチームを調整することである。顧客中心主義のトピックは以下の通りである。 これだ また、より詳しく見ることも好きだ。そのため カスタマージャーニー 顧客の顧客になりきって、視点を変えてみるのだ。実際のところ、残念なことに、クライアントは協力企業のプロセスに適応しなければならないことがいまだに多い。特に公的機関ではそうだが、一部の大企業や会社でもそうだ。しかし、それはスクラムの考え方ではない。 

Dominic Price schreibt in “これら5つの誤謬を学ぶことで、あなたはより革新的になる。” über die 5 Trugschlüsse, von denen du dich lösen solltest, um innovativer zu werden.

1. 「成長」と「規模拡大」は同じではない。
2. 変革」は「進化」とは違う
3. 「お騒がせ」は「お騒がせ」とは違う。 
4. 出席時間」と「イニシアチブ」は同じではない 
5. 「アウトプット」と「アウトカム」はイコールではない。

つまり、効率は良いが、効果はより良いということだ。常に効果に注意を払うこと。

経験から言えることは、同じ問題に取り組む人数が多ければ多いほど、解決策を導き出すのは難しくなるということだ。特に、部門横断的で自律的なチームメンバーであればなおさらだ。しかし、チームの規模が大きくなっている場合の解決策は、スケーリングである。それは スクラムガイド は、この分野でのサポートを必要とするチームや企業のための基盤を提供する。しかし、個々のチームを超えてスクラムをスケールさせるには、別のアプローチが必要だ。スクラム・オブ・スクラムのテクニック(SoS技術).

 

ソースはこちらだ： RFCのプロフェッショナル

 

コミュニケーションはアジャイルの世界では全てであり、成功の鍵である。コミュニケーションチャネルは、チームの規模が大きくなればなるほど、すぐに苦しくなる。情報が間違って届いたり、まったく届かなかったりする。遅かれ早かれ、これはチーム内の信頼にも影響し、親密さがなくなり、共通の目標を追求することが難しくなる。

目標は、すべての障害が取り除かれるようにチームを発展させることであり（スクラムマスター）、そのために必要なことがある。 フロー が機能する。理論的には、最適なパフォーマンスを発揮する「完璧なチーム」は、次のようになる。 ハックマンとヴィドマーの研究 の4.6人である。小さすぎるチームは、問題を解決するのに十分でないかもしれない。また、人数が多すぎるチームでは、クライアントの行動力や利害に関する人間関係や機敏さが損なわれる。

場合によっては、チームの分割が必要になる。しかし、ここで注意しなければならないことがある。すでに確立されたシステムに介入することになる。チーム間の能力をバランスよく配分し、機能のインターフェイスを再定義し、タスクを再分配または再定義しなければならない。予期せぬ依存関係や新たに出現したボトルネックは、プロセス全体を遅らせる可能性がある。ここでも、率直にコミュニケーションをとり、チームに時間と余裕を与えることが重要である。忍耐強く、適切な場所で調整することも非常に重要である。

スクラム・オブ・スクラムの手法では、複数のチームが結成された場合の調整が必要である。次の図は、その一つの可能性を示している：

ソースはこちらだ： アトラシアン

チーフプロダクトオーナー：チーフプロダクトオーナーは、製品全体のビジョンに責任を持つ。彼はプロダクトバックログに優先順位をつけ、顧客とのインターフェースであり、口利き役でもある。

スクラムマスター：スクラム・オブ・スクラムの効率向上に永続的に貢献する。他のチームから見える進捗や障害に注目し、チームに権限を与え、タスクの遂行をサポートする。また、次のことも行う。 サーバント・リーダー と呼ばれた。

チームメンバーは、スクラムチームを代表してスクラムオブスクラムミーティングに出席する人を一人任命する。プロジェクト内のどこに重点を置くかによって、チームは常に別の代表者を指名することができる。原則として、トピックに最も近い人が任命される。ユーザーエクスペリエンスに重点を置くのであれば、ユーザーエクスペリエンスに精通した代表者を派遣する。テストに焦点を当てるのであれば、代表者はテスト分野から来るべきである。場合によっては、SOSチームの人数が少なくなりすぎた場合、チームごとに2名の代表者を会議に出席させることが望ましいかもしれない。多くの場合、スクラムマスターはチームから指名された人に同行する。スクラムオブスクラムミーティングの作業が、より高いレベルのミーティングで調整される場合、これはスクラムオブスクラムミーティングと呼ばれる。

頻度とタイムボックス** von Scrum of Scrum Meetings**

スクラムミーティングの頻度はチームが決める。簡単にするために、スクラム・オブ・スクラムのガイドラインに従う。.

しかし、チームの規模や数にもよるが、それほど頻繁には開催されず、長時間のミーティングになることが非常に多い。例えば、週に2～3回である。毎日のミーティングとは異なり、スクラム・オブ・スクラムのミーティングで発生した問題は、可能であれば直接解決されるか、少なくとも対処される。この会議で発生する問題は、非常に重大な問題であり、すぐに100人以上の人々に影響を与える。

会議のアジェンダ

ソースはこちらだ： アンスプラッシュ

スクラム・オブ・スクラムのミーティングに適したアジェンダは、以下のアジェンダである。 デイリースクラム 非常によく似ている。スクラム・オブ・スクラムのミーティングは、実際には毎日行われるわけではないし、各人がチーム全体を代表してミーティングに参加するため、質問の答え方は少し異なる：

• 前回お会いして以来、チームは何を達成したのか？
• 次のミーティングまでに、チームは何を成し遂げるのか？
• チームの仕事を困難にする障害はあるか？
• 自分のチームが何かすることが、他のチームの邪魔になることはないだろうか？

ここでの最後の質問は、そのプロセスと、他のチームに与える可能性のある影響についてのものだ。この質問に対処することは非常に役に立つ。スムーズな協力を生み出すために、いくつかのシナリオを事前に検討するのだ。ここでサイロ思考は事実上崩壊する。最後の質問に対する回答は特に重要である。というのも、調査結果を代表者がそれぞれのチームに伝えることが不可欠だからである。

ミーティングでは、質問に答えるだけでなく、以前から生じていた問題や問題点、課題について話し合い、対処する時間と空間も提供される。ミーティングでは、進捗状況が文書化され、共通の理解が生まれる。解決策や行動は、フォローアップできるように記録される。

会議では、事実に基づいた中立的なレベルを保つため、ディスカッションの中で名前が出ることはない。トピックの長さも、トピックの重要度と明確に区別されている。その目的は、メタレベルから客観的な視点を作り出し、なおかつ視点を変えることにある。

結論

スクラム・オブ・スクラムは、既にスクラムを使用していて、エンタープライズアジリティに移行したい場合に、スケールを拡大する良い方法である。スクラムマスターのパフォーマンス評価についてもっと知りたい方は、以下も参照されたい。 この記事 アン

Scrum of Scrums und SAFe - zwei unterschiedliche Konzepte

スクラム・オブ・スクラム、SAFe、LeSSはすべてアジャイル・スケーリングのための異なるフレームワークであり、リーダーシップの導入やロードマップの構築に対するアプローチも異なる。他のコンセプトについてもっと知りたいのであれば、以下のブログ記事を読むことをお勧めする。 セーフ そして LeSS を読んでほしい。