スクラム道.06に参加してきました。 #scrumdo

スクラム道.06に参加してきました。
今回のテーマは「スクラムマスタ」で、講師*1の@kappa4さんの発表の題名は「スクラムマスター?」でこちらで公開予定だそうです。

発表内容は、スクラムマスタについて、知識ややったこと、どう考えるか、行動は？といった内容でした。
詳細はTogetterのスクラム道.06をご覧ください。
イベントの写真はこちらにアップされています。

以下は、プレゼンをふまえて、参加者同士のディスカッションの流れとか私の感想とか覚書です。

Q. SM*2は何をする人？
- チームの生産性を最大限向上させ、ユーザのビジネス価値の向上に最大限貢献する様にする人。not コード書かない人。
Q. SMとしてチームにやって欲しいことがある。その場合、どういう風に伝える？
- 指示する派：ティーチングでメンバにやって欲しいことを伝える。
- 指示しない派：課題をメンバに伝えて、コーチングで相手から問題への取り組みを促す
- ハイブリッド派：両方やるよ。
- 脅迫派：「この問題放置しててマジでいいの？」「ちゃんとここまでお前ら本当に考えてるの？」といってビビらせてやらせる。
Q. SMを専任？　それとも兼任してる？
- 兼任(8割?)、専任は少数
Q. PO*3とメンバは直接話せている？
- 話せているが大多数(9割?)、話せていないは少数
- 話せていないで手を上げた人も夫々のコンテキストを共有してみると、実は話せているってパターンでした。
- 私のところを除いて…*4
Q. スクラムをやり始めたけど、PBL*5の作成に時間がかかる。何か良い方法ないか？
- 最初に詳細化を全部やるのはアンチパターン。直近のスプリントのものだけ詳細化をする。
Q. 要望が前回の似たシステムと言われると、前回作っているだけにPBLが沢山出てきてしまう。その場合はどうすればよいか？
- “前回と似た”と言っているということは、前回と違っている部分はPBLに上げて、前回同じ部分に関しては、細分化せず、PBLの中の1つに落とし込めば良いのでは？
- PBLは製品に必要な要素を項目に起こした一覧なので、開発側視点のタスクに落とし込まれている様なものとして書いているなら、そこから異なるのではないか*6？
Q. 質問：スプリントの期間はどうPOに納得してもらう？
- スプリント期間はタイムボックス(チーム全員でコミットした期間)なので、スプリント期間に関しても、POに何故このスプリント期間なのか納得してもらう必要がある。そして、それはメンバやSMの役目でもある。
Q. 質問：もし、あるスプリントでそのスプリントでリリースするはずのモノが出来なくなった際に、POがそれに納得出来ない場合はどうする？
- “スプリント期間内にそのストーリーを完遂*7する”ことをコミットメントしているのではなく、“スプリント期間内にそのストーリーを完遂させる為にチームは全力を尽くす”ことをコミットメントしている。完遂出来なかった理由について、説明して納得してもらおうとするが、それでもPOが納得しないのならば、スクラムでやることは不可能なので、WF*8で開発してくれとなる。
- ちなみにWFでやったとしても、出来ないものは出来ないのでムリだと思う。
Q. 質問：アーキテクト依存の部分がビジネス価値が低い為に、優先度が低くなり、後回しになった。その時、後にやったことによって、開発工数が大きくなることが分かっている場合、どう判断する？
- “アーキテクトの問題で先にやっておいた方が開発する手間や難易度*9が低く、後でやると開発する手間や難易度上がる”ということがやる前から分かっている、判断出来るということは、それはその機能に関して、プロダクトバックログとして必要なレベル以上に見積もり過ぎている*10。
- もし、後でスプリントバックログとしての詳細化をした際にそれが分かった場合は、正直にストーリーポイントが高いことを伝えるしかない。
- それでもやるとPOが決めたのなら、やるしかないし、そこでやらないとPOが判断すればやらなくなるだけ。
- ただ、ROI*11によって、やる/やらないを判断することもあるので、そこらへんは伝えるべき。

質問への個人回答

以下の質問には私個人の意見を言いたいので、別枠にします*12。

Q. 質問：SMとして先程“指示にならない様にティーチングではなく、コーチングしている”と仰っていたが、“指示にならない様に”と思っている時点で、自分の中に答えがある様に思える。コーチングしている際にその答えになる様に誘導尋問しているのではないか？
- 自分の中にある答えと異なる答えをメンバが出したとしても、「それでやってみようか」と言ってメンバが出した答えをそのまま受け入れている。
- 何故なら、“自分の中にある答え”というのは自分一人で考えたものなので、必ずしもこれが正解とは限らないから。
- そして、メンバがコミットメントした答え*13を実施した結果、良いのか悪いのかを早期に知りたいので、小さく始めるのがベター。
- 個人的には1スプリント実施して、その手応えをふりかえりでメンバと確認するのが良いと思っている。
Q. 質問：指示した方が早い時に、指示しない(コーチングする)ことがビジネス価値を生み出さない時、どう判断をしている？
- “指示することにより、目先のスプリントのベロシティを上げるまたは落とさないというビジネス価値”と“指示しないことにより、目先のスプリントのベロシティは落ちるが、後のスプリントで落とした以上のベロシティを上げるというビジネス価値”から“指示しない”方が総計のビジネス価値が上がるという判断して行っている。
- これは自分が今まで携わってきたプロジェクトでは、プロジェクトの期間が長い(2ヶ月以上)為に、一時的にベロシティを落としたとしても、早期の自己組織化、自己解決力の向上によって、後のスプリントで最初に想定していた以上のベロシティとなって、落としたベロシティ分を十分回収出来るから。
- つまり、ROIを見て判断しているということ。
- その為、ソーシャルゲームやWebの様にプロジェクトの期間が極端に短い場合は、“指示する”方が総計のビジネス価値が上になるなら、“指示する”方が良いし、それを自分でも実行すると思う。
- ただ、人は人財なので、早期の人への投資*14は、すぐに回収出来るはずなので、人を使い捨てにしないなら、基本的に“指示しない”で人を育てる判断をした方が良いと思う。
- ちなみに自分が“指示しない”ことを選択して、プロジェクトを終える時点での総計のビジネス価値が“指示する”より低くなったことは一度もない。
- 但し、“指示する”より“指示しない”が生み出すビジネス価値が上回る時期*15を正確に当てたこともない(笑)。
- そこを正確に言い当てる能力も必要なのだろうけど、自分としては、“指示する”より“指示しない”が生み出すビジネス価値の方が上回るという読みをプロジェクトの出来るだけ前半で判断出来る様になる方が重要だと思っているので、今後もビジネス価値が上回る時期を正確に当てることに関して、磨くことはないと思っていたりする。