Scrum教えながら若手メンバーに伝えたかったこと ～（続）限られた時間でScrumを効果的に教える
前回は、開発経験がほとんどない弊社の若手に、ScrumのことをScrumで教えてみたことについてお話しました。
今回はその続きです。
見積もり通りに終わるとは限らないこと
前回、見積もりまでは終わらせているので、優先度が高かったグループのカード4つをスプリントバックログに移動させるところからスタートです。
- スクラムとは何か知りたい → 5P
- スクラムマスターが具体的に何をする人なのか知りたい → 2P
- アジャイル開発のスタートってどんな感じか知りたい → 2P
- スクラムがうまくいってる or いってないサインを知りたい → 1P
すべて時間内に終わらせることができれば、ベロシティは10Pになりますね。
まずはこの中で一番優先度が高かった、「Scrumとは何かしりたい」からスタートです。頭から全部説明しだすと終わらないので、私が一番大事だと考えるポイントに絞って説明しました。
それは、Scrumは経験的プロセスに基づくこと。つまり、検査と適応、フィードバックループの重要性です。ウォーターフォールのように事前にギチギチに定義されたプロセスでは、計画通りにタスクが終わればうまくいくけど、それが実際には容易ではないことは、彼らなりの経験に基づくイメージを持ってもらえたようです。
今回の講習に例えれば、15分単位に何を話すか細かく決めてその通りに進めることもできるだろうけど、事前の計画通りに終わるかはやってみないとわからないし、そもそも、計画通りに説明を聞き終えても、みんなが満足できるかはわからないよね、という話です。
ちなみにこのスプリントでは、ポイントを絞ったとはいえ、Scrumの3つの役割や5つのイベント等について説明をしたりして、90分の時間すべてを費やしてしまいました。最後に「これらの説明で納得できたか？さらに質問はないか？」を確認し、カードをDoneレーンに移動させます。
このカードは5ポイントの見積もりだったので、これが現時点でのベロシティになります。始める前は10Pぐらいいけるかな、と思っていたのですが、実際にはできませんでした。これは実際のプロジェクトでもよくあることです。
ということをみんなにお話して、最初のスプリントは終了です。
ふりかえりと改善が大切なこと
この講義では教える側の私がScrumチームなので、私はひとりで（頭の中で高速に）ふりかえりを行い、時間がかかりすぎてしまってこのペースでは最後まで終わらない状況を、次の手段で改善してみることにしました。
- カードに書いてもらった内容について追加で質問し、本質に絞って話ができるよう記入意図を再度確認する
- 無駄口を減らす
まあ、要はペースアップしたいわけなのですが、「あとは本を読んでおいて」という時間短縮よりは効果的だと思います。
で、結果的に、次のスプリントではベロシティが8Pに伸び、時間内にすべて終えられる可能性が高まりました。
スプリント中には割り込ませないこと
もともと講義は座学だけでなく、実際の現場（アジャイルスタジオ福井で実施されている実プロジェクト）を見てもらいたいと思っていました。タイミングよくこの日はあるプロジェクトのプランニングの日なので、チームのスクラムマスターに相談し、見学にいっても良い時間帯あるなら教えて頂戴とお願いしておきました。
で、ちょうど午前のスプリントを実施している最中にメッセージが届き、13時30分から30分程度なら良いですよ、とのこと。
この段階で「今からASFに見学に行きましょう！」というのは簡単なのですが、そこはScrumなのでそれをせず、「1Fを見学する（ASFは一階にあるのです）」というカードを書いて、「学びたいことバックログ」に追加しつつ、プロダクトバックログには、いつでも誰でも追加できることを改めて説明しました。
見学は、次のスプリントの最初に行いました。狙ったわけではないのですが、スプリントには割り込みを許さないことを体験してもらうことができ結果オーライです。
習っただけではできない。後は自分たちで考えて行動すること
と、このような感じで徐々にベロシティを向上させ、最終的には、元々予定していた時間内に、学びたいことバックログをすべてDoneにすることができました。アジャイルやScurmのことだけでなく、翌週からの自由課題にそれをどうやって活かすと良いのか等、実践的で差し迫った課題にもある程度は応えられたのではないかな、と思います。
しかし、知っていることとできることは全然違います。無茶苦茶悩むんじゃないかな。アジャイルにならない可能性もあるんじゃないかな。チームとしてうまく機能しないことも多いんじゃないかな。ベロシティが上がらず課題が完成しないプレッシャーを感じるんじゃないかな。
苦労はすると思いますが、自分たちで考えていろいろ失敗し、Scrumの本質の一つである、検査と適応、そしてフィードバックの重要性を実感してもらえると良いなぁ。と、思います。
今回、ScurmをScrumで教えるということを、本格的に試してみました。自分としては、限られた時間の中で、私が伝えたかったポイントを、本人たちが期待する優先度で伝えることができ、良かったんじゃないかなと評価しています。
ただ、本当はどうだったのか、本当に役に立ったのか、彼らチームの活動成果とフィードバックを待ちたいと思います。
