見出し画像

やっぱりScrumMasterは常にチームを観察してなきゃダメだったよ

こんにちは!ShinoPです!
株式会社タイミーで専任のScrumMasterをやっています。

今日は自戒も込めて、自分の見ているチームで起こったことと学びを書いていきます。
現在2チームのScrumMaster/AgileCoachをやっているのですが、1つのチームはオフショア開発でやっています。
今回は、そのオフショアのチームで起こったことを書いていきます。
ちなみにオフショアはベトナムです。


コンテキストの共有

オフショアチームの構成と特徴
・ProductOwnerとScrumMasterはタイミー所属
・開発者3名とブリッジSE1名とコミュニケーター1名がオフショアメンバー
・チームの公用語は英語
・オフショア開始から約1年
・JPエンジニアがレビューしないとマージできない制約があり、チーム内にJPエンジニアはいない

最初は、チーム内のメンバー殆どがスクラム初心者でした。
私はScrumMasterとして、特に開始3ヶ月くらいはティーチングを強く意識しイベントの意味ややり方、守破離の守を教え込みました。
本来であれば、スクラムチーム全員で考え、育む事をしたかったのですが、オフショアの性質上、契約の関係上すぐに結果を出さないと継続などの判断も関わってくることもあり、ティーチングが強くなることは環境的にも仕方がない状況でした。
チームの様子的にも、疑問があればすぐ聞き返してくれるなど意欲的な場面が多かったです。
また、小さな実験を積み重ねる中で、最初は日本語とベトナム語でブリッジSEを通してコミュニケーションをとっていたのですが、公用語を英語にするなど大きなカイゼンもできるようになっていきました。

さらにオフショアを開始して半年後、より自分達ごとにしてもらうことを狙って、ブリッジSEの方にScrumMasterの一部の役割を委任し、私はAgileCoachとして、チームをより外から支援するようになりました。
そして、週1でブリッジSEと1on1を行い、チームの変化について話したり、悩みに対してのコーチングを行うようにしました。

また、私が担当するもう一つの日本のチームにパワーをかけるような動きをする形になっていきました。

違和感

オフショアを開始して9ヶ月後くらいにオフショアのチームのレトロスペクティブに参加している中で、"Effective"や"No ploblem"、"I have no question"などの言葉が多く使われていることが気になりました。
カイゼン圧が弱まっているというか、チーム自体がコンフォートゾーンにいるのでは?という感覚です。

また、ブリッジSEと1on1では特に大きな課題などもなく、ProductOwnerとも週1で1on1を行なっていましたが、課題感は特になさそうでした。

しかし、ステークホルダーと話をする中で、オフショアチームのパフォーマンスなどに懐疑的なステークホルダーも存在していました。

ここで、オフショアチームとステークホルダーの間にギャップがあると認識したので、日本のチームよりもオフショアのチームを観察する判断をしました。
幸い日本のチームも自己組織化が進み、ScrumMasterが張り付いてなくても自分たちで仮説を立てて、実験しカイゼンしていくサイクルが出来てきたので、オフショアのチームに注力する事ができました。

オフショアチームのスクラムイベントを3 Sprint(3week)ほど観察した結果、動くソフトウェアが出ていないことに気がつきました。
チームの雰囲気(コミュニケーションの量)や進め方も自分たちでカイゼンしているので、問題なさそうに見えたのですが、スプリントレビューで一向に動くソフトウェアが出てきていなかったのです。

課題

前提として、弊社のオフショアをやるにあたっての制約上、JPエンジニアがレビューしないとマージできないなどもあり、レビューしやすいようにドキュメントをしっかり書くなどはやっていました。
また、ステークホルダーとのコミュニケーションも言語が異なる為、ドキュメントを作成して認識を合わせやすくするなどのプロセスに関するカイゼンは進んでいました。
しかし、コミュニケーションミスが起きないようにという部分を重視しすぎることによって、あまりにもプロセスを重厚にやってしまうことにより、動くソフトウェアが出てきていなかったのです。
スプリントレビューでは、ダイアグラムやテキストのドキュメント、調査結果などをステークホルダーに伝えている状況です。

さらに、チームの中ではブリッジSEやProductOwner含め、"自分たちはプロセスをカイゼンできている"、"コミュニケーションも良くなっている"という状況でした

本来であればScrumMasterが観察を経て、チームを俯瞰してみることによって顧客に目を向けるように促すなどが必要でしたが、それができていなかったのです。
この部分は私もチームから目を離しすぎたと反省しています。

行動

よくScrumMasterは"庭師"などと言われますが、オフショアチームの状態を一言で表すと、荒れ果てた庭の状態でした。
さらに、いくつかのアプローチを経てわかったこととして、全員がプロセスを良くすることを目的になっており、顧客に目が向きにくい状態でした。
ここで、私がとった行動は組織パターンで紹介されている賢い愚者という振る舞いです。

賢い愚者 とは

問題が簡単に公言されないのであれば,賢い愚者というロールを作り,誰も言いたがらないことを言ってもらうようにする.また,それによって罰を受けずにいられるようにする.

組織パターン

チームが組成され、コミュニケーションミスが多発していた頃に比べ、コミュニケーションの部分ではカイゼンされているという事実を尊重しつつ、それでも動くソフトウェアが生まれていない、また生まれる頻度が少ないことについて、ブリッジSEとProductOwner中心に問いかけました。
最初は一定の反発(我々はできているなど)があったものの、事実を一緒に確認し、プロセスをカイゼンする理由は何か?プロセスが良ければ顧客は満足するのか?を問い続けました。

学び

ここまでの学びは以下です。
・ScrumMasterは俯瞰してチームを見る事が大切
・プロセスも大事だが、顧客を中心とした考えをするように働きかけること
・常に観察いていないと荒れ果てる

チームを俯瞰してみたり、顧客中心の考えなどは今までも大切だと思っていましたが、"常に観察していないと荒れ果てる"の部分においては学びになりました。
一見、うまくいっているように見えたり、カイゼンサイクルが回るようになったチームでも、健全性を保つ為には、やはり常にScrumMasterは必要だなぁと感じました。
そうでないと、荒れ果てた後のテコ入れが大変なのと、常に観察していれば荒れ始めた段階で手を打つことによって、チームからの反発なども少なく早めに軌道修正できるからです。
もちろん、実際に失敗させて学びを得るやり方も良いですが、自分たちが失敗していることに気がつかない場合もあるので、その時はScrumMasterが失敗している事を認識してもらうような振る舞いや、誰もが言いにくい事を言わなければならないという必要が出てくると思います。
(Elephant in the room)

今後の動き

現在は、賢い愚者という振る舞いを使って、オフショアチーム内で誰もが言いたがらない事を指摘し、その指摘に対してどうするのか?をチームで考えてもらっている段階です。
自分達の目指す姿とか、チームのミッションに関して理解を深めるとか、色々なアクションに繋がりそうなので楽しみです!
また、本質的にチーム内でレビューが収められないなどがネックになっていることは変わらないので、その重要性を訴え続けた結果、ベトナムと日本の混合チームになる予定もあります。
今後、動きがあり学びがありそうなら記事にしていきたいと思います。




この記事が気に入ったらサポートをしてみませんか?