LeSS morning #2 参加記録

昨日(2/2)開催されたイベント「LeSS morning」に参加してきました

今回はLeSSの作成者の一人であるBas Voddeさんが来日したところに合わせて企画されたイベントらしい。まだ第二回だと言うのに早速LeSSの最重要人物から話が聞けた。

OST

Basさんが来るのが21時頃。それまでの時間は参加メンバでOST（オープン・スペース・テクノロジー）をしていました。私が参加したのは、メンバーを外部セミナーに参加させたい／学習する組織にするには。という2テーマ合同のテーブルでした。
いろんな話が出ましたが、印象に残ったのは。
・カンファレンス終了後にアフターケアをしよう
・カンファセンスの前にもオンボーディングをしよう
でした。やりっぱなしじゃ、また来ようとは思わないよね。

Bas Vodde - Large-scale Agile Health Metrics

• LeSS Conferenceの動画見た人いる？それと同じ話だよ。

• パフォーマンスや顧客価値を測るものじゃないよ。

• なぜHealth Metricsを使うのか？

  • 問題点を見つけること（プロダクト開発のダイナミクスにおける潜在的な問題を素早く見つけるため）

  • 対応を考えることができる（プロダクト開発のダイナミクスについての議論を出発点を提供できるため）

  • 組織はメトリクス欲しがるので、こちらから提示できる（最小限に害を抑えた方法で、企業が要求する指標に答えることができる）

  • LeSSではない働き方をしていると良い値を出せない指標を提供する

amount of backlogs that exist longer than exactly one Sprint（1スプリントより長く存在するバックログの数）
1以上だと危ない。
LeSSはHugeだったとしてもPBLはひとつ。エリアPBLも元のPBLの絞り込みでしかない。チームバックログやチームPOがいると、チームがリファインメント中にSBLを作り始める。Mixチームでリファンメントでこのようなことは起きない。データサイエンティストPBL、改善PBLなど。PBLを分けると、どのPBLからどれくらい持ってい来るかの割合など考えないといけなくなる。共同作業を阻害する。
また、〇〇〇〇を使うときにもよく起きる。〇〇〇〇はスプリント開始前にタスクを作れてしまう。〇〇〇〇はScrum、LeSSが上手くいかないように作られている。少なくともSBLは〇〇〇〇を使うのはやめましょう。

percentage of items in Product Backlog that your end-user can understand without additional explanation（説明なしでエンドユーザーが理解できるバックログの割合）
100％は難しい。100%だとすると技術的なアイテムがない可能性がある。だいたい0％が多い。理由はプロダクトの定義が狭いからだ。

commits per developer per day (開発者ごとの1日にコミット数）
開発の健康指標。小さく仕事しているか？CI、TDD、TCR、TDRができているのかも見ることができる。10くらいが良いが、大体0.2くらい。

percentage of commits directly to trunk（トランクに直接コミットする割合）
ブランチもプルリクもしません。これらはCIを阻害します。プルリクしてマージ待ちになるなんて、、、5分話せば済むでしょ？
レビューはコミットしてからでもできるでしょう。モブならレビューも不要だし、金曜日の夜集まってレビューしてリファクタすればよい。70%が理想。100％は無理だと思う。プルリクも場合によっては必要。よく知らないコンポーネントを変更したときに誰かに見てほしいことがある。選択できることが大事。

percentage of items selected in sprint that didn't exist before previous Sprint Review（スプリントで選択したアイテムの内、前回のスプリントレビューより前に存在しなかったのアイテムの割合）
テリーズインデックスと呼ばれる。SRが上手くいっているか？を見ることができる。100%が続くのはダメ。プロダクトの方向性が変わったときなどは起こりえるが。多くの場合0％。スコープは固定。一年前に決まっている。Feedbackをもらっても一番下。

started but not done items at the end of sprint（着手したけど完成しなかったアイテムの数）
チームが共同責任を負っているのかを見ることができる。WIPが1なら起きない。タスクを細かくして、チームのコミュニケーションがとれていれば起きない。1人1タスクのDailyだと、相手のことを知る必要もない。
自分の得意な領域だけをしていると、この値は高くなる。0にしようとすると学習を進める必要が出てくる。この指標を使えば学習を促進できる。

ancestors in progress per sprint（スプリントごとに進行中の祖先）
エピック（この言葉は嫌いだが分かりやすさのため使う）レベルでまずはｐBLに登録される。3つくらいあったとする。時間が過ぎると、分解され細かくなる。（どんなアイテムも無限に細かくできる手法があるが、そのうち細かくすることに意味がなくなる）アイテムごとに一世代前の情報を持ちどこから来たのかわかるようにする。アイテムの関連性を見ることができる。同じ先祖であれば関連は強い。
1なら全てのチームが関連性の強い仕事ができている。5チームいて5の場合、全てのチームは関連性の弱い仕事をしている。チーム間の共同を示す指標となる。1が望ましいように見えるがPOがひとつのことに注力してしまっている可能性がある。ちゃんと順位付けをしてない。
1< x < チーム数が良い。

amount of days per week with all teams in office
同一拠点（チームは同じテーブル）で働いているかの指標。リモートの悪影響が指摘されているが、コロナがあり5にはならない。6，7だと問題ですがね。日を決めてやりましょう。

Definition of Done
チームの能力を測る指標だと思います。おっとここで時間だ、また次の機会に！

まとめ・所感

LeSSのメトリクスということだが、ものによっては普通に1チームでも使えそう。TCR,TDRという用語も知らんかったので今後調べてみたい。リモートの悪影響も分かるが、指標の一つとなるほどのものなんか？という疑問がある。ここももうちょっと掘りたい。