認定スクラムマスター研修って、おいしいの?
はじめに
2013年10月28・29日に、JimCoplienさんの認定スクラムマスター研修を受講しました。永瀬美穂さん(@miholovesqさん。SCRUM BOOT CAMP THE BOOKの著者です。)も講師として参加されました。永瀬さんとは、2012年のSCRUM BOOT CAMP関西以来の対面となります。永瀬さんは、「(教えるためではなく)自分も学ぶためにやって来た」とのこと。このような姿勢が自己成長に繋がるんでしょうね。
さて、本研修は簡単にいえばスクラムガイドに沿った講義となります。ただ、本研修でしか得られなかった気付きや刺激もたくさんありました。自分の中で咀嚼しきれていないことも多々ありますが、備忘録の意味も兼ねて掲載しておきます。
認定スクラムマスター研修まとめ
・講義中に質問や意見をすると、内容に関わらずキャンディー等のお菓子を(投げて)もらえる。それを、うまくキャッチしないといけないw #積極的な発言を評価するということでしょう。
・ソフトウェア開発は、製造ではない。
・開発方法論を確立していくことで、どんどん開発スピードが落ちてきた。
・やることが明確であれば、個人が主体的に行動することで早く実現できる。
・小さいチームは、コミュニケーションパスが小さくなる。
・大きな組織は効率が悪い。大幅に変える必要がある。
・レシピは組織毎に異なる。
・小さくやって成功できなかったら、大きくやっても失敗する。
・守破離。まず型を学ぶことから。
・Skypeの開発は、初期は4人チームだったが、現在は1000人。果たして、250倍パワフルなチームになっているだろうか。
・バグの80%は、要件の悪さから。プロトタイプをつくりましょう。コミュニケーションをとりましょう。プロダクトオーナーが熱意を伝えましょう。
・開発チームは、スクラムにおける豚である。
・開発者とスクラムマスターは兼任しないことが多い。
・開発方法論を確立していくことで、どんどん開発スピードが落ちてきた。
・やることが明確であれば、個人が主体的に行動することで早く実現できる。
・小さいチームは、コミュニケーションパスが小さくなる。
・大きな組織は効率が悪い。大幅に変える必要がある。
・レシピは組織毎に異なる。
・小さくやって成功できなかったら、大きくやっても失敗する。
・守破離。まず型を学ぶことから。
・Skypeの開発は、初期は4人チームだったが、現在は1000人。果たして、250倍パワフルなチームになっているだろうか。
・バグの80%は、要件の悪さから。プロトタイプをつくりましょう。コミュニケーションをとりましょう。プロダクトオーナーが熱意を伝えましょう。
・開発チームは、スクラムにおける豚である。
・開発者とスクラムマスターは兼任しないことが多い。
・スクラムでは、バグを見つけたら今実施しているタスクをやめ、すぐに直す。4時間かけても直らなければ、プロダクトオーナーに伝え、プロダクトオーナーが対応方針を決める。 #4時間というのは厳密に決っているわけではなく、チームで決めることなんだろうなと思います。
・いまどれくらいバグがあるか?という話題は、スクラムではあり得ない。
・チームに主体性を与えることで、成長を促す。
・カンバンは、チームワークを壊す。
・日本語と英語での、"かんばん"の意味の違い。かんばん=ScrumBoad、カンバン=Kanban #あくまでも、一般的にはということで。
・2weekという期間は、予測するのに長けている。
・プロダクトバックログはWHAT、スプリントバックログはHOW。
・スクラムマスターは、スプリント中のタスクを全てDoneに持っていくのが仕事ではない。品質を保つこと、人に命令せず促そうとすること。但し、何を言っても命令に聞こえてしまう(かもしれない)。態度で示すこと。
・良いスクラムマスターは、複数のチームをみることができる。素晴らしいスクラムマスターは、一つのチームしかみれない。
・スクラムマスターは暇じゃない!改善すべき種は沢山ある!
・スクラムマスターが暇ならば、確認してみよう。ベロシティは上がっていっていたか?品質は完璧だったか?改善マインドがなかっただけではないか?
・複雑さのレベル。Simple、Complicated、Complex、Chaotic。
・Scrum of scrumについて。チーム人数が増えていくと、最初にあったチームを分割。服っすうチームでひとつのプロダクトバックログを共有。
・複雑さのレベル。Simple、Complicated、Complex、Chaotic。
・チームに女性が入ることで、チームの考え方に多様性が出やすくなる(ことが多い)。
・オブジェクト指向のゴール:(クラス構造や継承関係がどうこうではなく、)頭にあるイメージを、コンピュータ上にそのまま再現すること。
・事前のQCD計画の正しさは、誰も判断できない。
・計画通り≒良いプロダクト。
・スクラムでは、計画を微調整していく。
・見積もりは、各自考えていることが異なるのが健全な状態。
・見積もりは、10秒でも機能する。
・見積もりに時間を掛けると、開発の時間が圧縮されることになる。
・見積もりは、プロダクトオーナーとのコミュニケーション。
・緻密≒正確。
・PBIのテストシナリオは、プロダクトオーナーが作成する。
・PBIのテストシナリオ≒Done条件。
・ソフトウェア開発は、10代の子供と同じ。予測はできるが、コントロールはできない。状況に応じて、方向修正していくことが必要。
・スクラムマスターは、権限を持たない。見積もりにも参加しない。命令もしない。
・スクラムチームは、problem vs usの構図。問題は、誰かひとりのものではない。
・見積もりは天気予報と同じだ。コミットなんかできない。
・メンバーの休暇は、プロダクトバックログに入れておけばいい。
・スクラムマスターは、牧羊犬である。
・スクラムマスター同士の秘密の挨拶。 #これは、Coplienから直接聞いて下さいw
・スクラムマスターとはw #コプリエンが見せてくれた動画
・スクラムガイドは、今でも改訂され続けている。スクラムの生成物の定義に、"スプリントゴール"なるものが新たに追加されていた。
・懇親会に参加しないのは、勿体無い。これから認定スクラムマスター研修に参加される方、是非懇親会にも参加を。その場こそが本番かもしれない。
・二日目最終日のチーム対抗ベロシティゲームの結果。各チーム、同じプロダクトバックログを3スプリント実施。スプリント毎に改善することで、ベロシティが上がるという事象(ちんもチーム、KUSHIチーム)。また、スプリント毎にプロダクトバックログを見積もりし直すことで、結果としてベロシティが安定してくるという事象(Hossy4チーム、倍返しチームなど)を体験。
これから認定スクラムマスター研修を受講する方へ
認定スクラムマスター研修は、基本(型。守破離でいう守。)を学ぶ場であり、素振りがメインの場ではありません。素振りの場を提供してくれるScrumBootCampやDevLOVE(僕の場合は、DevLOVE関西)、京アジャ(京都アジャイル)などの各種勉強会は、とても貴重な存在であると今回再認識しました。私は、事前に各種勉強会に参加していたお陰で、本研修でゼロから学ぶのではなく今まで蓄積してきた知識の再確認をすることができました。濃密な研修にするために、少しでも多くの体験をしてから研修に臨むことをオススメします。
認定スクラムマスター研修は、おいしかったのか?
「研修に参加し終えると、今の組織の文化が嫌になって耐えられなくなる。改善意欲の高い、成熟した組織に移りたくなる。」
本研修に参加するまでは、このように想像していました。
しかし、研修を終えた今はこう思います。
改善する=組織の文化を変えることともいえます。
決して容易なことではないでしょう。
組織に新しい文化が定着するまで、3-5年の覚悟は必要かもしれません。
でも、今は選択の余地はないのです。
自分は赤いピルを飲んだのだから。
認定スクラムマスター研修がおいしいかどうか、それはきっとあなた次第です。