スクラムマスタという名前が表すのは、この役割はスクラムプロセスの守り神だということだ。彼は変革者としてチームを支援し、組織の中でスクラムを構築する。障害をなくし、外部の邪魔からチームを守ることでチームが滞りなく機能するようにするのが彼の仕事だ。しかし、ある状況では、スクラムマスタ自身が最大の障害になっているとチームが感じることがある。
Siddharta氏は、オフショアチームでよくみられる、文化的な階層や伝統的な意思疎通方法に起因するある状況を挙げている。この状況ではチームと顧客の間で結局、スクラムマスタがボトルネックになっている。
氏が言うには、
多くのチームは顧客やプロダクトオーナと直接やりとりすることに対して神経質になっています(とくに互いに離れている場合は)。なので情報の流れは下記のようになります。
あなた <-> スクラムマスタ <-> プロダクトオーナ <-> 顧客
Tobias Mayer氏はこの記事に反応して、スクラムマスタがチーム内の仲立ちを行っていると、上のような状況の原因は至る所に生まれることを指摘している。
[この情報の流れ]は単純な上意下達の指揮方法です。誰かをスクラムマスタと呼ぶこと自体はその人をスクラムマスタにしません。特にその人が“古い発想”に深く捕われていて、その発想から離れてコーチングができない場合がそうです。
Jaibeer Malik氏はアジャイルを実践する方法に問題の原因を求めているが、氏の考えはTobias氏とほぼ同じだ。氏はアジャイルの基礎となるコミュニケーションの重要さを強調し、すべてのメンバが、いちいちスクラムマスタを通さずに互いに意思疎通をはかるべきだと主張している。
Roberto Fasciolo氏はスクラムマスタが伝統的な作業方法の罠に陥ってしまう別の理由を指摘している。氏はこの件に関して次のような落とし穴を見つけている。
- スクラムマスタがスプリントバックログにコミットすること–特にスクラムマスタが同時にメンバであるときに問題が発生する。すなわち、チームが単純にスクラムマスタの言うことに賛成するだけになってしまう。
- スクラムマスタがコーチングをする代わりに具体的な作業をチームに指示すること - スクラムマスタが以前プロジェクトマネージャである場合に発生しやすい。この場合、チームが完全にスクラムマスタに依存するようになってしまう可能性がある。
- スクラムマスタがチームとプロダクトオーナーの間で代理人として働くこと – Siddharta氏が説明した状況と似ている。オフショアチームのような分散している開発体制でよく起こる。
Mike Cottmeyer氏が付け加えるのは、スクラムマスタが障害を追跡するだけでそのまま放置しておくのなら、そのこと自体が原因でそのスクラムマスタは障害そのものになるということだ。優れたスクラムマスタは障害を追跡し取り除くだけでなく、先回りする者として問題点を予想し、チームと共に危険を探しだすこともできなければならない。
Cesario Ramos氏は興味深い状況について説明している。すなわち、スクラムマスタが本来のスクラムマスタとしての作業から離れてチームの作業に巻き込まれたとき、スクラムマスタはクリティカルパス上の障害になりうる。
この場合の問題はスクラムマスタがプロジェクト上の“価値のある”タスクを行うことです。彼または彼女がしようとする作業はチームの他のメンバの作業に影響を与えかねません。さらに、自分がやらなければ、チームのメンバがスプリントを行えないのではないかと、スクラムマスタ自身が考えてしまい、重要な作業や難しい作業を自分で抱え込んでしまうこともあるでしょう。
Boris Gloger氏もスクラムマスタ(SM)は(S)uper (M)anではないと指摘することで、同じようなことを言っていた。自分の役割を適切に果たさなかったり、主要な役割以外の様々な役割をやろうとするスクラムマスタはチームにとって障害になるのだ。
このように、多くの状況でスクラムマスタが陰に陽にチームのパフォーマンスを低減させる要因になることがある。重要なのはそのような状況を早めに見つけ出し、回復可能なうちに適切な行動を起こすことだ。