« 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける | トップページ | なぜユーザーストーリーによる要件定義にピンとこなかったのか »

2020/12/27

大規模スクラムはLeSSとSAFeのどちらが良いのか

LeSSとSAFeの違いの記事のリンクをメモ。
僕にとっては理解しやすかった。
記事から一部引用している。

「エンタープライズ・アジャイル」LeSSとSAFeどちらを選択すべきか。その違いと比較。 ? 変化から進化の物語へ/(株)Salt

LeSSは最大8チームまで。
8チームを超えるとLess Hugeになる。
LeSSはスクラムを忠実に大規模チームへ拡大している。

(引用開始)
基本的にチームが分かれていても、一つのバックログで対応します。そしてそれぞれのチームの代表が(Scrum of Scrumと同じく)、スプリントプランニングやレトロスペクティブ(振り返り)を行い、それと連動する形で、各チームもスクラムのイベントを行います。
新たな製品やシステムを開発する場合、それがどのくらいの規模感でどのくらいのチーム編成になるか、最初はわからないケースが多いと思われます。
そこでLeSSでは、まず少数のチームでスプリントを回しながら全体の計画をつくっていきます。
したがって、柔軟なチーム編成ができる組織づくりが必要となります。
日々行う業務は、スクラムでやっていることと殆ど変わりません。スクラムに慣れている組織なら、比較的スムーズに実行が可能であると考えられます。
(引用終了)

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意」でも、大規模スクラムはLeSS一択です、と記載されていた。

一方、「SAFeは4つのレイヤー(レベル)でマネジメント」する。

(引用開始)
上位のレイヤー(レベル)で、ユーザー要求や設計を行い、下位のレイヤー(レベル)で開発を行います。プログラムレベルとチームレベルの関係はScrum of Scrumに近いです。
階層を持つことや、設計(上流)と製品開発(下流)が分離しているところから、ウォーターフォール的なエッセンスもあり、「これはアジャイルではない」という声も聞かれます。
反面(特に日本の)SIerが現在の組織体制をそれほど変えずにアジャイルに取り組むフレームワークとして取り掛かりやすい一面も見逃せません。
(引用終了)

More Effective Agile」では、SAFeが推奨されていた。
理由は、「More Effective Agile」のP.134に記載されているように、Scrum of Scrumは上手く機能しない場合が多いからだ、と著者は言う。
Scrum of Scrumを選択することで、プロセスと全体的なワークフローを調整しようとするが、実際は、要求となるプロダクトバックログに問題が起きやすい。
一般的に、Scrum of Scrumにはスクラムマスターではなく、プロダクトオーナーを出席させて要求を調整した方が良い、と言う。

記事では、下記の結論を出している。

(引用開始)
LeSSとSAFeどちらが自分の組織に向いているのか。
LeSSは、アジャイル本来の目的である自己組織化組織、自律的なプロジェクトに向いています。またイノベーションも起きやすいでしょう。
ただし、上流工程に関する手法があまりないため、特にチームが増えると全体像が見えなくなる不安はあります。
この場合、後述のICONIXとの組み合わせは、組織やシステムのダイナミズムを失わせないで、全体像を見ることができる方法論です。

一方で、大企業のSIer等が既存の組織をできるだけ変えずがリスクをできるだけ少なくすることを考えるとSAFeが向いていると思います。
反面アジャイルの根幹であるAgility(俊敏さ、柔軟さ)が失われやすく、特に経営陣やビジネスサイドが硬直化すると、変化に対応できなかったり社会や顧客に合わないシステムが出来上がってしまう可能性はあります。デザイン思考を取り入れるなど、顧客や社会情勢の変化にうまく対応できるかどうかが成功の鍵となります。
(引用終了)

僕の感想は、日本の企業ではSAFeの方が大規模アジャイルを実践しやすいだろうと思う。
日本の企業は組織文化が独特の価値観を持ち、正直柔軟ではない。
アジャイル開発を実践してすぐに効果を出したい場合は、組織構造や組織文化をいじる必要性が少ないSAFeの方がリスクは小さいだろう。

しかし、小規模なチームでスクラムが成功した経験がなければ、いきなり大規模アジャイルに挑戦しても失敗する。
LeSSのように、小規模なスクラムチームが8個以上準備できた後で、大規模アジャイルに挑戦すべきだろう。
LeSSであれば、スクラムの大規模化は運用しやすいのではないか。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」と「SAFe 4.5のエッセンス―組織一丸となってリーン‐アジャイルにプロダクト開発を行うためのフレームワーク Amazon」を今度読み比べてみようと思う。

|

« 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける | トップページ | なぜユーザーストーリーによる要件定義にピンとこなかったのか »

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける | トップページ | なぜユーザーストーリーによる要件定義にピンとこなかったのか »