LeSS (Large-Scale Scrum)の原理原則ってScrumの原理原則って言ってもいいぐらい良いね

1桁人数でチームを組むScrumと、ART一本50人のSAFeを中心に今まで勉強してきていて、その間にあるLeSSやNexusなどについて概要しか知りませんでした。そんな折にスクラム実験室コミュニティの方でLeSSの概要と事例紹介というめっちゃ良いイベントがあったので参加してきました。

大規模スクラム(LeSS)の概要と事例紹介/Doneの定義 (2020/12/11 19:00〜)

LeSSの概要を説明いただく中の「LeSSの原理原則」が、LeSSの原則に限らずScrumの原則として取り込んでも良いぐらい大切なことばかりだったので説明いただいた内容とスクラムでもどう重要かの自分の考えを共に記していきます。

システム思考＆プロダクト全体思考

部分最適ではなく、システム全体を最適化していく考え方が大事です。部分視点は狭い視点になっている時に陥りがちです。チームがプロダクトの全体、ひいてはプロダクトだけでなくプロダクトを使う上での一連のUXを理解し、カイゼンしていくことが大切です。部分最適がユーザーに与える影響は軽微なものですし、ユーザーはプロダクトの一部だけ買うわけではありません。システムモデリングを使いシステムの関係性を把握しましょう。

少なくすることでもっと多く

「少なくすることでもっと多く」とはどういうことでしょうか。例えば、LeSSはScrumをスケールするために必要最低限のロールしか追加していませんが、これはロールを必要以上に増やすことでロールごとの責任が減ってしまうことを指します。Scrumでも同じで、スクラムガイドに定義されている以上のロールを導入することで、それぞれのロールの責任の範囲が不明確になってしまいます。例えば、プロダクトオーナー補佐というロールを導入するチームが居ますが、そのロールの責任の範囲が明確になっているでしょうか。開発者の中でテックリードを置くことが、他の開発者の責任にどういう影響を与えるか考えたことはありますか？

顧客中心

顧客の本当の課題を学び、解決することこそが顧客中心主義の考え方です。プロダクトアウトになっていて自分が作りたいものを作っているのはよく陥りがちな罠です。あるいは、顧客のことを考えながら作っていてもアウトプットばかり気にして顧客にとってのアウトカム（価値）を意識できているでしょうか。

完璧を目指しての継続的カイゼン

カイゼンを続けていくことはもちろん大切ですが、LeSSの原理原則にある「完璧を目指して」というのがとても良い！自分たちにとっての「完璧」がどういうことなのかを常に考え続けます。そしてその状態に向けてカイゼンのために実験を繰り返します。目指すべき「完璧」が、チームの理想なのかユーザーにとっての理想7日、「何」の「完璧」なのか。チームの完璧か、プロダクトの完璧か、組織の完璧か。

リーン思考

House of Leanの土台、柱、の上に屋根が正しく載せられる組織になっているかどうかですね。

待ち行列理論

自分たちの開発、従来の開発がなぜ遅いのか。その理由とそれに対して何をなすべきかをどう考えるか。すべてのことには適切なタイミングというものが存在します。今必要に思えても、実は1ヶ月後にはいらなくなるような機能を頑張って実装していませんか。あるいは、自分たちのプロセスの中に見えないボトルネックがないか。

終わりに

他にも元々Scrumにある理論と同じものがあったりしますが、リーン思考なんかはLeSSからScrumに逆インポートされたのでしょうかね。この日に聞いたLeSSの話で一番心に残ったのは、LeSSの作者が「LeSSは基本止めておけ、まずLeSSじゃなくてScrumで出来ないかを考えろ」的なことを言っていると聞いたことです。たしかに、すべてのことはスケールすることで複雑度が飛躍的に上がっていきます。それに対してLeSSはできるだけScrumそのままでいることで立ち向かっているのだろうなと感じました。