アジャイルをスケールしたいときの注意点

人間だれしも大きいものが大好きなので、大きいままやってもムダじゃね、な精神から生まれた(嘘)アジャイルもスケールさせようとするのは、ピラミッドや天守閣が巨大化していったのと同じくらい自明なのでしょうがない（諦め）

で、大規模アジャイルがクソ扱いされる場面はとてもよく見かけるし、大規模にしました！っていう場面もよく見かける。

昔そんなの書いた気はする。

身もふたもない結論で話をしていたけど、それでもやっぱり大規模にやりたいって人は後を絶たない。

（というかスクラムマスターが昇進したりして影響力を持つと大体そういうことをしようとすることが多い気がする。）

これまでに経験してきた 3~4チームといった小規模なものから、12,3チームといった規模のアジャイルプロジェクトを見てきて、いくつか大事なポイントは見えてきて、スケールしたときに考えるべき注意点ってことでまとめておきたい。そのうち忘れるので。

スケールしたときに考えるべき点は、主に以下の3つな気がしている。

① アジリティ

② エンゲージメント

③ 顧客理解

----

速くいきたければ一人で行け、のことわざではないが、取り組む人数が増えるほどスピードは下がる。

創業期は少ない人数でやりたいことがすぐに実現できたのに、チームや会社が成長して人が増えてきたら、何をやるにも時間がかかる（＝リードタイムが減る＝アジリティが下がる）ようになった、、っていうのをとてもよく見る。

つまりスケール時の注意点①は、

1チームでやってたときよりも、
バリューストリームのリードタイムが悪化していないか？

となる。（自分に刺さって死ぬ）

解決するための手段としては、Team Topology のような形での組織・アーキテクチャを設計することが組織的な取り組みとしてはベターな解な気はしている。

あとは書くな・話せ、の徹底とか。

規模が大きくなるほど、目的に対するエンゲージメントが低下しやすい。

社会的手抜きではないが、エンゲージメントを維持するのに多大なコストを支払う必要が出てくる。

解決策はいつの世も一緒なので割愛。

チームが増えるにしたがって、顧客の顔が見えないケースが非常に増えてくる。

XP でいえば顧客同席だったのが、Scrum になるとプロダクトオーナーを介するようになったり（話すなとは言っていないが話さないフォースを生みがち）、組織が大きくなると、PO すら営業やマーケ・カスタマーとしか話してない、みたいなことも出てくる。冗談のような悲劇（よく見る）

というわけで注意点③としては、

1チームでやってたときより、顧客とエンジニア間のコミュニケーションホップ数が悪化していないか？

になる。

結果として、顧客のことがわからん、何を作っているのかわからんが指示通りに作る、みたいなことがよく起きる。

結果として、PO がそう言ったんじゃないですかーとか、チケットに書いておいてくださいよ、みたいな内ゲバが起こりがち。何と戦っているんだ俺たちは状態。

解決策は、、、、、、、現場に行けとしか。

要は創業期の熱量やスピード感をスケールしても末端まで維持できてるか？がわかりやすい観点かもしれない。

とはいえそれらの指標がどれくらい悪化するか、悪化したところでどれくらい影響があるか、その分のメリットを享受しているか、はコンテキストによるので、目をそらさずに Struggle してね。

（PO だってうまくいっているからパターンなんだから。It Depends よ。）

海と山が好き