スクラムガイドのモブリーディング #2 in Agile Shinano

7/24に開催した「スクラムガイドのモブリーディング #2」の参加レポートです！

今回はスクラムイベントとスクラムマスターにフォーカスして、スクラムガイドのモブリーディングとディスカッションを行い、理解を深めました！

テーマの背景（イベントページから抜粋）
- 前々回のスクラムガイドのモブリーディングでは、スクラムのロールとスクラムの理論にフォーカス
- その中で「スクラムマスター」について知りたいと意見がでました
- そして前回、OSTでスクラムマスターについて議論しました
- その中での疑問を今回、スクラムガイドのもブリーディング、ディスカッションで理解を深める！

モブリーディングは2回目でしたが、初めてのこともありました😍

イベントを中継（Zoom）
自己紹介のやり方がかわった
公開イベントにしてから初の一桁の参加者
〇〇さんがビール飲んでいなかったｗ

中継については、Keepしていきたい❗

音質は問題なかった🙌
上田からの参加者の方も多くいるので有効に使っていきたい
中継元の議論を聞いて、中継先でも議論がおきていた👍
今後は双方向（ちょっと競争的なこととか）でやるのもよいかも

それでは内容ですー

アイスブレイク
ラガーTシャツのスクラムマスター再びｗ🏈
スクラムガイドのモブリーティング
- スクラムガイドで読んだところ📖
ディスカッション💬
- ホワイトボード
Fun-Done-Learn

今回のスライドはこちら（作： @shigeshibu44 ）

docs.google.com

アイスブレイク

Moving Motivators（3.0）で自己紹介

nuworks.jp

結構、参加者も同じになってきて、自分のことというよりは、今回は、相手のことを知ろうを主目的に行いました！自分も相手のことを知るということは普段から、大事にしています。

そのひとが何に詳しいかを知っていれば、不明点が発生したときに聞けるｗ
相手の知識、技術レベルがわかれば、それにあった説明ができる
相手が興味をもっていることを知れば、そのひとがどんな考え方をするかなどわかりそう

などなど。

Moving motivatorsの10個のなかから、個人ごと、大事にしていること3つを選んで理由とともに自己紹介

ちなみに私は「受容」「ゴール」「関係性」

これ、逆の大事にしていないこと、などにするとか、選択する意味合いをかえると違った面もみえてきて、いろいろ発見がありそうですね！またやりたい📝

ラガーTシャツのスクラムマスター再びｗ🏈

これをみて、スクラムマスターを復習ｗ

youtu.be

スクラムガイドのモブリーティング

今回は順番に読んでいきながら、

知ったこと（黄色い付箋）
疑問・質問したいこと（緑の付箋）

を付箋に書いて、ホワイトボードに貼りました

スクラムガイドで読んだところ📖

スクラムイベント
- スプリント
- スプリントの中止
スプリントプランニング
- トピック１：スプリントで何ができるのか？
- トピック 2：選択した作業をどのように成し遂げるか？
- スプリントゴール
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ

ディスカッション💬

ホワイトボード

f:id:chinoppy:20190724211919j:plain:w600

このホワイトボードをみながらディスカッション。印象に残ったことはこちら

スプリント
- 語源は自転車レースにおいて、長い距離を走ってきてのラストスパート部分
- なので、開発チームはスプリント期間中は全力疾走している
- だから開発チームへの障害は取り除かないといけない
- 余計なことを考えさせてはいけない
- だからラガーTシャツのスクラムマスターは開発チームを守っていたのか！
- これを聞いて、気軽にスクラムやろうぜ！なんて言えないと思った・・・
デイリースクラム
- 開発チームがおこなうもの
- 毎日、同じ時間・場所で開催し、複雑にならないようにする
- （全力疾走中なので今日は何時からなのかなとか、余計なことを考えさせない）
- 15分間で終わらせる
  - 全員が15分で終わらせることを意識しないと終わらなそう
  - 長くなりそうなものは、後で行うよう了解をとる程度がよさそう
- 障害物など懸念点等はすぐみつからなければいけない
  - デイリースクラムでみつかるのは遅い！
- 開発チームは自己組織化しなければいけない
  - なので、スクラムマスターは出席必須ではない
  - なにか調整、懸念点等あれば、開発チーム⇒スクラムマスターへ提言
PO大変
- お客とあったり、内部の調整をしたり、成果物を確認したり、プロダクトバックログをつくったり
- 開発チームは全力疾走してきているので、追いつかれないようにしないといけないｗ
- ステークホルダーを連れてこないといけない
- 価値、フィードバックをもらえるように計画していかないといけない
- 曖昧なプロダクトバックログだと、開発チームから突き返されてしまう・・・
不確実性を小さくしていく
- 新規案件はどの程度、売れるか、登録者数が増えるかなど不確実性が満載
- 価値を細かくリリースしていき、市場、ユーザからフィードバックをもらう
- リリースしないと自己満で終わってしまいそうだし・・・
- ここはアジャイルに興味をもった「エンジニアリング組織論への招待」の振り返りになった
- いろいろとやることがあるので、担当はあまり割り振られていない
  - 基本的にはプラインイング、スプリントレビュー
  - ちなみにそのせいか、ホワイトボードをみると、POの列はあまり付箋がなかった😳
兼任
- スクラムチーム内でPOは1人、スクラムマスターも基本1人などスクラムガイドでは記載があるが現実としては・・・
- PO + スクラムマスター
  - 相反する立場なところもあり、あまりよろしくなさそう・・・
- スクラムマスター + 開発チームメンバ
  - 成功している事例もあるが・・・
  - 開発チームメンバとしては全力疾走しないといけないけど・・・
  - チームのフォローもしないといけない・・・😫
- PO + 開発チームメンバ
  - これも事例がある
  - 開発チームメンバとしての役割が、技術支援、テクニカルアドバイザー的な立ち位置ならよさそう（なんとなく私もそう思いました）
- 正解はないので、試しながら改善がよさそう