「スクラムで開発をしているか？」
と聞かれると「うーん」ってなる。それは、あなたの中のスクラムの定義による。
そして、スクラムの定義に厳しい人だけでなく、多くの人にとって、僕のやっている開発はスクラムではないだろう。
Doneの定義が明確ではなくてもスプリントを始めるし、スプリントバックログアイテムは全部は完了しないのが普通だし、スプリント中の差し込みも当然あるものとして開発をしている。
プロダクトマネージャー（POに近い役割）は2人いるし、プロジェクトマネージャー（SMに近い役割）も2人いるし、エンジニアのリーダーとしての開発マネージャーもいる。
全然スクラムじゃないよね。
でも、僕の中では、もうこれでスクラムと呼んでいいことになっている。
僕の中のスクラムの定義
じゃあ、僕の中のスクラムの定義ってなんだろう？
それは、何をやっているかではなくて、どう反応していけるか。
Commitment, Courage, Focus, Openness, Respect、そこに謙虚と信頼。これを持ったチームで、透明性を持って検査と適応をしていれば良い。
そんなチームで、プロダクトだけじゃなくて、プロダクト化されていないところまで含めた「サービス」全体を見て。
自分たちの今持っているをスキルを、期待ではなく、過去の実績をもとに把握して、ベストな道を選ぶ。
そういうチーム。今何ができるか、じゃなくて、今できることを持って、どこに踏み出そうとしているか。
チームもプロダクト
現状維持をしたいとは思っていない。やりたいことはたくさんある。もっとチカラをつけて、もっと良いサービスづくりをしたい。
そう考えると、サービスに対するスクラムチームであると同時に、チームそれ自身も自分たちのプロダクトだなと思う。そちらも育てていく。
スクラムマスターはチームというプロダクトのプロダクトオーナーだなぁって感じがする。そして、自分が何もすることがなくなるようになんてならない。
フレームワークとしてのスクラム
とはいえ、フレームワークとしてのスクラムを否定しているわけではない。
分かりやすいガイド、入口、1つの形として存在してくれているおかげで踏み出すことができるし、自分が違うやり方をしているなぁって認識できる。
「アジャイルな開発をしているか？」
と聞かれたら「そうだね」とは言えそう。
ということで、僕の中のスクラムの定義は広い。
今日もぼーっと思うことをメモしておいた。
