LeSS,そういうのもあるのか！ということでチームスクラムと大規模スクラム（LeSS）ではPO目線で何が変わるのか？- POStudy ～アジャイル・プロダクトマネジメント研究会～に行ってきたメモ

LeSSの概要説明

Youtubeの紹介動画を見ながらポイントごとの説明がありました。

www.youtube.com (日本語字幕があるのでONでどうぞ)

動画を流しながらの解説メモ

LeSSは一つのチームで行われるスクラムを複数のチームでどうしたらやれるの考え方なのでLeSSは可能であればやるべきではない。LeSSは2チーム以上のスクラムをどうやるか、従来のスクラムのエッセンスをどうそこに落とし込んでいくかの考えかた
従来のスクラムと同様にちゃんとビジョンなどは明確に示す
基本的には1つのバックログ、1つのプロダクトオーナー、同一のスプリント期間でやるのが前提
プロダクトバックログはチームに配分して、チーム間の調整ごとはPOではなく、チームそのものがコミュニケーションをし解決する。POやスクラムマスターがチーム間の調整に立つという考えではない
POは開発と顧客の要望を持つ人達の距離感を縮めていくことが仕事となる。そこが近づけば作るものは明確化されるのでPOが細かく支持を出さなくても良くなる
8チーム以上を扱う場合は、LeSShugeという形になり、チームごとにAreaPOとAreaスクラムマスターができて細分化される。チームとしてはAreaPOがPOの立ち回りをし、チームはAreaPOをPOとして見るようにする。
LeSSはコンポーネントごとのチーム（UIチーム、サーバサイドチーム）ではなくFutureごとにチームを分けるべきとされている。
極力シンプルなもので維持していくのがコアな考え方。
規模の大きい組織のように部署で責任を負わせる形（例えばQA部門がいれば、品質の管理はその部門）みたいな考え方をするのではなく、チームがすべての責任を負う形にする
LeSSは大きなチームでもシンプルなスクラムをやるための取り組み方。

ディスカッション

フィッシュボウルの形式でディスカッションがあったのですが、部分的によりぬきメモです。

異なるチーム感で、プロダクトオーナーからのインプット情報はどの程度共有すべきか

曜日を決めてその日はMTGの日としチームメンバー全員でスプリントレビューをやっていくなどの事例の話があった
LeSSとしては一つの大きな部屋にチームごとにブースを設けてレビューして回るバザールという手法がある紹介があった
派生してコードをどうするかという話もあったが、コードはなるべくチーム内では属人化させないようにする、LeSSとしてはみんなが見てわかるコードを書くなどの話があった

どういう人がLeSSのPOに向くのか

完璧主義者は向かないのでは？という意見
意思決定をちゃんとするひと、やる/やらを明確にする人が強そう、など
上記に関連して、ビジョンがはっきりあると意思決定が早い。そういうプロダクトのほうが筋が通って生きる。最終的なプロダクトの成長につながる。という意見もあった。

POはどうやってスポンサーを納得させるのか

継続的に動く状態を維持していったりすることが大事
内部でイマイチな評価でも、世に見える形になったら評価されて会社内の評価が変わったという話もあった

組織構造を変化させるにはどうすれば

ボトムアップとトップダウンが大事というのがLeSSの概念ではあった
すでに社長がスクラムできる、ボトムアップは大変などの話もあった。

スクラムはチーム、評価は個人、そこをどうしているのか

多面的に評価するというご意見
スクラムなので計画性のあるもの、計画性のないものがあるので、計画性があるものはちゃんと遂行できたかを見て、そうでないものは動きなどを評価する

全体を通しての感想

ディスカッションのときにPO練度高い人の意見がたくさん出てきて自身のいるところとの練度の差を感じた
なんちゃってスクラムマスター業をやっているので、その観点から見ても学びはあった
大規模スクラムといえども基本ラインを踏襲しつつの拡張なので、ベースのスクラムをしっかり身につけないとなんか要点抜け落ちそうなので、そこを理解するのが先かなという感じだった
フィッシュボウルで登壇したかた結構鮮烈なイメージの人多くて、中でも曜日固定でMTGデーにして残業禁止にしている事例がセンセーショナルだったのでもっとお話聞きに行けばよかったなという後悔…