Scrum」タグアーカイブ

スクラムマスター自身で自分自身を検査する1つのアプローチ

これはなに?

こちらはレッドジャーニーアドベントカレンダー11日目の記事です。
前日は市谷さん(@papanda)の組織の「左手」は、自分たちの「右手」のことを知らないでした。

このエントリでは「スクラムマスター自身で自分自身を検査する1つのアプローチ」について書いてみます。
合わせて同僚の森實さん(@samuraiRed)が書いている100日後に死ぬスクラムマスターを読んでみると理解が広がるかもしれません。

「自分自身がスクラムマスターとしてうまくやれているかわからない」という声

スクラムマスターとして活動してしばらくした後のスクラムマスターがこのような悩みを持ったりすることは割とあるようです。
支援先のスクラムマスターたちとの会話でもよく耳にしますし、(もうずいぶん前ですが)自分自身がスクラムマスターとして活動し始めた頃にも持った悩みだったようにも思います。

この状況に対する1つのアプローチとして「スクラムマスター自身で自分自身を検査する」というのがあると考えています。
その検査するための物さし、基準にはどのようなものがあるでしょうか?
多くの先達が書き記した書籍やインターネット上にあるスライド、ブログなども参考の1つにできると思います(もちろんコンテキスト依存だったりするのでそのままの適応はできないかもしれませんが)。
こういう、困った時に”原点に戻る”ことは比較的、筋の良いアプローチです。というわけで、ScrumGuideにはどのように書いているか見てみましょう。

スクラムマスターは、さまざまな形でスクラムチームを支援する。

  • 自己管理型で機能横断型のチームメンバーをコーチする。
  • スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
  • スクラムチームの進捗を妨げる障害物を排除するように働きかける。
  • すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

  • 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
  • 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
  • 複雑な環境での経験的なプロダクト計画の策定を支援する。
  • 必要に応じてステークホルダーとのコラボレーションを促進する。

スクラムマスターは、さまざまな形で組織を支援する。

  • 組織へのスクラムの導入を指導・トレーニング・コーチする。
  • 組織においてスクラムの実施方法を計画・助言する。
  • 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
  • ステークホルダーとスクラムチームの間の障壁を取り除く。

このように、支援の対象はスクラムチーム、プロダクトオーナー、組織の3つあり、それそれ4つの活動・行動があげられています。
この活動1つ1つを物さしとして、スクラムマスターとしての自身の活動を照らし合わせてみることで、検査が進むのではないかと思います。

もちろん、活動だけが大事ではなく、その活動の先にある周囲にもたらすもの(価値)も大事です。
ですが、まずスクラムマスターに取り組み始めてしばらくの間は活動の検査にフォーカスしてみるのもいいかもしれません。

スクラムマスターたちと実際にやってみて得られた3つのきっかけ

以下は、支援先のスクラムマスター(1〜3人)とアジャイルコーチとで実際に何度かやってみて、主に得られた3つのきっかけです。

具体的な活動を整理するきっかけになった

自己管理型で機能横断型のチームメンバーをコーチする。

「この活動に対して自分はどのようなことをやっているか?」という問いかけが起きました。
あるスクラムマスターは、メンバーとの1on1の中で、自己管理型が進んでいる状態を話し合ったり、その状態において自分たちは今、どこにいそうかといったことを話していました。
また別のスクラムマスターは、スキルマップを作り、その変化を検査することで、機能横断型のチームに近づいているかを意識していると話していました。

このように自分たちの具体的な活動がどんなものかを整理するきっかけになりました。

活動がもたらした変化や価値を考えるきっかけになった

必要に応じてステークホルダーとのコラボレーションを促進する。

「これに関する活動をやってみたことで、どんな変化が起きたんやろうね?」と話し合いました。
社内のステークホルダーと期待のすり合わせができて、協力を得やすくなったり、「あいつら大丈夫かな」となんとなく懐疑的に思われていた様子が変わっていったという話もありました。
社外のステークホルダーの1つである実際の利用者への理解の度合いが変わり、「これって刺さらさそうだから下にしよう」「ムダなものを作らないようにしよう」といったようにプロダクトバックログが変わることもありました。

Scrumを深く理解するきっかけになった

すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。

「”開催し”ではなく、”開催され”になっている。この違いはなんだろうか?」という話題が出た場もありました。
ちなみに原文(英語)だと”Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.”とあります。

(1つの解釈ですが)スクラムイベントはスクラムマスターが開催するものでなく、スクラムチームが開催するものであり、スクラムマスターはその場がポジティブで生産的になるように関わることが期待されています。その点から「開催され」といいう表現になっているのではないかという解釈を自分たちで見つけたりしました。

この3つ目のきっかけは1人でなんとなくScrumGuideを読んでいるとなかなか行き着くことの難しいものだったようです。

補足1:チームでこのようなことを話してみる

今回は主にスクラムマスターとアジャイルコーチでこのような場を作り、会話をした話を書きました。ですが、このような会話をスクラムチームの中でやっている現場もあります。

例えば、スクラムチームへの4つの支援を、チームはどのように見えているのか?どれくらい気づいているのか?どんな風に感じているのか?などを話し合ってみることで、スクラムマスターが自分自身のふるまいを変える参考になります。また、チームも今はスクラムマスターがやっているこれらの活動をどのようにチームに取り込んでいくのか?というきっかけにもなります。

補足2:人事評価のためのチェックリストに使わない

注意点として、これらの物さしを人事評価のためのチェックリストに使わない方が良いです。冒頭に書きましたが、これはあくまでスクラムマスターが自分自身で、よりチームにとって効果的な活動をし、価値をもたらすことを検査することを目的としたものです。

おわりに

Scrumに取り組む現場が増えてきていますが、まだまだスクラムマスターの活動やその価値といったものを(スクラムマスター自身も含めて)理解し、効果的な活用ができている組織、現場はそこまで多くないと私の観測範囲では感じています。
そのような状況が少しでも前進する1つの参考になれば幸いです。

Photo by Hudson Hintze on Unsplash