スクラムチーム間のナレッジ共有はじめました

こんにちは、技術戦略部のやすだです。
弊社では今年の年明けあたりからスクラムマスターが集まってナレッジを共有する取組などを行っています。

企画回も含めて今月で3回目。そろそろブログで公開しても良い頃合いなのではないかと思います。
というわけで今回はスクラムのナレッジ共有についての紹介記事です。

最初に説明する点として、スクラムマスターの寄り合いとしての性質が強いです。
俗に言うスクラムオブスクラムやその導入に伴うアレコレには触れていないのでご了承ください。
スクラムオブスクラムについて知りたい場合は、「スケーリングアジャイル」や「大規模スクラム」などのキーワードで検索してみてください。

また、記事内ではスクラムの用語についての説明等は含まれていません。
用語の説明などはスクラムガイドなどを参照いただければと思います。

経緯

大所帯から超大所帯へ

2015年あたりからラクーンではユニットチーム制を導入しており、10年経過した現在も継続しています。
ユニットチーム制の詳細についてはリンク先の記事をご覧ください。

記事内では「17名の大所帯」となっているところ、今では技術戦略部総勢49名になりました。
ユニットチームも4人以上で構成されるチームができたり、ユニットチーム数も増えて12ユニットになりました。
当時と比較すると超大所帯です。

スクラム＠ユニットチーム

ユニットチームの多くはスクラム形式で日々の開発を行っています。

チームの状況は下記のように様々です。
* チーム内に認定スクラムマスターの資格を取得しているメンバーがいるチーム
* 認定資格は取得していないものの自身でスクラムを学んでいるメンバーがいるチーム
* スクラムマスターのロールを各メンバーが担うようなチーム

ラクーンの「スクラムオブスクラム」開始

上述の通りスクラムを導入しているチームが多く、チーム毎にナレッジが蓄積されていきます。
定期的に実施しているユニットチーム毎の状況共有などで「○○のやり方いいよねぇ」「ちょっと詳しく聞きたいよね」なんて話はあるものの、
深堀りするのにちょうど良い場が無くチームをまたいだ形での共有があまり進んでいない状況でした。

そこでスクラムマスターやスクラムマスターに近い立ち回りをしているメンバーが集まって、
ナレッジ共有や質問・相談を行えるといいよねというところから定例会議を設ける運びとなります。
ラクーンの「スクラムオブスクラム」の始まりです。

トピックス

これまでの挙がったトピックスから個人的に面白かったトピックスを下記で挙げていきます。

プロダクトゴールをどうしているか知りたい

スクラムガイド2020年版で導入された「プロダクトゴール」についての話題です。

プロダクトゴールを定義していないという話から、そもそもプロダクトゴールってなんだろうね？という話になったり議論が広がりました。
改めてスクラムガイドを見直すきっかけになったりするのでこういう話題は良いですね。
~~プロダクトゴールってなんだったっけ？のレベルで全然覚えていなかったのは内緒~~

議論でのアレコレ
- 現在稼働中のプロダクトではプロダクトゴール定義はしていなさそう
- プロジェクトではプロジェクトゴールを決めている
  - KPI達成
  - リリース
- 意思決定をするときの重要な支援になりそう

結果、サービス毎に「プロダクトゴールこのタイミングで定めてみませんか？」と促してみようという方針が出ることになりました。

どれくらいスクラム用語を大切にするべき？

スクラムチームによってはスクラムの用語を使ってはいるものの、実態としては別の用語を指しているというところから挙がった話題です。

スクラムチーム内で共通認識ができているとなんとかなってしまうものではあります。
ただし本来の意味について理解できると関連した用語やプラクティスの理解もスムーズになるので、個人的には大切にしたいと思っています。

議論でのアレコレ
- 課題が出た時に、用語含めて認識合わせを促すようにしてる
  - レトロスペクティブ＝振返りじゃないとかも言われるよね
  - インクリメントとか使ったこと無い
    - PO/SM/開発者くらいしかメインで関わらないので、他のメンバーに伝わらない
  - 言葉の理解は、スクラム理解の入口だよね
- 別の言葉を使うときは、POやSMが都度翻訳してスクラムガイドと照らし合わせる
  - 開発メンバーは少なくともしっかり言葉を理解することは必要そう

結論として、開発メンバーに理解不足の気配がある場合、レトロスペクティブなどで上げてスクラムマスターの役目としてレクチャーしようということになりました。

ベロシティどうやって計測してる？

リソース効率、フロー効率のどちらを優先するかという話題から挙がった内容です。

ベロシティはスクラムチームの状況を把握するための指標の一つですが、
具体的に何を計測しているのかはチームによって異なっていました。
計測しているチームをザックリ分類すると、デプロイを計測しているチームとスプリントバックログアイテムを計測しているチームという具合です。

議論でのアレコレ
- デプロイしたら計測対象
  - ストーリーポイント出してない
  - やるもの決めてやったかどうかで測ってる
- スプリント毎にデプロイできないケース
  - 難しかったり大きい案件だとズレちゃう
    - スプリントバックログアイテムを計測
    - ストーリーポイントで計測
- PJ毎にチームを作っているので測れていない
- 中長期的にはベロシティって上がって欲しいね
- 確約したものだけを終わらせる
- 大事にすべきはスプリントゴールだが、ベロシティは予測や計画に使えるので大事

こちらに関しては結論や方針が出ることはなかったのですが、アプローチの違いが見えて興味深い話題でした。

チームのこと教えて！

ユニットチームA

安定して成果を出していて、スクラムを上手く使っているチームの一つです。
どんな形でスクラムを取り入れているのか気になるチームだったので、こういう場で話が聞けるのは良いですね。

概要
- ガチガチにスクラムやってるわけじゃないよ
スプリント
- 1週間スプリント
イベント
- デイリー
- プランニング
  - プランニングポーカーはやってないよ
  - 誰が何するのか決める
    - 各メンバーが自身で判断してる
- レトロスペクティブ
  - 月1で実施
  - KPT
    - keepが多め
    - 適応って意味だとまだあんまり
- リファインメント
  - 都度実施してる
  - 個別にPOがフォローしてる
  - 目途が立ったら優先度を上げる仕組み
- その他
  - POがしっかり動くことができている
    - スクラムチームのから現場に対しての共有・説明
    - 起票者へのコメント促し
  - 依頼者がまとめてくれてる
    - 知識的なところは省いてる
  - スクラム用語は公式と乖離が出たりする
  - メンバー間の協働ってできてる？
    - 予定通りいかなかった場合は協働してる
    - 助けを求めるために、自主的に声を上げたり手を上げたりする
  - パフォーマンスが悪いみたいな話ってある？
    - PO的には技術部案件で差し込みが入ると遅く感じる
  - 新メンバーが入った場合ってどう説明してる？
    - オンボーディング中だから遅くなる話をしてる
    - 「2~3倍遅れるよ」とか

ユニットチームB

透明性の担保やタスクの可視化がかなり進んでいるチームの一つです。
加えて、守破離の守を意識していることもあり、社内で一番スクラムらしいスクラムを実践しているチームだと思います。

概要
- もともとスクラムやってた
- 守破離の守をやってるよ
- チームビルディングも意識してる
スプリント
- 2週間スプリント
イベント
- デイリー
  - ガントチャート眺めながら実施
- プランニング
- レトロスペクティブ
  - 議題を捨てちゃうともったいないので残すようにしている
  - 明るい感じでイラストつけてる
- リファインメント
  - デイリーで実施
  - 毎日1つ以上実施してバックログを綺麗にしている
  - 次のスプリントのために砕いたり
  - チケットでやることを変更したり
  - 計画からズレるケースとかの対応
  - 優先順位をつけるため
その他
- Lean Coffee
  - チーム全員で好きなときにやりたくなったらやる
- POへの負荷
  - PO自身が工夫して軽減しようとしてくれている
  - スクラムチームへの要求としてあがってきたりとかはしてない
- スプリントゴール定めてる
  - スプリントゴールを達成できなかったときの説明・対応ってどうしてる？
    - 遅れている場合など状況把握ができないケースがある
    - 自分から開示してもらえるようにするのが大事
    - ガントチャート上で期限を超過していれば自分から開示しやすくなる