大規模アジャイルのヘルスメトリクス〜Large-Scale Agile Health Metrics
2023年のLeSS Conference BerlinでLeSSの考案者の一人のBass氏の講演を視聴したので、その紹介と自分なりの理解をまとめてみました※1
Conferenceの内容は公開されているので、誰でも見ることができます。（コロナ以降のこういうイベント動画公開の流れは、家庭の事情で参加できない勢としては本当にありがたい！）
Bass氏の動画は以下。サイト内の「Video Recording」から閲覧できます。
TL;DR
時間がないので大規模アジャイルのヘルスメトリクスだけ手っ取り早く知りたいという方のために、メトリクスは以下です。
- ちょうど１スプリントよりも長く存在するバックログの量
- エンドユーザーが追加説明なしで理解できるプロダクトバックログアイテムの割合
- 開発者1人あたりの1日のコミット数
- トランクへ直接コミットする割合
- スプリントで選択されたPBIのうち、前回のスプリントレビュー前には存在しなかったPBIの割合
- スプリント終了時の着手済みの未完了アイテム
- スプリントごとに進行中の祖先
- 全チームがオフィスにいる週の日数
- 完成の定義
メトリクスを見て興味が湧いた方はぜひ続きを読んで見てください。
大規模アジャイルのヘルスメトリクスについて語る目的
講演の中で、通常は特定の指標については話していない、メトリクスに関する組織のダイナミクスと、メトリクスが組織内でどのように使用されているかに興味があるからだと言っています。また、ほとんどの場合、メトリクスが組織内でどう使われているかが問題であって、メトリクス自体ではないからとも言っていました。
自分の体験としても、メトリクスを設定したはいいけど、達成目標のように扱われ始め、組織内のコミュニケーションを余計にややこしくしている例に出くわします。
今回メトリクスについて言及した目的を以下のように言っています。
WHY
1. Quick identification of potential problems in product development dynamics.
2. Provide a starting point for discussions on product development dynamics
3. Be able to answer corporate demand on metrics in the least harmful way.
4. Suggest metrics to also measure non-Less agile adoptions
- 製品開発ダイナミクス内の潜在的な問題の迅速な特定
2. 製品開発ダイナミクスに関する議論の出発点を提供
3. メトリクスに関する企業の要求に最も害の少ない方法で答えられる
4. LeSSではないアジャイルの採用にもこのメトリクスを提案
LeSSではない大規模の製品開発を行う活動についても、気づきや議論のきっかけを提供できるメトリクスということで紹介されているようです。
勝手な解釈ですが、SAFe®に今回のメトリクスを当てはめたらきっと良い結果が出ないので、暗にSAFe®を採用している大規模開発チームへ示唆しているのかなと邪推してしまいました。
では、さっそくメトリクスの紹介に行ってみよう。
1. ちょうど１スプリントよりも長く存在するバックログの量
Amount of backlogs that exist longer than exactly one Sprint
Bass氏がよく見かけたことの一つに、スプリントプランニングではなく、リファインメント中にスプリントバックログを作成しているチームがいるという話がされていました。
なぜこれを計るかというと、本来であれば変化に適応するために、実装する直前までの新鮮な情報を使ってスプリントプランニングで計画してタスクを作成するところを、実際に実装するよりも前のリファインメントで既に計画してタスクを作成していることに問題があるからかと思います。
スプリント終了に間に合わなかったり、焦ってしまうことを恐れるあまり、「計画に従うことよりも変化への対応」をおろそかにしています。
例えば、前のスプリントで次のスプリントで行いそうなバックログアイテムのコードを調査していたり、設計を始めていたりするチームがそれに当たります。
皆さんのチームはこのメトリクスはどうなっているでしょうか？
2. エンドユーザーが追加説明なしで理解できるプロダクトバックログアイテム(PBI)の割合
Percentage of items in Product Backlog that your end-user can understand without additional explanation
個人的にはめちゃくちゃ“とんち”のきいたメトリクスという印象。
LeSSのサイトにはCustomer Centricに関するページが設けられています。
小さいチームが顧客中心に開発を進めることはできたとしても、大規模になってもそれをやり続けることができるか？LeSSの課題は、規模を拡大してもなお、どのように顧客志向を維持するかだとサイトに書かれています。
まさに、それができているかの洞察を得ることができるメトリクスになっています。
3. 開発者1人あたりの1日のコミット数
Commits per developer per day
これについても、LeSSのサイトにGrowing the Systemという解説ページがあります。そこでは、システムの構築(building)というのは、別々のコンポーネントを作り、完成したらそれらを組み立てることで、一方システムを成長(growing)させるというのは、システムを育てて、より大きなシステムへと進化させることだと記載されています。
そのため、このメトリクスの言いたいことは、何日もコミットせずに自分の環境で開発することは、コンポーネントを作って構築しているのではないか？ということを一つのメトリクスとして表現していると思われます。
4. トランクへ直接コミットする割合
Percentage of commits directly to trunk
メインブランチやトランクに直接コミットしないということは、きっとブランチやプルリクエストで開発をしているということになりそうです。そうすると小さく開発して育てるというよりは、最後に大きな塊を統合することになります。それは、常に動くシステムを維持することに背くことになり、それによって、全体で統合したときに動くかどうかの検査は先延ばしになってしまいます。
このやり方を実施する場合は、CIは必須でそれについてもLeSSで言及(Supported by a CI System)されています。
途中、クレイグ※2が”Not every team has own trunk”と言って笑いが起きていました。おそらく、全体トランクではなくチームごとにトランク持って運用しているという背景があって、その上でチームのトランクはブランチと一緒だろ！だからそれもだめだぞ！という皮肉で笑いが起きていたのかなと推測しました。
5. スプリントで選択されたPBIのうち、前回のスプリントレビュー前には存在しなかったPBIの割合
Percentage of items selected in Sprint that didn’t exist before previous Sprint Review
講演では、これはアジリティ指数(the agility index)と呼んでいるそうで、前回のスプリント前には存在しなかったアイテムがこのスプリントに入っているか？ということのようです。
これが耳の痛い話のチームもありそう。スプリントレビューでのフィードバック（検査）が行われておらず、事前に固定された計画どおりに作ったものを、ただデモするだけになっているチームはこのメトリクスは低くでてしまいそうです。
さらに、クレイグが追加で、
this is also the percentage of items in PBR that didn’t exist at the last Sprint review.
前回のスプリント・レビュー時に存在しなかったPBRのアイテムの割合でもある。
と言っていました。スクラムチームが事前に作られたプロダクトバックログの生成工場になってしまっていないか？をチェックするメトリクスになりそう。
このメトリクスのアイデアは以下に詳しく紹介されていました。
Terry’s Agility Index
6. スプリント終了時の着手済みの未完了アイテム
Started but not done items at the end of Sprint
講演では、スプリントの終わりに着手済みアイテムを中途半端なままにしてはいけない、そしてそういったことが起こるチームは相互学習しておらず、密かにバッファを作っていると言っています。
（解釈が多分に含まれますが）スプリントの終りが見えてバックログが終わらないことが何となく見えているにも関わらず、チーム内での再計画や情報共有による学びなどが行われずに、中途半端なままスプリントの終わりを迎えてしまうチーム、または中途半端に終わることが悪いという意識があるため、そうならないようにスプリントでピックするバックログの数を少なくして密かにバッファを設けているチーム、そういったことが起こっていないかの議論を行うきっかけとなるメトリクスのようです。
工場ラインのようにいつも同じものを作っているわけではなく、不確実の程度はあれ、毎スプリント異なるものを作っているため、スプリントの終わりにピックアップしたアイテムがいつも全てきれいに終わるわけがありません。そんなときに、チーム内で何もせずただ中途半端にスプリントの終りを迎えるチーム（相互学習が起こっていないチーム）なのか、あらかじめ毎スプリントきれいに終わらないことを見越して、少し少なめにバックログアイテムをピックアップするチーム（密かにバッファを設ける）なのか。
そうではなく、相互学習が行われているチームでは、スプリント最終日が近づいたらスプリントがどんな終わり方をしそうかチームの認識を合わせて、終わり方の再計画を実施することが大切です。
全力でやったは良いけど、ローカル環境に書きかけのコードが残ったままなのは、再計画できているとは言いにくいですね。
7. スプリントごとに進行中の祖先
Ancestors in progress per Sprint
このメトリクスの意味するところは、製品全体を意識した開発を全チームで協力してできているかを計るところにあります。
通常バックログの先頭には小さなアイテムが並んでいて、その小さいアイテムは分割されて小さくなっており元々はもう少し大きなアイテムだったものがあったはず（これがこのメトリクスでいう祖先）。
複数チームで開発するにはお互いのチームの依存関係を減らして、お互いが独立して開発できるようにしたほうがうまくいくと考えられ、独立して開発するためには、この祖先となるアイテムが異なっていれば独立性も高くなるため祖先の異なるアイテムを各チームがピックアップすることになります。
ところが、このメトリクスはそうではなく、むしろ同じ祖先を持つ小さなアイテムを複数チームでどれくらい開発しているかを計るところに、意図があります。
要は、チーム間で依存関係のあるアイテムを開発することで、製品の特定の部分のみを各チームが意識して開発するのではなく、全チームが製品全体を意識し、コラボレーションし、さらには課題や解決策を検討しながら開発が進められているかを計るメトリクスとなっています。
このメトリクスの詳細な内容については、同じくBass氏の2022年のLeSS Conference Warsawの講演動画で詳細が話されています。
Maximizing Dependencies with Interdependent Teams
全チームがオフィスにいる週の日数
Amount of days per week with all teams in office
これはちょっと笑える皮肉なメトリクスです。
チームがオフィスに来たいときに来られるようにするのではなく、同時に全チームがオフィスにいる週の日数をメトリクスとするようです。
マネージャーや会社から強制的に出社日を決められて、全員が出社した日数ということもできるかと思います。
昨今、リモートワークが進みオフィスでの固定席も減る中で、全員出社しても対して快適にチームで働くことができにくくなっているにも関わらず、なぜか強制出社が設けられていないでしょうか？
完成の定義
Definition of Done
最後は完成の定義です。
ただし、講演ではこれについての詳細な説明はありませんでした。
I’m not going to explain that further for now except that unless we consider that a metric and an important one
完成の定義が指標であり、重要なものであると考えない限り、今はこれ以上説明するつもりはありません。
とのこと。
（ここからは解釈ですが）完成の定義は、組織やチーム内であいまいになりがちな完成という品質をあいまいなことにせず、組織として完成とはどういうことで、それが達成されていればユーザーに届けることができる品質基準になります。
その完成の定義を運用できていない場合や、アンダンワーク(Undone work)※3を減らす活動をせずリリーススプリントを持ち続けている場合、それ自体がメトリクスとして機能するのではないでしょうか。
参考までにLeSSのDefinition of Done.
まとめ
2023年のLeSS Conference BerlinでLeSSの考案者の一人のBass氏の講演を自分なりに解釈してまとめてみました。
製品開発のダイナミクスに着眼して、大規模開発でも迅速なフィードバックが回っているか、大規模チームになってもコラボレーションが行われているかなど興味深いメトリクスがたくさんありました。
気を抜くと思考がコンフォートゾーンに言ってしまいがちで、チーム間の依存関係をできるだけ減らそうとしたり、大規模だからある程度事前に計画されたバックログをしゅくしゅくと開発するほうが良いという考えにいきがちですが、あくまで大規模でもスクラムを実践するLeSSらしいメトリクスになっていたかと思います。
来年は、また現地参加してみたい（英語がどこまで上達しているかによるなw）
※1 訳は、動画から聞き取ったり文字起こしの英語を訳したものになります。間違っていたらご指摘いただけると助かります。
※2 LeSSの考案者のもう一人
※3 完成の定義と実際に出荷するまでに必要な作業に差分があるならそれはアンダンワークと呼ばれます