読書メモ「大規模スクラムLarge-Scale Scrum(LeSS)」
表記本を読んだので感想を記載します。
大分前に買ったっきり、スクラムのスケーリングを考えるのはだいぶ先かなと思って読んでなかったのですが、読みました。システム思考や組織の学習について等、大規模スクラムやらなくても参考になる内容でした。
LeSSは、１つのプロダクトを複数チームで協働するために考えられたスクラムです.
⇒「複数チームでの協働」をテーマにしています。そのためにプロダクトの価値や目的の共有について非常に重視されているのが印象的でしたし、スクラムとも同じだなと感じました。
LeSSの原理・原則
大規模スクラムはスクラム、透明性、少なくすることでもっと多く、プロダクト全体思考、顧客中心、完璧を目指しての継続的改善、リーン思考、システム思考、経験的プロセス制御、待ち行列理論
⇒LeSSも原理・原則が心臓部分としていて、それを元にすコリのルールとガイドと実験の部分があります。ガイドと実験は必須ではなく、試してみる事をお勧めするといったレベルになっています。原理・原則部分は基本的にはスクラムと同様と感じましたが、プロダクト全体やシステム思考の部分が特徴的と感じました。
人はほぼスキルがない状態で生まれてきます。しかし、新しいスキルを習得するという、非常に優れたメタスキルをもっています。このスキルは、柔軟性を目指す組織にとってはとても重要です。専任された長期間存続するチームでは、自動的にこの学習スキルを使うことになります。
⇒LeSS全体としてこの学習に関する要素が非常に強いなと感じました。
フィーチャーチームは顧客と同じ言葉を話し、顧客に説明を直接求めることができます。これによりチームは、何を、なぜ、誰のためにつくるのかを理解し、より目的のある作業が出来ます。また、顧客と開発者のあいだの間接的な層（アナリスト、プロダクトマネージャー、プロジェクトマネージャー)も削減されます。
⇒このような顧客中心、プロダクト中心な考え方もLeSSの特徴と感じました。またプロダクトを拡張可能なものと扱って常に今後の進化を考えながら進めていく点も特徴的だなと感じました。
マネージャーとして最新の状態を保つためのアイデア
・時々チームのバグを修正する
・プロダクトを使い、テストをする
・コメントしなくてもコードレビューに参加する
・ユーザーを訪問または観察する
・(おそらく捨てることになるが)コードのリファクタリングをする
・最新の業界紙を読む
・仕事をしているチームメンバーとペアで作業をする
・何かを自動化する
・コミュニティに参加する
⇒「教師及び学習者としてのマネージャー」というガイドでマネージャーに対しての学習者としての位置づけを強く要求しています。現地現物として現場の理解を進めることを推奨しています。
スクラムマスターはLeSS導入がうまく機能している事に責任を持ちます。注力する対象は、チーム、プロダクトオーナー、組織、技術的手法の改善であり、各スクラムマスターは１チームだけの改善にとどまることなく、組織全体の改善を行う必要があります。スクラムマスターは専任で専従の役割です。1人のスクラムマスターは1-3チームを担当できます。
⇒LeSSはチームだけでなく、全体で価値を上げることが重要な為、スクラムマスターの責務も難しいと感じました。組織、チーム、プロダクトオーナー、開発プラクティスに時々で重点を置き、変えながら組織の自己組織化を進めていくとあるので、かなりハードル高いです。またそのために学習やコミュニティ活動が重要と書かれていました。
ガイド：あなたのプロダクトを定義する
ステップ１：プロダクトの定義を可能な限り広げる
・「私たちのプロダクトはなんですか？」と尋ねると、顧客は何と答えますか？
・共通のコンポーネントや、現在のプロダクト間で同じ機能はありますか？
・私たちのプロダクトは何かの一部ですか？プロダクトが最終的な顧客のために解決する問題は何ですか？
ステップ２：プロダクトの定義を実践的な内容に抑える
・プロダクトにはどのようなビジョンがありますか？顧客は誰ですか？プロダクトの顧客ドメインは何ですか？
・私たちの会社の中では、何を開発していますか？どれくらいの構造変化なら実践できますか？
ステップ３：最初のプロダクトの定義を決定する
⇒プロダクトの定義についてとても大事に感じました。またこれらの事をチームメンバーでいかに共有できるかがポイントと感じました。
ガイド：５つの関係
a.プロダクトオーナーとチーム
・ともに当事者になる
・対等の関係
・チームに助けを求める
・信頼を構築する
・助けましょう、次の場合を除いて
・マイクロマネジメントはしない
・ふりかえる
・チームの拠点を訪ねる
b.プロダクトオーナーと顧客/ユーザー
・教育する
・ユーザーと一緒に参加する
・少なくともスプリント単位で出荷する
・透明性を高める
c.チームと顧客/ユーザー
・コネクターになる
・ビジネス活動を共有する
・顧客と話す方法を教える
・顧客関係管理グループと組む
・中間の人たちを統合する
d.プロダクトオーナーと上級マネジメント
・自己評価する
・まわりを教育し、役割を売り込む
・「プロダクトオーナーに」を伝える
e.プロダクトオーナーとスクラムマスター
・少しだけ
・生徒になる
・じっくり考える
⇒プロダクトオーナー５つの関係性に対してどのように振舞うかというヒントです。特に「チームと顧客/ユーザー」の所は強く意識したいと感じました。
出荷は、言葉よりも声が大きい
⇒LeSSはチームが分かれているからこそ、プロダクトとしてシッパブル(出荷可能)な状態にしておくこととインクリメンタルに進めることを強く重視していると感じました。
プロダクト全体で全チーム共通の１つのDoneの定義を持ちます。各チームは共通のDoneの定義を拡張してより厳しい独自のものを定めても構いません。究極の目標はDoneの定義を拡張し、毎スプリント(あるいはより高い頻度で)出荷可能なプロダクトをつくれるようになることです。
⇒出荷可能な状態を目指すためにDoneの定義とUndoneワークの考え方について重視しています。（UndoneワークとはDoneの定義と潜在的に出荷可能の差分の事です)スプリント進めて行きながらDoneの定義を育てることを重視しています。
プロダクトバックログリファインメントは、将来そのチームが対応しそうなアイテムについてチームごとに行われます。複数チームや全体でPBRを行うのは、関連性が強いアイテムであったりより広範なインプットと学び得る必要があるときに、共通理解を深め、互いに関連したPBIについて協力する方法を探ったりするためです。
プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。複数チームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダクトオーナーをサポートします。
すべての優先順位付けはプロダクトオーナーに確認をとりますが、要求や仕様の詳細確認は極力チーム間や顧客、ユーザーまたはステークホルダーと直接行います。
⇒バックログリファインメントの考え方です。リファインメント作業の記載でも学習や顧客主義、システム思考をとても重視しているのが伝わります。
スプリントプランニングは2つのパートに分かれます。スプリントプランニング1はすべてのチームが合同で実施します。それに対してスプリントプランニング2は通常、各チームに分かれて別々で開きます。ただし、関連性が強いアイテムを持っているチームは同じ場所で、複数チーム・スプリントプランニング2として一緒に行います。
スプリントプランニング1はプロダクトオーナーと全チームまたはチームの代表で行います。参加者は一緒に、チームは協働する部分や不明確な点を見つけ、残った疑問があれば解決します。
各チームはチーム毎のスプリントバックログを有します。
スプリントプランニング2は各チームがどうアイテムを実現させるかを考える場であり、設計やスプリントバックログの作成を行います。
⇒スプリントプランニングの説明です。全体-個別との関係があるので、ボトルネックにならないようなバランスで進めるのが難しそうだなと感じました。
ガイド：ただ話す
大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。
(1)あなたは、チームBとの”調整が必要”なことに気付きます
(2)立ち上がって、
(3)チームBの所に歩いていき、
(4)「やぁ、話し合おうよ！」と言います
この一連を私たちは”ただ話す”と呼んでいます。
⇒この「ただ話す」は本当に強力ですが、意外とやられないと感じていて、名前を付けて推奨するというのはとても良いなと感じました。
感想
大規模スクラムとしての本になっていますが、大規模でなくても重要な要素が多くありました。大規模になればなるほどプロダクトや顧客主義、学習の重要性がしっかり説かれているのが印象的でした。ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？