天の月

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

ZombieScrumSurvivalGuide読書会 #3に参加してきた

yasashii-agile.connpass.com

こちらの読書会に本日参加してきたので、会の様子と感想を書いていきます。

チェックイン

皆さんがどのように普段ノートを取られているのか、というのを聴いていきました。

途中からの参加だったので残念ながら参加者皆さんのテーマは付箋でしか確認できませんでしたが、以下のような意見が挙がっていました。

  • 仕事ではリアル付箋にメモを取る
  • 家で勉強する時にはキャンバスノートに書く
  • 自分にslackメッセージ
  • A4ノート
  • 基本的にはVSCodeで教科書使う系はGood Note5(iPad)
  • notion
  • Obisidian
  • Scrapbox
  • ほぼ日手帳
  • Confluence
  • Markdown形式でエディタにログ的な感じでメモ
  • スマホのメモ帳

会で話されていたこと

the discussion usually ends with the questions “What are the reasons people have for using the Scrum Framework in the first place? What are they hoping to get out of it?”の壁にぶつかっているので、どうやって、いつ決めるのかを聴きたい

以下のような意見が挙がっていました。

  • レトロスペクティブで話をみんなでする。「いいプロダクトをつくりたい」「給料を上げたい」など、協力することで達成できるような何かしら共通の目的ができるまでやってみる。
  • 人数が少ないと社長/副社長といった経営層からトップダウンで浸透しやすかったが、人が多くなると浸透しなかった印象があった。
  • スクラムの理解がなくても、何かしらお互いに共通して目指している所、合意できるところを見つける

皆さんが常に変化し予測できない問題をどう把握してトラックできる形にしているのか気になる

以下のような意見が挙がっていました。

  • ビジネス側が取得した数値の共有
  • レビューでステークホルダーの満足度をとって、トラックしている(インクリメントに対する満足度を測るGoogleフォームを配った)
  • Extreamな状況を想定して、ロールプレイ的にどのような問題が起こりそうか、というのを考えている
  • 皆で定期的にプロダクトのパトロール(ユーザから来ている問い合わせを眺める)をして、何か異変の兆候がないかを確認する。

実際にやらない人(隣の組織・隣のチーム)にスクラムのことや自分たちがやっているアプローチをどのように説明するか?

以下のような意見が挙がっていました。

  • お互いのギャップを見つけて、共通理解できるような部分を見つける
  • 個人的な経験だが、スクラム/アジャイルが分かっていないことが目的になった経験はない。
  • 問題が起きるまでは、スクラムアジャイルを理解していないことを問題として扱わない。
  • 朝会に代表者にだけ来てもらう

スクラムが効果的ではないと感じた場面はないか?

  • プロダクトゴールが可変な場合はスクラムが合わないと感じた。
  • 既存のシステムの改修で、手順が決まりきっていて、扱う問題がそこまでComplexではないように感じる時は、無理にスクラムでやらなくてもいいのではないか?と感じた。
  • レガシーなシステムで機能が充足している時は効果的ではないと感じる*1
  • チームが責任を取りたくない時、物事を自分たちで決めたくない時は効果的ではないと感じた。

全体を通した感想

今回も皆さんの意見をたくさん聴けて楽しかったです。特に、実際に皆さんが経験したお話というのを聴けるのは、読書会をはじめとしたみんなでディスカッションする系のイベントの個人的な醍醐味なので、実体験が多く聴けたのは良かったです!

*1:ただしRSGTでyotaさんがレガシーシステムリプレイスでスクラムが有効に機能した例を説明してくれていたので見てみてもいいかもしれない