読者です 読者をやめる 読者になる 読者になる

#devkan プロダクトオーナーとスクラムマスターはどこで成長するのか?

昨日行ってきた。

devlove-kansai.doorkeeper.jp

現場の実際のストーリーは成功・失敗に関わらず宝の山だ。どちらかと言うと失敗談からの方が学ぶことが多いかもしれない。だからたくさんの人と様々な成功・失敗のストーリーを共有して、その体験談から学んでいきたい。

だけど、自分の体験した仕事の話を共有するというのは中々にハードルが高い。失敗談ともなればなおさらだ。でも、安心してほしい。僕らにはスクラム現場ガイドがある。この本には、そんなストーリーがたくさん書いてあるのだ。まさに、宝の山の山だ。

問題は、僕がまだこの本を読んでいないということかな(おい。読むよ!

という感じに、昨日のイベントで感じたことを雰囲気で書いてみた。良い本だと思いますよ!

books.rakuten.co.jp

悪役のストーリー

「ストーリーの中では悪役が大切。その悪役にもバックグラウンドがあって理由がある。」by キロー

そうね。そうね。もし開発チームを良くしたいと思うなら、その一つ外側の視点で開発チームをみなきゃいけない。なぁって。あぁ、最近こんなことばっかり考えてるすね。

あとは、ちょっと昨日隣の人とかとした話。

マネージャーをスッ飛ばす話

上の方とは合意ができているが、直接のマネージャーと反りが合わない。というときに「そのマネージャをスッ飛ばして話を進めようとしたがうまくいかなかった」というストーリーがあった。

僕だったらどうするだろう?スッ飛ばしでうまくいくイメージはない。僕だったら、そのマネージャと意見は合わなくても、その人のやり方が好きじゃなくても、利害関係を一致させる方向に動くかな。

マネージャとリーダーの意見が違うことほどメンバーを疲弊させることはない。それでもやっぱりそのマネージャが全然良くないときには、そいつを飛ばすか、僕が飛ぶかするのかな。

POが良いバックログを書くという話

POが良いバックログを書いたら、チームのベロシティがあがったという話。会場の雰囲気に多少違和感があった。

エンジニアはもちろん、プロダクトオーナーもスクラムマスターも、成長を考慮したいよね。エンジニアの場合はペアプロやコードレビューなどで成長していける。さて、POとSMの成長は?というのだけど、僕のチームではそれをチームに溶け込ませている。

エンジニアがスクラムマスターのヘルプも、プロダクトオーナーのヘルプもしている。スクラムマスターがあまりうまくない動きをしていたらチームのメンバーが「そこは、ほら、お菓子でも持ってウロウロしておいてよ」とか。

プロダクトオーナーは、書きかけのバックログを持ってきてチームに相談する。「こんな感じなんだけど他に書いておいて欲しいことある?」そして、チームの全員で「これがあるとテストがかけるよ」「これはなぜ必要なの?」「このストーリーは分割できるよ。そのほうが開発しやすそう。」などと話をしてバックログを作っていく。

なので、良いバックログを書くのは、僕のチームではPOだけではなくて、チームなのだ。ま、それをバックロググルーミング(リファインメント)っていうのかな。

会場の雰囲気的には「POが良いバックログを書くべき!」みたいになってて、ちょっと違和感あっただけです。

チームの中で全員が助けあって成長していけたら良いんじゃないかな。そういえば、全員プロダクトオーナーって話を以前にしたな。

www.slideshare.net

よく整理されていない

最近思うのが、僕のこういったやり方は、結構感覚で。全然よく整理されていないなー。整理するつもりもあんまりないんだけど。

今から東京。楽しんでくる。