この記事はフリューアドベントカレンダー2023の記事になります。
はじめに
弊社では以前、開発部門でスクラムの拡張フレームワークであるLeSS（Large-Scale Scrum）を導入しました。
現在はLeSSを使ってないのですが、今回は当時の導入背景と、そこで得られた知見について書こうと思います。
LeSSを導入した背景
LeSS導入前の課題
LeSSを導入する以前の開発体制は以下のような体制でした
機能追加などを行うスクラムチームと、技術的負債の解消を行う非スクラムチームという、ミッションが違う２つのチームが同じプロダクトを触っている状態でした。
当然、２つのチーム間で綿密なコミュニケーションが必要となるんですが・・・
全然コミュニケーションがないんです・・・
で、どうなるかというと
↑のような状態が発生し、ちょっとした対立構造になっていました。
そして、当時片方のチームのスクラムマスターをしていた私は、チーム間の連携を強化することで、これらの課題を解決したいと思いました。
そのためにはまず
「お互いの作業の見える化と、コミュニケーションする仕組みが必要」
だと考えました。
非スクラムチームへのスクラム導入
まず最初に、非スクラムチームのスクラムを導入し、他チームからも作業が見えるようにすると同時に、スプリントを合わせることでチーム間で歩調を合わせるようにしました。
スクラムマスターは私が兼任している状態。
これによってお互い何をやっているのかは見えるようになったのですが、「見える」と「見る」はまた別。
スクラムチームが２つあったからといって勝手に連携するわけありません。
やっぱり仕組みが必要だなーって色々調べてたら、複数のチームでスクラムを回すためのフレームワークがあると知ったのと、当時のPOさんからLeSSってのがあるよって教えてもらったこともあり、自分の中で
意識せずに連携できるように、連携が仕組み化されている「大規模アジャイルフレームワーク」を導入しよう！
となりました。
今からしたら、この結論までのプロセスがめちゃくちゃ未熟だったと思っています。
あと、最終的にはどうやってうまく連携できるかより大規模アジャイルフレームワークを入れる事が目的になってた気がします。
LeSSの導入
POさんにLeSSを紹介されたとはいえ、大規模アジャイルフレームワークは色々あるので、LeSS、Nexus、SAFe、Scrum@Scale、Spotifyは比較してみました。
このあたりの比較内容については、機会があればどこかで書きたいと思います。
比較した結果、自分の中ではLeSSが一番理解しやすかったので、導入することにしました。
LeSSを導入した結果
LeSSは公式サイトが非常に充実しており、導入は比較的に簡単にできました。
そして、LeSSを導入したことで、全体プランニングやリファインメントなど、チーム間のコミュニケーションがより活発になりました。
そして
めでたしめでたし
んなぁ〜こたぁない！！
確かに・・・
LeSSを導入したことで、各イベントに参加すれば意識せずとも最低限チーム間で連携できるようになり、結果的にチーム間の衝突への対応時間や精神的な負担は減りました。
でも、やはりデメリットもありました。
LeSS導入によって起こったこと
減った分以上に増えた
LeSSを導入したことで、
- 全体スプリントプランニング → 約30分
- 全体リファインメント → 約30分
- 全体スプリントレビュー → 約30分
上記のイベント時間 × 2チーム分
２週間スプリントでざっくり３時間、イベントに使う時間が増えました。
全体のプランニングもリファインメントも、結局全員参加していたので、工数的には
3時間 ＊ 11人 = 33人時 ≒ 4人日 くらい増えたイメージです。
精神的負担が減ったと思えば、これくらいなら、まぁ許容範囲・・・
それよりも
メンバーが考えないといけない事がめっちゃ増えた！！
例えば、
- 今日の全体プランニング（リファインメント）に誰が代表として出席する？
- 今日の全体プランニング、代表者だけでなく全員で出たほうが良くない？
- 今回のレトロは一緒にやったほうがよさそう
- 向こうのチームのこのスプリントバックログアイテムの進捗どうなってる？
みたいなこと。
一つ一つは大したことない。数分で終わるようなものがほとんど。
ただ、
集中力が切れるタイミングが増える
コンテキストスイッチが増える
のが大きな問題。
当時の自分は、スプリントに集中できるようコンテキストスイッチを減らすために、mtgを減らしたり、スケジュールをデフラグしたり、割り込みを無くすことばかりに目がいってました。
30分のmtgでも30秒の会話でも、別の事を考えればコンテキストスイッチが発生するし、集中が途切れるというのに気付けなかった。
スプリント中に、開発メンバーから不意に出る「そういえば今日の全体リファインメント誰が出ます？」みたいな会話を、「連携を意識してる」くらいにしか思ってなかったんです・・・
その大規模アジャイルフレームワーク本当に今必要ですか？
この経験から得られた知見。
大規模アジャイルフレームワークに安易に飛びつかない
当たり前なんですけどね（笑）。
でも大事だと思います。
チーム間で連携するためにフレームワークを導入する前に、まずはPO同士がしっかり連携すればいいと思います。
そして、その内容をバックログに落とし込めればいい。
スクラムマスターや開発はそれをサポートする。
それが出来ている間はフレームワークは不要だと思います。
また、チームが増えてきたからフレームワークを導入するのではなく、PO同士の連携に限界が来そうな段階で導入を検討するのがいいと思います。
限界は組織や状況によって違うはずです。
検討する時期かどうかはスクラムマスターが状況をしっかり見極めましょう。
PO同士のコミュニケーションに限界が来る頃なら、大規模アジャイルフレームワークの導入によって得られるメリットは非常に大きいと思います。
最後に
大規模アジャイルフレームワークは、チーム間の連携を強化するための有効な手段です。しかし、導入にはメリットとデメリットがあることを理解し、慎重に検討する必要があります。
導入を検討する際には、以下のポイントを参考にしてください。
- PO同士のコミュニケーションが十分に行われているか
- チーム間の連携に限界が来そうな段階か
- チーム間の連携を強化することで、メリットがデメリットを上回るか
これらのポイントを踏まえて、自社にとって最適な導入タイミングと方法を検討してください。