tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

LeSS Study LeSS本読書会 第1回 & 第2回に行ってきました

f:id:tune:20190321134657j:plain
サインをもらいました

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が1月末に発売され、LeSSの勉強会「LeSS Study」が読書会として再スタートすることになったので行ってきました。アジャイルスクラム・LeSSに関して突っ込んだ議論ができるとても楽しい会なのですが、ピザ&ビールを食べながらで翌日には記憶が曖昧になってしまうのが難点です。

LeSS Study LeSS本読書会 第1回

秋葉原のクラスメソッドさんでの開催でした。 内容は「読書会の説明」、「LeSS本の説明」、「LeSS でもっと多く: 2ページ」まで予定通り進みました。

以下質疑応答でかろうじて覚えているメモです。

Q: LeSSはスクラムなのか

A: スクラムである。原則にも「Large-Scale Scrumはスクラムである」と明確にかかれている。

LeSSはスクラムをベースに新しい役割やイベント、ルールを当てはめたものではなく、1つのスクラムを複数チームでやろうとした際に考慮した方がよいアドバイス集のようなイメージです。

Q : LeSSを構成する原理・原則が多いのではないか?

A: 確かにそうかも。

「透明性」や「顧客中心」などスクラムと重複しているものもある。 「LeSSはスクラムである」ならば、スクラムの原理原則をベースとして、LeSS固有の追加事項だけに記述を留めたほうが良いのかもしれない。

Q: システム思考ってどんなもの? 勉強にいい本ある?

A: 相互に作用する要素・関係性を整理し、どこを起点に改善を図っているかを考えるやり方。

例えばプロジェクトが遅延すると追加要員が送られる。開発メンバが増えるとコミュニケーションコストが増えさらにプロジェクトは遅延する。プロジェクトが遅延すると追加要員が送られ…といったよくある事象を関係で整理し、改善点を検討する。

LeSS Study LeSS本読書会 第2回

恵比寿 Redhatさんでの開催でした。 第2章が対象でしたが、途中の議論が盛り上がりスプリントプランニングぐらいしか話していません。

Q: スプリントプランニング1に代表者しか来ないとあるけど、残りの人は何しているの?

A: 対して長くないから気にしなくても大丈夫。

1チームスクラムのプランニングと異なり、LeSSのスプリントプランニング1はどのチームが何のストーリを担当するかを「ざっくりと」決めるものなので短いです。プロダクトオーナーがバックログを付箋に書いて持ってきて、チーム代表者の前にがさっと置き、代表者が好き好きに好きなものを持っていくぐらいのイメージです。事前にプロダクトバックログリファインメントでどんなストーリーが来るのか確認しているのでここで長い議論になることはないのだと思います。

Q: スプリントプランニング1でバックログの優先順位を考慮しなくて良いのか?

A: チームにストーリーの分配が終わった後で優先順位が高いものが残った場合、プロダクトオーナーがチームと交渉すれば良い。「このストーリーと交換できないか」とか。

Q: 書籍では「預託チーム」「取引チーム」「非デリバティブチーム」となっているが、チーム分けはどうするのか?

A: 顧客視点の機能で分けるフィーチャーチームが基本。コンポーネントチームではない。

とはいえ書籍のチーム名はコンポーネントチームに見えなくもない。「預託コンポーネント」とかありそう。 実際の現場では機能と関係がないチーム名をつけ、「預託に強いチーム」「取引に強いチーム」といった認識を裏で持っておくぐらいで良いが、書籍での説明のしやすさのため今の形に落ち着いているのかもしれない。

スクラムマスターは保育園の先生に似ているという話もあるので、「うさぎさんチーム」「くまさんチーム」といった名前でも良いかもしれない。

Q: 単一チームでプロダクトバックログリファインメント(PBR)したストーリーを別チームに割り振ってもいいの?

A: ダメじゃないけど、どのチームが担当しても良いストーリーは複数チームでPBRした方が良い。

「複数チームPBR」は、A・B・Cの3チームがあった時、3チームで順繰りに見積もりを行なって結果をまとめるということではない。A・B・Cのメンバをごちゃ混ぜにし、3グループに分け、3グループに見積もり対象のストーリーを1/3ずつ分け、それで見積もりを行う方式である。したがって見積もりに要する時間は単一チームに見積もらせる時と変わらない。

複数チームPBRを行う利点として、チーム横断で議論できることで観点の見落としが減り、ストーリーポイントなどの見積もりも自然と揃ってくることがある。また実際にチームがストーリーに着手した際も誰かしらストーリーの詳細を把握している人がチームにいることが期待できる。

Q: スプリントプランニング1でチームに自由に取らせると偏りが出て、得意なものばかりやるのでは?

A: あるチームが優先順位の高いストーリーばかりを担当するなど、スプリントを始めるにあたって課題がある場合、プロダクトオーナー・他チームとストーリーの交換など調整をすることになる。この時に「得意じゃないけど、担当できる」ストーリーが割り当てられることになるので、スプリントを長く続けていると偏りは出にくくなる。

Q: スプリントプランニング2は共有スペースで行うの?

A: その通り。複数チームで行う時は広い場所で行う。大きい会議室、食堂など。

計画時に他チームと調整が必要になった時にすぐに話せるようにするため。 リモートサイトのチームがあるときはスプリントプランニング2の時はテレビ会議を繋ぎっぱなしにし、部屋のある一角に移動したらすぐに話し始められるようにする。


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法