先日「アジャイルコーチとスクラムマスターの集い」に参加してきました。「とにかく刺激的だった！」という熱量だけ当日ブログにまとめていました。 blog.kiwatchi.com
あれから数日経ち、断片的に思い出した印象的な話を箇条書きでまとめました（実際にはこれの200倍くらいのボリュームの話をしました）
- スプリントゴールを無理やり価値提供ベースの言葉に置き換えていることに対して何か意味はあるのだろうか？というモヤモヤがあったが、チーム外に「今なにやっている」を説明しやすいから意味はある、という話をした
- EMと兼務の話
- 明確なリスクとしては、評価者（EM）がチーム内にいることで、"開発メンバーがSMの言うことを聞いてしまう"状態になること
- SMはあくまでサーバントリーダーなので、SMの意向がチームの意思決定に大きく影響を与えるのはよくない
- いいチームの条件の一つとして、スクラムマスターがいなくなっても今まで通りパフォーマンス出るというのがある
- 逆に、そうならない場合はスクラムマスターに依存していることになるので健全ではない
- ただ、現実問題EMとSM、EMとPOの兼務などは現場ではよくある
- 横文字に逃げるのをやめようの話
- 横文字は定義がふわっとしているので、共通認識とりづらい
- たとえば「オンボーディング」。何をもって「完了」とみなすのか、オンボーディングする側とされる側で認識一致できているか？
- そもそもスクラムマスターという言葉が持つ役割や責務についても曖昧だなーと思うなど
- 1つ1つの言葉がチームに与える影響は大きい。言葉選びは慎重にやろう
- スクラムコーチはティーチングもする
- 「コーチ」という名前がついているから誤解されがちだが、チームに知識がない場合は当然ティーチングもする。というか、最初は100％ティーチング。
- （学びというか感想）SMやアジャイルコーチを仕事としている人たち、話聞くのうまいし、言語化能力めちゃ高かった
- 人や組織と向き合うという点ではまさにマネジメントと領被域っている
- 逆にマネジメントと直接かぶっていなそうなのは、経営との結びつきを考えるところかな
- ただ、ScrumMasterWay というSMのレベル指標的なものがあり、レベル3になればもはや全社的に影響を与える存在になっているので必然的に経営とも密接に関わることになりそうな気はする
- 「優秀なエンジニアばかりのチーム」vs「エンジニアはダメダメでベロシティも全然安定しないチーム」
- 最終的にビジネス的に成功したのは後者だったというエピソード
- 後者だとPOが本気でバックログを精査し、優先度をつけた結果ビジネスインパクト出せたというオチ
- 前者はエンジニアが優秀で良くも悪くもたくさん作れてしまうが故に、いわゆるビルドトラップに陥ってしまった
- 頭の片隅に入れておきたい知識
- レトロのネタが減ってきた話
- レトロでスプリントごとに着実に改善を行ってきた結果、挙がってくるProblemが減ってきた。これ自体はチームが成長した証として良いこと。
- 自分は、「理想と現実のギャップが課題」という観点から、新たに高い目標を掲げることでギャップを生み出し改善のネタを生み出そうと考えていた
- これ自体も悪いことじゃない
- 他の考え方としては、「課題を見つける」ではなく、「次のスプリントではこんなチャレンジをしたい」もアリ
- 「現状をよりよくするために何か施策を考えて実行する」ことにおいてはProblem出すのも同じだが、気持ちがポジティブなのでチームのモメンタムにもつながる
- 「レトロが終わった時に、次のスプリントを迎えるのが楽しみ」という状態を作れたらその時点で勝ち
- 「現状をよりよくするために何か施策を考えて実行する」ことにおいてはProblem出すのも同じだが、気持ちがポジティブなのでチームのモメンタムにもつながる
- ソフトウェア工学の話
- 日本でソフトウェア工学を教えている人はアジャイルなどのモダンな開発現場の知識があまりない
- アメリカだとGoogleなどが最先端の研究をやっている
- 『Googleのソフトウェアエンジニアリング』など
- スクラムガイドは何度でも読もう
- スクラムガイドは抽象的なので、チームメンバーで読み合わせ、議論するというプロセスに意味がある
- 何度読んでも味わい深い
