アジャイルをスケールするためのフレームワークはたくさんある。これに対し、組織をデスケールするという考えがある。Odd-eのアジャイルコーチであるViktor Grgic氏は、自身のブログにおいて、LeSS (Large-Scale Scrum) を使って組織をデスケールすることについて語った。
LeSS (Large-Scale Scrum) の第一の目的は、組織の変化を通じて実際にデスケールすることです。役割の数、組織構成、依存関係、アーキテクチャの複雑さ、マネジメントのポジション、サイト、人の数をデスケールするのです。LeSSはひとつのチームを複数のチームにスケールするためのものではありません。LeSSは組織のデスケールを実現するために、スクラム自体をスケールアップするためのものです。
TrustArtistのトラストアーティストおよびアジャイルコーチであるOlaf Lewit氏は、InfoQとのインタビューでこう説明した。
デスケールするというのは、組織内の役に立たない要素を特定し、少しずつ互いに信頼していくことです。人は信頼されると、選択肢が増えます。したがって、第一のステップはもう少し信頼することです。第二のステップは人に選んでもらうことです。そうすることで、あなたは少しずつ組織を解き放つことができるでしょう。
Synerzipの創業者でCTOのVinayak Joglekar氏はブログで、“Agile 2014”カンファレンスのスピーカーによるトークを引用して、アジャイルをスケールするために組織をデスケールすることを支持した。
Agile 2014カンファレンスで、多くのスピーカーが同じシグナルを発するのを耳にしました。「アジャイルをスケールする代わりに、組織をデスケールしよう」。会社の階層構造がうまく機能しなくなっていることに対して、Scrum of Scrumsのような新しいモデルを構築してアジャイルプロセスを合わせようとする動きが高まっています。モデルは厳密で直線的ですが、人間のシステムは非直線的であって、より柔軟性が必要になります。私たちはサイロと階層を減らすために、組織の再構成について綿密に検討する必要があります。
Victor氏は小さな独立したプロダクトを持つことについてこう語る。スクラムチームは彼ら自身のプロダクトを扱うべきだが、プロダクト全体の明確なビジョンを持つべきだ。ユーザや顧客も同様だ。偽の小さな「プロダクト」を扱うチームは、偽のユーザを持つ可能性が高い。「私たちのユーザは別のプロダクトであり、私たちの顧客はITアプリケーションマネージャです」。自称プロダクトは単なるアーキテクチャコンポーネントであり、他のコンポーネントは偽のユーザになる。
LeSS (Large-Scale Scrum) の共同作者であるBas Vodde氏はこう説明した。真の価値を提供しない「偽の」小さなプロダクトが複数あっても良くはならない。たくさんの小さなプロダクトのせいで、全体像を見失うだろう。
Victor氏は、単一プロダクトの場合、LeSS組織はポートフォリオや計画、プロジェクトマネジメントを必要としないと言う。別個の分析、アーキテクチャ、UX、QA/テストのグループも必要ない。おそらく別個のオペレーションのグループも必要ないだろう。彼はこう言う。LeSSにおいて、組織の基本構成要素は、職務横断、コンポーネント横断のフィーチャーチームだ。多くの人は単にフィーチャーチームの一員となり、スプリング毎に、動作するテスト済みのフィーチャーと出荷可能なプロダクトを提供する。
LeSSはスケールアップしたスクラムフレームワークであり、組織のデスケールを可能にします。