DoorKeeper
https://postudy.doorkeeper.jp/events/87970
Togetter
https://togetter.com/li/1325878
新しく立ち上がる大規模スクラムプロジェクトにスクラムマスターとして放り込まれそうなので、ちょうど良い機会、ということで参加することに。
先日↓の書籍が発売されたのでこちらも購入済みで、読み進めている最中なのです。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
posted with amazlet at 19.03.06
丸善出版
売り上げランキング: 13,367
先日、LeSS Studyでも読書会が始まったので、こちらも参加してきたところです。
アジャイルサムライ横浜道場でおなじみ、たくぼんさん。
LeSS Study を再開します。
— KIMURA Takao (@tw_takubon) February 16, 2019
今回から、『大規模スクラム Large-Scale Scrum(LeSS) 』https://t.co/b9n0V53Oqzの読書会方式で進めていきます。
担当が発表する中、ピザやドリンクを楽しみながら、発表内容についてディスカッションして、盛り上がりましょう！https://t.co/P7edKntqY5
次回の読書会は3/19です。ご一緒にいかがですか～？
イントロダクション
今日のファシリテーターはodd-eの榎本さんです。
以前、スクラムマスター研修（CSM）を受けたときにお世話になりました。
冒頭、参加者にカードが配られ、榎本さん曰く、「今日一番議論したいことを１つ書いてほしい」とのこと。
ということでこんな感じで書いてみた。
先月、デブサミでScrum@Scaleの講演を聴講してブログ書いたり、Nexusの日本語ガイド読んだりしてたので、やっぱ違いが気になります。
書き終わったら、次は「周りの参加者さんと自己紹介を兼ね話し合ってみてください」とのこと。
ということで周りの４～５人の方と会話させていただきました。やっぱ同じこと思ってた方もいらっしゃったようで。
LeSSの概要理解
お次は、LeSSの概要を紹介した動画をプロジェクタに投影しながら、榎本さんが説明を随時挟んでくださいました。
日本語の字幕が付いたスライド、あったんですね。
以下、メモ。
「大規模」について
LeSSで大規模にスクラムをやることを推奨はしていない。
小規模で上手くいってたものが、大規模になると上手くいかなくなる。。。
大規模にスクラムをやることを目的にしてほしくない。
小さく行けるなら、そちらのほうが好ましい。
無理にスケールしないでください。
どういった状況を大規模というか？というと、2チームから。
1チームでいけるなら、極力１つのチームでやるのが好ましい。
チームが2つ以上になるなら、極力シンプルに。
極力スクラムを維持しながら、必要最低限のものを追加して、スクラムのエッセンスを極力残したものがLeSS。
プロダクトオーナー
LeSSは1人のプロダクトオーナーで、プロダクトバックログも１つ。
それに対して複数チームが仕事をしていく。スプリントの期間も全チームが一緒。
基本的には「１つのスクラムでやることを複数チームでやるにはどうすればいいのか」という観点で最低限のルールを追加している。
チーム間の調整は、チーム同士で調整していただく。
プロダクトオーナーやスクラムマスターがチーム間の調整をするわけではない。
それぞれのチームが開発していく上で、チーム間の調整は必要。それをチーム同士でやっていただく。
プロダクトオーナー視点でいうと、複数チームになると、やることが増えてくる
１つのチームなら要求の詳細化をプロダクトオーナーが出来た。
それが複数チームになると難しくなるので、要求の詳細化などをプロダクトオーナーから開発チームに移譲していく。
ビジョンはプロダクトオーナーが示す。PBIの優先順位もプロダクトオーナーが最終に決める。
開発チームが自分たち自身で顧客から要求を聞き出す、というようにプロダクトオーナーは促していく必要がある。
開発チームと、要求を持ってる人を、近づける。
開発チームと顧客とで、直接やってもらう環境づくりをプロダクトオーナーがやる。
プロダクトオーナーが自分でPBIを明確化しなくても済むようにする。
オーバーオールレトロスペクティブ
通常のスクラムにない考え方として、オーバーオールレトロスペクティブというイベントがある。
開発チームの代表者、マネージメントする人、顧客などの人たちが集まって、複数チームや組織全体の課題を考える。
複数チームで開発するとなると、全体としての課題解決の場が必要になる。それがオーバーオールレトロスペクティブ。
2種類のLeSS
LeSSは2種類ある。通常のLeSSと、LeSS Huge。
LeSS Hugeになると、8チーム以上。その場合、もうちょっと構造を追加しないと上手く全体が回っていかない。
８チームを超えたタイミングで追加の構造が作られる。
LeSS Hugeでは、エリアプロダクトバックログとエリアプロダクトオーナーという概念が追加される。
実際の開発チームから見たら、エリアプロダクトバックログが通常のバックログで、エリアプロダクトオーナーが通常のプロダクトオーナー。
プロダクトオーナーは、どのエリアにプロダクトバックログアイテムをまかせていくのかを決める。
各チームをどこのエリアに配置するのかを決める。
全体の差配、調整をプロダクトオーナーが担う。
開発チームから見たら、常に１つのプロダクトバックログ、 1人のプロダクトオーナー。
組織構造
通常、スクラムやLeSSをやるように組織は設計されていない。
LeSSは影響範囲が広くなるので、組織の影響を多く受ける。
スクラムやLeSSで定義されてない役割が組織にはいっぱいある。
企業にはそういう課題がいろいろある。
それらの課題を解決して大規模でスクラムやっていくには、推進者には障害がインパクトとして出てくる。
フィーチャーチームになるよう組織構造を変えなきゃいけない。
顧客に価値を提供できるスキルを持ってるのがフィーチャーチーム。
UI/UXチーム、サーバサイドチーム、DBチーム、とかは「コンポーネントチーム」と呼ぶ
１つのユーザー価値を提供することができるスキルセットを持ってる人がフィーチャーチーム。
組織構造を変えていくことが必要になる。
More with Less
少ないことでもっと多く。More with Less。これが基本の考え方。
何かを追加するのではなく、極力シンプルに維持していくのがコアの考え方。
QAの責任者を立てる、とかだと、「品質に責任を持つのはQAだ」という考えになってしまう。
それは開発チームから品質の責任を取り上げているのと一緒。
チームに責任を持って行ってもらう。責任をQA等、あちこちに分散させないことが大切。
チームから責任を奪うのではなく、チームが責任を果たせる状況を作っていくのがマネージャ。
原理原則がコアになる。
その上にフレームワークのルールがある。そんなに数はない。
原理原則やルールだけでカバーできない部分は、TIPSとして多く存在している。ガイドとか実験だったり。本に書いてある。
前の2冊は、クレイグとバスの実験がいっぱい書いてある。その一部が今回の本に書かれている。
必ずやったほうがいいよ、というものではない。
ルールはやりなさい、とLeSSは言ってるが、ガイドに書いてあることは助けになることがあるので使ってみるのがいいんじゃない？くらいな感じ。
LeSSでやることは極力シンプルに。
プロダクトオーナーからの視点としても、スクラムと変わらない。
極力チームに裁量を持ってもらわないとプロダクトオーナーは回らない。
PO視点での探求セッション
ここからはフィッシュボウル（Fishbowl）形式でのパネルディスカッションです。
4人がパネラーとして前の椅子に座り、ディスカッションネタを提供する人が順に1人ずつ前に出て、パネラーと議論していきます。
以下、出た意見のメモ。
実際はこのセッションの前に質疑応答の時間があったので、メモもそこから。
Q.
LeSS Hugeは８チームから、という話だが、「８」の意味は何か？
A.
「8」は、LeSSの中でオススメしているプロダクトバックログの粒度に関係がある。
1チームが毎スプリントで４つくらいプロダクトバックログアイテムを選択するのがお勧め。
プロダクトバックログリファインメントで3スプリント先まで詳細化する。
そうすると、1チームあたり１２個くらいのバックログアイテムを明確にする必要がある。
8チームだと、合計１００個くらいのバックログアイテムを明確にする必要がある。
１００くらいがプロダクトオーナー1人が理解して優先順位を決めれる限界だろう、という考えに基づいている。
8チーム以上になると1人のプロダクトオーナーで対処できないので、エリアプロダクトオーナーがプロダクトオーナーの役割を担っていく。
そうしないと把握しきれなくなる。
プロダクトオーナー視点で注意しないといけないのは、細かくやりすぎるとすぐ把握できなくなる、という点。
ある程度まとめてやっていく、という考えが必要。
Q.
なぜ責任は分散させてはいけないのか
A.
LeSSで重要視しているのが、顧客やプロダクトの全体感。
常に動くソフトウェアを作るということ。
責任を分散させると、全体感や責任を持つという点がチームから離れていく。
自分の責任じゃないよね、という部分最適が始まる。
助け合いが生まれない。組織として良くしていこう、という思想と真逆にいってしまう。
Q.
リリース後のフィードバックからPBIを作るのが難しい。
A.
マーケットから新しい学びを得たら、スプリントレビューとかPBRとかでプロダクトオーナーから開発チームにシェアしていく。
そこからどうしていけばいいかは開発チームに主体的に動いてもらいたい。
大きな変化をさせる必要が出てきたら、開発チームに伝えて、プロダクトバックログに入れる。
その時は、ポンッと大きい要求を入れる。プロダクトバックログアイテムの分割など、細部はチームにやってもらう。
プロダクトオーナーは方向性とかビジョンとかを持ち続けるのが重要な責務。
Q.
異なるチーム間で、プロダクトオーナーからのインプット情報は、どの程度共有するべきか
A1.
朝会やバックログリファインメントを部屋でやってると、「あの人たち、何をやってるんだろうね・・・」となる。
A2.
週次のレビュー会は全員でやる。その場でプロダクトオーナーが決定する。
A3.
LeSSのフレームワークとして、共有する場としてはスプリントレビューがある。参加者は全員。
大きい部屋で各チームがブースを持つ。バザールと呼ばれる形式でやる。
スプリントレビューでは、いろんなチームが開発したものがブースで公開されるので、ステークホルダーはそれらを見て回る。
スプリントプランニングとかプロダクトバックログリファインメントとかは、LeSSだと2部構成でやる。
1部は全員参加。
スプリントプランニングの第一部は、一番上のバックログアイテムから順に、どのチームやる？と決めていく
プロダクトバックログリファインメントも、どのチームがやるのが良さそうか、を考えて、そのチームにリファインメントをやってもらう。
Q.
ソースコード、チーム間のをどのタイミングでシェアしてる？
プロダクトバックログリファインメントをやろうとすると、そのソースに知識がないとできない。
違うチームが作ったものを学習していかないといけない。
意識的にやらないと、自分のに集中してしまう。
A1.
他人のソースをいじるの難しいなので、チームで完結するようにしてた。
A2.
LeSSは「コードの共同所有」という概念を提唱している。
基本的にはどのソースも、誰でも変更を加えられる。その考え方をオススメしている。
このソースはこのチームにしか触れない、だと、そのチームに変更依頼しないといけなくなる。
誰でも変更してOKとなると、コンフリクトおきるじゃん？となる。でも、コンフリクトは極力起こそう、という考え方に立つ。
変更を1週間分貯めてマージ、じゃなくて、1時間に何回も同じコードベースに対してマージしていく。
それだとコンフリクトの差分が小さくてすむ。
どこが誰とコンフリクトしたかが分かる。コンフリクトすることが互いに話すきっかけとなる。
コードで対話していきましょう。
極力コンフリクトが頻繁に送る環境を作るようにする。
Q.
LeSSのプロダクトオーナーに向いてる人は？
A1.
完璧主義は向かないかな？
A2.
任せる人。
A3.
意思決定をちゃんとする人。
A4.
やるやらないを明確にする人。
A5.
開発で細かいところは知りたがるけど、それでも任せる人。
開発よりも、市場とかお金をもらう人に意識が向いてる人。
Q.
短いサイクルでたくさんの意思決定を求められる。なにかよい工夫あるか？
A1.
決定するには事前の情報収集が大事。市場を分析して未来を予測する。
A2.
あとで検証できるように根拠を明らかにしておく。
A3.
スクラムマスターが意思決定をしてしまって、そこに結論を誘導するようにした。
A4.
失敗していいんだ、というのを後押しする。
Q.
成功するプロダクトと成功しないプロダクト、どこが違うんだろう？
A1.
成功するプロダクトは、ビジョンが最初から最後まで変わらない。
A2.
はっきりと意思決定すること。ビジョンを持ってることが意思決定の速さや成功につながる。
Q.
プロダクトオーナーで難しいのが、どうやってスポンサーを納得させるか。
開発チームやスクラムマスターに、こーゆうことやってほしいな、というのがあれば教えてほしい。
A1.
ステークホルダーを納得させるのに、場を設けるとか日程調整とかの時間をプロダクトオーナーは持っていかれがちなので、それらの調整はスクラムマスターにやってもらうようにした。
A2.
投資家にお金を出してもらうには、「動くもの」と「将来性」を見せることが大事。
結局、動く状態をいかに作り続けていくか。動くように継続するのがポイントかな。
Q.
スクラムを理解してない人から、「ミーティングばっかりやってるよね」とか、「残業しないでいつも早く帰るよね」とか嫌味を言われる。
A1.
スクラムの啓蒙は外にもやってほしい。
A2.
完成前にプロダクトを提供していくのが大事。製品を細かくリリースしていく。
それにはバックログアイテムの分割が重要。
フィーチャーチームの単位で体制を組め、とLeSSはルールとして言ってる。
バックログアイテムをフィーチャーチームができるように分割してないとダメ。
フィーチャー単位でのバックログ分解をしていく重要性を開発チームにもプロダクトオーナーにも理解してもらわないといけない。
ユーザーが読んでもわかるようなバックログアイテムになってるのが重要。
開発者しかわからないバックログアイテムはフィーチャー単位でなくコンポーネント単位になってる可能性がある。
Q.
LeSSをやったとしても、本質的には組織を変えないといけない。年月がかかる。
そこが上手くできなかった。どうやればいいか。
A1.
上の人に共感を得る。
A2.
組織を変えるにはトップダウンとボトムアップの両方が必要。
組織構造をいじれるマネジメントと、現場と、両面から変えていく。
スクラムの価値を説明して体感してもらうことが、スクラム知らない現場をボトムアップで変えていくのには大事。
A3.
2000人をいきなりには変えられない。
まず10人からやって、徐々に根回しを経営層にしたりしていく。
まずちっちゃく初めて、10人単位にして、次に100人単位にして、徐々に進めていく。
大企業でいきなりやるのは難しいので、小さい組織を特区化して、そこで試す。
徐々に人数が増えていくと、見え方が変わる。
2000人のうち、３００～４００くらい変えられると一気に変わるんじゃないかな。
A4.
LeSSは8チームまでなら一気に変えていい。
8チーム以上のLeSS Hugeくらいになると、一気にやっちゃだめ。痛みを伴う。混沌としちゃう。
まず失敗を許容できる領域とサイズでやる。
ゆっくりゆっくりかな。
Q.
個人評価とチーム評価、どこかでぶつかる。どうすればいいか。
A1
特区化してるメンバに対しては、良い人に寄せてチーム評価をつけるようにしている。
A2.
多面的に評価する。
計画性があるものは、計画通りにいけてるかを重視するし、走りながら考えるものは、失敗しても行動やプロセスを評価する。
評価の考え方を分ける。
A3.
LeSSの提唱者のバスは、評価制度自体が時間の無駄、と言っている。あんな価値を生まない活動はない。
odd-eは評価制度がない。作るつもりもない。
お金のために働く、という状況をいかに作らないかが大事。
ビジョン実現のために仕事をしていく、という状況を作る。
感想
一方向の座学形式でなく、ディスカッションやワークショップの要素が多く入っているのが良いですね。
いろんな人の考えを知ることができ、いろいろ考えさせられました。
それなりの規模の企業だとプロジェクトもそれなりの規模になることが多いので、スクラムをいかにスケールさせるか、というのに悩んでる人は、実はけっこー多いんじゃないか、と思うのです。
ということで、こーゆう観点の勉強会がもっと広まっていくといいなあと思いました。
榎本さん、関さんはじめ、関係者の皆様ありがとーございました。
- 関連記事
-
- 自転車で東京から銚子への旅 1日目
- POStudy 「１チームスクラムと大規模スクラム（LeSS）ではPO目線で何が変わるのか？」に参加しました
- 自転車で山梨から静岡へ、富士山沿いの自転車旅 3連休2日目
