【最近の悩み】スクラムチームをスケーリングする方法
私の担当ではスクラム型アジャイル開発手法を採用しているのですが、今、大きな壁にぶつかっています。その壁とは、「複数のスクラムチーム間でのノウハウや情報の共有が上手くいっていない」ということ。
スクラムチームが一つの時は上手くいっていた
私の担当は、1年前に発足したばかりの新組織で、その当時はスクラムチームが一つだけ。人数も最小構成の5人。
<当時の体制>
プロダクトオーナ:1人(私)
スクラムマスター:1人
エンジニア:3人
(プロダクト開発だけでなく、インフラの仕事もすべてこのスクラムチームが担当していたため仕事量が多すぎるという問題はありましたが)全員が同じ部屋で仕事をしていたため、ノウハウや情報の共有は特に意識せずともできてました。
あっという間のスクラムチーム拡大
トライアルとして実施したアジャイル開発の結果は上々で、アジャイル開発向きの案件も豊富にあったことからあっという間にスクラムチームの体制は拡大していきました。
<現在の体制>
プロダクトオーナ:3人
スクラムマスター:3人
エンジニア:15人
現在、スクラムチーム数としては3チーム。当初5人だったメンバーも、20名強まで拡大。これに加え、現在はインフラチームも別に存在。
スクラム経験も数年から未経験まで様々。
複数のスクラムチームを運営してみての課題
課題、それは、複数のスクラムチーム間でのノウハウや情報の共有が上手くいっていないということです。
各スクラムチームが働く場所が物理的に離れていることも大きな要因ではあるのですが、各チームが日々学んだノウハウや反省を共有することができず、同じ轍を踏むケースがちらほら。
スクラム型アジャイル開発はあくまでチーム内に閉じたフレームワーク。複数のスクラムチームでどう情報を共有するのか、効率よくスクラムを運営していくのかはまた別の次元。
これからどうしていくのか
嬉しいことに、来週から私の担当はフロア移転を行います。全てのスクラムチームが同じ場所、同じ空間で働くことができるように。
また、複数のスクラムチームを効率よく運用するためのフレームワークとして、スクラム・オブ・スクラムなるものも。
これらも参考に、私たちなりの解決策を見つけて改めてブログに書きたいと思います。大規模なアジャイル開発を実践している他社はどのようにやっているのか、とても話を聞きたい。
Product Owner at docomo / プライベートでもC向けWebサービス作ってます / 元 #入江開発室 / #nyan / SketchやXd、Figmaなどのデザインアセットのシェアサービス #collin