この度、1年ぶりくらいに スクラムマスター として仕事をする機会ができたので 事前準備としてチームにヒアリングして気づいたことをまとめておく.
背景
今回は新しく スクラム開発を始めるチームではなく, 既にスクラム開発を行っているチームにジョインすることになった. 背景として, スクラムイベントが停滞していて建設的な議論ができないとのことだ.
なんだか…炎上はしていないけど, 煙がたちはじめた所に参加しているような気がする.
やったこと
チームのヒアリング
現状を把握したいので, プロダクトオーナー, デベロッパー, スクラムマスターにそれぞれ話を聞くことにした. 端的に表現すると, お互いへの期待値に大きなズレがあることが分かった.
チームの成熟度を可視化
「お互いへの期待値に大きなズレがある」ことは分かったが, 「なぜ, ズレがあるのか？」を考えたときに, いくつか仮説を立てた.
しかし, これら仮説が有意だと判断するには観察時間も少ないので, 現時点での判断は諦めることにした. そこで現時点で見える範囲を分析をすると, スクラムチームのスキルや体験について気になることがあった. 役割毎に, スクラム開発経験と成功体験の有無に差があったのだ.
| 役割 | スクラム開発経験 | 補足 |
|---|---|---|
| プロダクトオーナー | 有り | 経験が長い, 上手くいったパターンを体験している |
| デベロッパー | 無し | 初めてスクラム開発する. まずは型から入っている |
| スクラムマスター | 有り | 経験が短い, 上手くいったパターンを体験している |
それをもとに立てた仮説は「成功したときのチーム像を追いかけているのでは？」ということだ. ※実際に聞いたところ, 事実だった
そこで思い出したのが過去に@ryuzeeさんがtweetしたこちらの内容だ.
スクラムチームの成熟度モデルに関する基準の例がCCライセンスで公開されていたので、日本語化したものを共有します。元ネタは、https://t.co/lFsD9KDUf1 pic.twitter.com/v1HlDK3z1k
— Ryutaro YOSHIBA (@ryuzee) 2019年8月21日
もとの記事が2018年なので, 現在のスクラムと状況が異なる部分もあるかもしれないが, こちらを使って自分たちの考える役割毎の成熟度を可視化してもらった.
| 役割 | 成熟度 | 補足 |
|---|---|---|
| プロダクトオーナー | 4 | 4よりの3らしい |
| デベロッパー | 1 | |
| スクラムマスター | 3 | 最近,は3に近いらしい |
この結果から得た気づきは各役割が相手に対して同じ成熟度でのやりとりを求めていたのだ. そのことから, 理想と現実のギャップを埋めるアクションを考えるきっかけが出来たので, そのための場づくりを準備をしようと思う.
まとめ
観察し対話することで, 気づき を促し, アクションに繋げられることを考えると, 可視化しながらの対話の重要性を改めて感じる機会になった. 今回は 成熟度という共通の指標を用いたが, 他にも可視化の方法があるだろうし, 成熟度から起こしたアクションを経過観察して効果が無ければ「ふりかえり」で別の方法を考えればよいので, たくさん試していこうと思う.
ちなみに, 先日 「スクラムマスターのためのファシリテーションの学び方について集まってみる会」に参加させてい頂いた. そこで スクラムマスター のファシリテーションについて考える機会があったので, この行動が スクラムマスター としてコーチングかファシリテーションかと考えたときに 「コーチング: 3, ファシリテーション: 7」 くらいの割合だと思った. スクラムマスターがチームにファシリテーションを行う場合は, コーチングの要素が含まれているのが, 多いのかな？と感じた出来事だった. ※司会進行とかに徹しているファシリテーションも見たことがあったので...
