2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14622
チーム参加してきました
aslead Agile のチーム「オキザリス」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。
スケールの話
スケール＝大きさの尺度
スケールというとすぐ大規模に結びつけがち。
大きいことってどういうこと？
スケーリングの手法
SAFe, Scrum@Scaleなどが多数。
- SAFe
- LeSS Huge
- Scrum@Scale
- Spotify Model
大規模でスクラムやるって考えると、上層部がこれをもってくる
- Nexus
シンプル。スクラムに近い。
じゃあ、どこから始めたらいいの？
なぜスケーリングする必要があるの？
数を増やすことで目的の達成が容易になるのか？
数を増やすことで、経済的に合理的になる場合にのみスケーリングする
ここまでのアジャイルのFWはは開発側・提供側の絵しかない
スケールしたいものはなに？
- 人
- プロダクト
- 顧客満足
- 金
- 世界平和
結局人を増やすけど、プロダクトインクリメントは増えない。
次にプロダクトインク路面とを増やすと顧客もお金も離れていく。
結局ここまでの例は膨張しているだけ
実はすでにアジャイルマニフェストの原則に書いてある
シンプルさ
「最大限やらずに済ます技術」は必須。
ソフトウェアエンジニアが目的を理解せずに実装しようとする
→コピペプログラミングする。（これっていいの？）
じゃあ組織もコピペする？
自然界でのコピペ→ビスマスの結晶、ロマネスコ（ブロッコリー）
じゃあ組織はどうやってスケールする？
Alejandro Aravenaのハーフハウス
Before:
After:
差はどこから来るの？
- クネビンフレームワーク
- スクラムの主な適用領域
- 複雑な問題から煩雑な問題により分ける
カスタマーオブセッション
顧客に価値を提供するならば、会社のカタチを変えることもいとわない
小さなチーム
- 意思決定の遅延を最小にする
- 顧客価値にこだわる（手段を選ばない）
- チーム間の相互学習を促す（地検の素早い共有によって、遅延をさらに減らす
- あのチームでできることを、このチームでもできるようにする
事例は？
- アジャイル・コミュニティ
- オープンソース・コミュニティ
知識をすぐに共有する。
依存関係
- 同期的に依存しないようにする
- 非同期に助けを求められるようにする
スケーリングを考える前に
あなたの組織に、よいスクラムチームが複数いないのであれば、まず良いスクラムチームを育てるところから始めましょう。
その次に、組織の学習を支援しましょう
- うまくいっているやり方を盗みやすくする
- 良いスクラムチームたちが、チームの学びを組織に伝えやすい環境を用意しましょうしましょう
- 学習構造に基づいて、学習のネットワーク構造が成長を助けましょう
- 時間はかかります、粘り強く
まとめ
- スクラムのスケーリングは、
- まず組織内の学習の相互移転を促すところから
- 個々のチームは可能な限り小さいままを保つ（判断のレイテンシを小さく）
- スケールフリーネットワークは生成するもの。生成を支援はできる。
- どのスケーリングフレームワークを使うか考えるのは、それからで遅くない。
- 顧客満足・金・世界平和をスケールしたい
QA
- スケールしろという圧力がある
- やりたいことが多くてチームが増えるならばいいと思う
- １つのプロダクトに対してチームが増えるというのは要注意。顧客価値が見えていない可能性がある。
感想
- 意思決定の遅延を最小にすることで、スピーディに業務を行うことができ、その結果より多くの価値を生む出すことができる。これはビジネスの本質だと思った。
- 組織の学習移転の仕組みをいかに作るか。これが肝だけど、なかなか理解・な得してもらうのも難しい。チームオキザリスが、その模範になっていきたいと思う
- たしかに意思決定は遅延が大きくなりがち