見出し画像

CSP-SM受けてみることにした その3

これまでの話はここから

始まるまでのアイスブレイク

さぁ今日もいよいよ時間だと思い準備をする。
念の為 Linkedinを確認する(MarcとのやりとりはLinkedinでしてます)
ほらきたよ
「30分ずらしてくれない?」
とりあえずサムズアップを送り返した私です。

と、30分遅く始まったこの会ですが
冒頭いきなりMarcが言い放つ・・・

ま:この朝早い時間無理なんだよねー

な:・・・

それはさ!それなら予約ツールにその時間を設定するのやめようよ!!
そしてさらに予定調整は続く・・・。
前回、複数アポを入れていいことになり、このシーズンは年始まで空いてるらしいからポコポコ入れた私でしたが・・。

ま:クリスマスイブはさ・・・キャンセルしていい?
な:・・・いいよ

いや、そこもさ!ツールで設定してよ!!!

なんだかんだ入れた予定が2〜3個キャンセルになったような気がするものの。
なんかぬるっとぬるっと年末年始のメンタリング日程が決まりました・・。

セッション3回目本編開始!

今回も、結局はTrelloのToDoリストからReady for Reviewなものの対応をしていくイメージで進めます。
特に何から先にやりたいとかはないので、前回のやり直しになったものとその続きを順番通りに進めます。

Section 2のレビュー:スクラムマスターのコアとなる競争力について

2.1 オープンディスカッション のやり直し

構造化されたオープンディスカションの方法を考えてみようということで

  • 事前の意見収集からディスカッションをすること

  • 合意形成のためにfist-fiveのようなできる限り意見を拾いやすい方法を用いること

  • ファシリテーターが場を強くコントロールし、話す人・答える人を指名していく方法

を提示。無事に採用。
そのほかのものとして

  • 1人ずつ順番に意見を言う方法

  • 個別で書き起こす方法

  • アイディアをリストアップする方法

  • ペアもしくはグループでする方法

についてのアイディアをMarcから共有される。

2.3 ビジュアルファシリテーションをしたエピソードと、どのようなインパクトがあったか のやり直し

これが・・・難敵だった。
さらに粒度を細かくしたエピソードを書きMarcと会話をする。

何かが違う・・・

ま:あなたの書いていることは間違っていない。セオリーがわかる。ただ、セオリーでしかない。自分が体験したことを伝えてほしい。そこからどんなインパクトが生まれたのかを振り返ってほしい。「REFLECT」してほしい。
だからこそ、このコースは簡単ではないんだよ。

結論、再度ここの項目はやり直しになりました。

ただ、ここでの収穫はかなりある気がします。
スクラムマスターとしての新しい振る舞いの一歩の扉が開いた感覚がしました。
2回目NGは正直辛かったけど。

2.8 スクラムやアジャイルを適用したインパクト のやり直し

こちらも特にやり直しはなし

Section3のレビュー:開発チームへのサービス

3.1 二つのモデルを考察せよ。それぞれ、どのような時に使うことを推奨するのか

タックマンモデルによるチームの5段階でを引用
もう一つは
ハックマン:ハーバードで学ぶ「デキるチーム」5つの条件―チームリーダーの「常識」を引用
しかし、こちらもまた、フィードバックがありやり直し。

ま:このモデルを、どのように使い、実際にコーチとしてチームに接したのかが知りたいんだ

まさに、section2とほぼ同じ指摘です。

3.2 チームの効果を上げる、少なくとも3つのテクニックをあげよ。そしてそのメリット/デメリットをあげよ

回答には
Scrum.bookと組織パターンを引用

3つについてはそれぞれ

  • おやつ神社

  • 賢い愚者

  • 1人を犠牲にする(名前はあっていたか?)

で回答。
こちらは問題なく通過。

3.3 なぜ新しいスクラムチームを立ち上げる時には、従来型のプロジェクトのキックオフとは違うアプローチを用いる必要があるのか、少なくとも3つの理由を挙げよ

な:そもそも「従来型のプロジェクトのキックオフ」がわからないよー。従来型って何を指してるの?ウォーターフォールのこと?

ま:あー知らない!?従来型っていうのは所謂、プロジェクト型開発のこと。さらに説明をするとすれば、納期・スコープ・予算を中心に進められる開発スタイルのこと。ウォーターフォールというのは遠くはないよ。

とのこと。
とはいえ、想像は外れていなかったみたいで、ある程度のかいたセオリーは間違ってはいませんでした。

ただ、うっかり「プロジェクト」と書いてしまった箇所に関してはしっかり指摘され

ま:「プロジェクト」ではなくて「プロダクト」ね。スクラムやアジャイルは「プロダクト開発型」の開発スタイルだから。

この回答中に「従来型とスクラムではマインドセットが違うから」みたいな説明をしたところがあって、

ま:そうはいっても変わってくれない時はどうする?3ケースくらい答えられる?

なんて質問もありました。
ここは無事に回答完了。
ちょっとしたことなのですが、ここら辺からもうMarcの英語添削も割とはいってきており

Make them fail(失敗を経験してもらう)
って記載したんですけど

ま:Let them failにしよう。流石にmakeは強すぎる。

みたいなやりとりも。

3.5 新しいスクラムチームを立てるときのプランを立てよ。達成のためのキーとなるステップは何か

ここも無事に完了

3.6 スキルやケーパビリティが不足しているチームがインクリメンタルなやり方で成功するプロダクトを作り上げるにはどのような方法があるか提案せよ

ここは、子供を迎えにいくため終了。
ただ、「実際にどうしたのかを教えてね」というフィードバックがあった

今回のメンタリングセッションを受けて

前回までは「英語がーイマイチかー」ってところで進みが悪そうな印象があった。
ただ今回のを経て

「CSP-SM、しっかり噛みごたえあるな・・・むしろキツいぞ・・・」

に変化が・・・。

というのも、今までの自分の中に

自分の経験を基に論理と合わせて説明する

という観点がなかった。
これはスクラムマスターとして全く新しいアプローチだなと正直思った。

スクラムマスターを開始してから約3年、少しづつマインドは変化し、
より良いスクラムマスターの状態に変化しているとは思っていたけれど・・・。

さらに新たなステージへの扉を見つけた気がした。

確かに、CSMのトレーナーも「自分が経験した話なんだけど・・・」から多く切り出していたのを覚えている(もう2年前だけど)

今までは割とセオリーだったりロジックの部分を説明するのか、もしくは背景に合わせてどうしたいのかを問うやり方だった自分がいた気がする。

それからこの次の段階は
「相手の背景に合わせて、セオリーやロジックを自分の経験に乗せて話せるようになる」
そんなスクラムマスターになる必要があるんだなと。
さらにこれが、もしかしたら日本人あるあるなのか、教育の結果あるあるなのかと繋がったところなのだけど

ロジックを覚えてそれを模範回答として提示する

ことは例に漏れず自分も得意分野だったんだなと。
所謂、学校教育の上で、回答を溜め込んでそこを出していく状態。
そんな設問に関しては完璧な回答だというリアクションをもらえる。

しかし、
経験の上で語る部分に関しては、
セオリーやロジックの話はいくらでも出るのに
経験と結びつける話がなかなか出てこない・・・。

ここは一つ、自分の中の可能性として
すごく面白い体験になった回だった。

まさに私たちが
スクラム/アジャイルの実践者
であれと言われるそのもう一つ深いところに
今回のCSP-SMの研修があるんだと実感

Marcありがとう。