昨日行ってきた。
現場の実際のストーリーは成功・失敗に関わらず宝の山だ。どちらかと言うと失敗談からの方が学ぶことが多いかもしれない。だからたくさんの人と様々な成功・失敗のストーリーを共有して、その体験談から学んでいきたい。
だけど、自分の体験した仕事の話を共有するというのは中々にハードルが高い。失敗談ともなればなおさらだ。でも、安心してほしい。僕らにはスクラム現場ガイドがある。この本には、そんなストーリーがたくさん書いてあるのだ。まさに、宝の山の山だ。
問題は、僕がまだこの本を読んでいないということかな（おい。読むよ！
という感じに、昨日のイベントで感じたことを雰囲気で書いてみた。良い本だと思いますよ！
悪役のストーリー
「ストーリーの中では悪役が大切。その悪役にもバックグラウンドがあって理由がある。」by キロー
そうね。そうね。もし開発チームを良くしたいと思うなら、その一つ外側の視点で開発チームをみなきゃいけない。なぁって。あぁ、最近こんなことばっかり考えてるすね。
あとは、ちょっと昨日隣の人とかとした話。
マネージャーをスッ飛ばす話
上の方とは合意ができているが、直接のマネージャーと反りが合わない。というときに「そのマネージャをスッ飛ばして話を進めようとしたがうまくいかなかった」というストーリーがあった。
僕だったらどうするだろう？スッ飛ばしでうまくいくイメージはない。僕だったら、そのマネージャと意見は合わなくても、その人のやり方が好きじゃなくても、利害関係を一致させる方向に動くかな。
マネージャとリーダーの意見が違うことほどメンバーを疲弊させることはない。それでもやっぱりそのマネージャが全然良くないときには、そいつを飛ばすか、僕が飛ぶかするのかな。
POが良いバックログを書くという話
POが良いバックログを書いたら、チームのベロシティがあがったという話。会場の雰囲気に多少違和感があった。
エンジニアはもちろん、プロダクトオーナーもスクラムマスターも、成長を考慮したいよね。エンジニアの場合はペアプロやコードレビューなどで成長していける。さて、POとSMの成長は？というのだけど、僕のチームではそれをチームに溶け込ませている。
エンジニアがスクラムマスターのヘルプも、プロダクトオーナーのヘルプもしている。スクラムマスターがあまりうまくない動きをしていたらチームのメンバーが「そこは、ほら、お菓子でも持ってウロウロしておいてよ」とか。
プロダクトオーナーは、書きかけのバックログを持ってきてチームに相談する。「こんな感じなんだけど他に書いておいて欲しいことある？」そして、チームの全員で「これがあるとテストがかけるよ」「これはなぜ必要なの？」「このストーリーは分割できるよ。そのほうが開発しやすそう。」などと話をしてバックログを作っていく。
なので、良いバックログを書くのは、僕のチームではPOだけではなくて、チームなのだ。ま、それをバックロググルーミング（リファインメント）っていうのかな。
会場の雰囲気的には「POが良いバックログを書くべき！」みたいになってて、ちょっと違和感あっただけです。
チームの中で全員が助けあって成長していけたら良いんじゃないかな。そういえば、全員プロダクトオーナーって話を以前にしたな。
www.slideshare.net
