スクラムの拡張による組織づくり ──複数のスクラムチームをScrum@Scaleで運用する

投稿元：

レビューを見る

スクラムは実践している、けれども大規模アジャイルについてはよくわからないー。私自身がそうだが、そういった人がscrum@scaleについて概要をおさえるのにうってつけの一冊。
オーソドックスなスクラムを起点に各コンポーネントの解説がなされ、実際に著者が行っている実践例まで紹介されるため、かなりとっつきがよい。なんならちょっとやってみたくなる。
いわゆる大規模アジャイルについて疎い人間としては、scrum@scale以外の大規模アジャイルについても簡単に触れているのがありがたかった。

投稿元：

レビューを見る

スケーリングアジャイルに関する日本語文書では最高の読みやすさと内容。これからは薄っぺらくて読みにくいLeSSよりこちらを紹介すると思う。

投稿元：

レビューを見る

大規模スクラムの中でも、特にScrum@Scaleに主眼を置いた一冊。
その他の手法にも触れつつ、どういった部分に主眼を置いているのか、異なるのかといった部分が紹介されていてよかった。

著者が実際に組織に導入した例などにも触れつつ、構成する各コンポーネントの働きや協働する内容が説明されており、実際の現場に当てはめてイメージがしやすかった。
フラクタルな構造を維持するうえで、完全に官僚的な構造を排除することは難しく、必要最小限の官僚機構を導入するというのは納得感がある。

複数のチームが連動するスクラムチームの中に身を置いている中で感じていた課題を自分の中で整理するうえで、非常にいい本だった。

投稿元：

レビューを見る

自社でやろうとしていることのヒントになるかも、という思いもあり手に取った。

具体的にはScrum@Scale そのものをやりたいわけでは無いのだけど「自律して動けるよくできたチーム」を単位として組織のパラダイムを変化させていこうと考えており、考慮すべき点の参考になった。

投稿元：

レビューを見る

以前、スクラム開発を採用していたプロジェクトチームの規模（人数）が大きくなってきたとき、Scrum@Scale導入の話が上がってきました。その時に本書を購入。

Scrum@Scaleがどういうものかという説明は当然として、実際の導入事例が紹介されているので、Scrum@Scale導入時にとても参考になりそう。

前提としてスクラム開発のことを知っておく必要がありますが、第2章に「スクラムのおさらい」として簡潔にまとめられているので、問題はないと思います。スクラム開発を知っている人にとっても、この「おさらい」はチートシート的に役に立つのではないかと思います。

要所要所で図があったり、要点が箇条書きで簡潔にまとめられているところがあるなど、個人的にはかなり理想に近いテキストで、非常にわかりやすい内容だと感じました。

投稿元：

レビューを見る

「スクラムの拡張による組織づくり」のScrum@Scaleの感想: プログラマの思索

https://forza.cocolog-nifty.com/blog/2024/03/post-068e48.html

投稿元：

レビューを見る

LeSS：プロダクトバックログは一つ、プロダクトオーナーも1人。スプリントバックログはチームの数だけ必要。
Scrum@Scale：開発現場のHowの部分を担うスクラムマスターサイクル＋Whatの部分を担うプロダクトオーナーサイクル
　スクラムマスターサイクルは、開発チームが複数で連携するためのやり方を定義しています。プロダクトオーナーサイクルは、複数の開発チームが連携するために、それぞれのチームに所属するプロダクトオーナーたちの仕事のやり方を定義しています。

　Scrum@Scaleの主な特徴は、普通のスクラムを「拡張」している点にあります。ただし、拡張することによって複数のチームによる相互のコミュニケーションが必要になるため、チーム間のコミュニケーションに関するルールを設けています。なぜなら、チームの数や関わる人数が増えて規模が大きくなるほどコミュニケーションの複雑さは増し、やがてそれは手に負えなくなってしまうからです。
　…Scrum@Scaleとは、通常の単一スクラムチームの活動にチーム間の連携のしくみを追加したもの、と言い換えることができます。

▫️スクラムオブスクラムマスターの役割
・SoSとして開催するイベント全般の開催支援・ファシリテート
・SoSとして以下に関する話し合いが確実に行われるようにする
　・SoS全体として仕事の妨害になるもの（障害物）の共有や除去
　・SoS全体としてのプロセスの改善
　・チーム横断的な依存関係の調整
・チーフプロダクトオーナーと緊密に連携し、SoSとして統合されたインクリメントを届けることに責任を持つ
・SoSそのものの継続的な改善に責任を持つ


　各チームのプロダクトオーナーは、SoSやSoSoSといった構造でひと塊りになったチームどうしの結び付きの単位で、プロダクトオーナーどうしのチームを組みます。図4.13のようなイメージです。このチームで、組織全体で一貫性を持ったプロダクトバックログを作ります。そしてチームごとにプロダクトバックログをブレークダウンして供給します。そうすることで、チームが個別のプロダクトバックログを持ちながら、組織全体においても方針がバラバラにならず、一貫した方向性を示し続けることができます。このようなプロダクトオーナーによるチームを「メタスクラム」と呼びます。
　メタスクラムは、プロダクトに関する方向性を決定する場となります。したがって複数の方針決定者が横並びで決定権を持った状態で活動することはあまり好ましい状態ではありません。意見が割れた場合などに、最終的な決定権を持った人が必要です。このメタスクラムには、チーフプロダクトオーナーという最終的な意思決定者を置きます。これは、専任でも、各チームのプロダクトオーナーの誰か1人が兼務してもかまいません。


　スクラムマスターサイクルとプロダクトオーナーサイクルの最初の交差点は「チームプロセス」です。スクラムガイドが定義しているスクラムの活動を軸に、Scrum@Scaleとしての組織構造を定義しています。ここからいったんスクラムマスターサイクルと、プロダクトオーナーサイクルの活動は分岐���ます。
　プロダクトオーナーサイクルでは、組織全体の一貫性を維持し、スケールされたすべての組織が足並みをそろえるために「戦略的ビジョン」を策定し、維持します。
　次に、その「戦略的ビジョン」に基づいて作成したプロダクトバックログの優先順位付けを行います(「バックログの優先順位付け」)。
　プロダクトバックログは、決められた優先順位に従って整え、必要に応 じて各チーム単位に分割します(「バックログの分割とリファインメント」)。
　プロダクトバックログの準備が整えば、それをいつリリースするのか「リ リースプランニング」を行います。
　これらの活動を「EMS」が中心となって繰り返します。
　スクラムマスターサイクルでは、日々の開発をしながらプロセスの「継続 的改善と障害の除去」を行います。
　スケール化された組織では、複数チームが連携して作業にあたることと なるため、「チーム横断の調整」も欠かせません。
　やがて開発したプロダクトを「デリバリ」します。
　これらの活動は「EAT」が中心となって繰り返します。
　活動が分岐していたプロダクトオーナーサイクルとスクラムマスターサ イクルは、プロダクトをデリバリし、そのフィードバックを得る段階で再 び合流します。ここで、それぞれの活動の次のスプリントに必要な重要な 手がかりを得ます(「プロダクトリリースとフィードバック」)。
　これらのフィードバックを正しく解釈するために「メトリクスと透明性」 が重要な要素となります。
　これらの両輪の活動を繰り返しながら「プロダクトインクリメント」を生み出します。
　これが、Scrum@Scaleの全貌です。

▫️12のコンポーネント
・スクラムマスターサイクル
　・EAT
　・継続的改善と障害の除去
　・チーム横断の調整
　・デリバリ
・プロダクトオーナーサイクル
　・EMS
　・戦略的ビジョン
　・バックログの優先順位付け
　・バックログの分割とリファインメント
　・リリースプランニング
・両サイクル共通
　・チームプロセス
　・メトリクスと透明性
　・プロダクトリリースとフィードバック

▫️企業変革の「８つのアクセラレータ」
・危機感を醸成する
・変革を推進するチームを築く
・戦略的ビジョンを作る
・ビジョンを伝え、熱意のあるメンバーが参加する
・障害を取り除き、成果をあげる
・短期な成功を生み出す
・変化を促進する
・変化を根付かせる

投稿元：

レビューを見る

スクラムを拡張するとそうなるのか〜というのはシンプルに学びでした。コミュニケーションパスの設計が要だという感想です