天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「脱!なんちゃってスクラム」実践事例から学ぶ Lunch LTに参加してきた

findy.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

アジャイル開発の1つのフレームワークであるスクラム。昨今では、アジャイルコーチやスクラムマスターの役割も一般的になりつつあり、実際に取り組む組織も多くなっています。その一方で、「スクラムを実践しているがあまり上手くいっていない」「イマイチ成果につながっているかがわからない」といった声も聞かれます。本イベントでは、各社でスクラムに取り組まれている方々、スクラムマスターやアジャイルコーチとして活動されている方が登壇。参加者の方にとって学びとなるイベントを目指します。

会の様子

以下、LTごとに話されていた内容を記載していきます。

1人だけ知ってても回らないスクラム

デイリースクラムを題材に、チームの中でスクラムイベントの理解や目的がばらばらな中でどういう風にしていくとよいのか?という話がありました。

知識が足りない状態でも、なんとなくで話をして解釈を作り切ることも「できてしまい」ますが、そういうときにはなんとなくの解釈の違いがあるまま進めるのではなく、チームで共通の定義を作るとともに、足りない知識を輪読会などで吸収するように工夫をしていくことが重要だというお話でした。

現職と前職で感じたスクラムの違い

前職と現職で同じスクラムを経験したのに感じた違いの話がありました。

前職では、ステークホルダースクラムに参加していなかったり、プラクティスをただ実施するような流れだったのに対して、現職では、偏愛マップやムービング・モチベーターズといったワークショップを通してチームの関係性を構築したうえで、実例マッピングなどを活用してステークホルダーを巻き込み、実装にかける時間が前職と比べて大幅に短くなったという話がありました。(手戻りが少なくなった印象があった)

ただし、前職のスクラムがひどかったことを伝えたいのではなく、熟練度がない中で精一杯やった結果だったと思うということです。

スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜

最初になんちゃってスクラムになっている兆候がある事象とその対策として、

  • スクラムガイドを読んでいない(スクラムのHowではなくスクラムの考え方をスクラムガイドで学ぶ)
  • 時間効率ばかりを意識したファシリテーション(時間内に終えることではなく目的に沿った会話ができているかを観察する)
  • チーム内だけで自分たちはいいチームだと言っている(第三者からパフォーマンスのレビューをもらう)

の紹介がありました。

ログラスでは、ワンチーム→チーム分割→スケーリングという流れでスクラムをしていたそうで、直近は高い自律性と組織の流動性を考慮してFASTなどを活用してスケーリングをしているそうです。

300人の組織でスクラムを運用するための考え方

300人の組織だと、チームの種類に多様性が出たりスクラムチームとnotスクラムチームが混在したり、チームで働いていない人も出てきたり、色々な人が色々な働き方をするようになってくるという話が最初にありました。
そういった組織では、スクラムを厳密に運用することはゴールではなく、組織として価値を届けるためのベースとして捉えているということです。

サイボウズではこうした考えのもと、

  • 自己管理型チームを組織の基本単位にする(機能するチームの基本の型を定義し、外部にも公開)
  • チームを健全にするためのスクラムマスターを増やす(スクラムマスターの職能化)
  • 組織の目標に沿って各チームが自律的に活動するための仕組みづくり(組織の方向性との合致性などが課題になってくるので、そこに向けての対策をしている。詳細はRSGT2025のプロポーザルに記載)

に具体的に取り組んでいるということでした。

会全体を通した感想

どれもダイジェスト版のような感じだったので、細かいところまで聞きたいなあとは思いましたが、会のタイトルにある通り、実践的な事例が話として聞けて、非常に満足度の高いイベントでした。