初めてスクラムに取り組む方には特におすすめの良書でした！！
スクラムはスクラムガイドがあるもののより具体的な行動は自組織の状況に合わせて考えていく必要があります。本書はスクラムガイドの丁寧な説明と共にある架空のプロジェクトを題材により具体的な行動を示してくれます。
もちろん、組織の状況により変わるので正解があるものではありません。しかし、著者が長くスクラムに向き合う中でうまくいっている状況をまとめたものなので参考にはなるはずです。
一つのお手本として色々と学びや気づきがあります。自組織ならこうなるだろうな〜と考えながら読むことでよりスクラムに対する理解を深めれるでしょう。
プロダクトのSREチームにおけるスクラムについて（おまけ）
SREチームでスクラムを初めて4ヶ月ほど経ちました。メンバの中には開発チームでのスクラム経験者もいるので一定のプラクティスは実践でき始めています。
ただ、全てを忠実にやれているわけではないというのが現実です。なんちゃってスクラムと呼ばれる状況なのかもしれません。
結果としては導入して良かったと感じるところが多いです。特に透明性がもたらす属人化排除や、メンバを孤独にしない環境作りはこれまでのSREチームの課題を解決するものだったように思います。
また開発チームはスクラムを導入しているので会話の中で出てくる用語の解像度が上がったなど副次的な効果もあります。
一方で、SREチームのスクラムはかなり難しいなあと感じます。創意工夫の余地があるのは前提として難しさを言語化してみます。
やはり一番の歪みはプロダクトオーナーがいないことなのかもな〜と仮説を立てています。
そもそも当プロダクトにはプロダクトオーナーという立ち位置はありません。プロダクトマネージャと各開発チームにいるプロダクトリードが似た責務を持ちます。
当SREチームが実施するような「開発者チームが信頼性を向上するための仕組み作り」をプロダクトマネージャーが扱うのは現実的ではなさそうなので、プロダクトマネージャーは現状SREチームのバックログには関わっていません。
そうなると結局プロダクトオーナーの責務はメンバが共有して持つ形になります。スクラムチームから⽣み出されるプロダクトの価値を最⼤化する責任をメンバで共有している状況です。
ちなみに、チームのプロダクトリードがバックログアイテムの作成は実施しています。なのでスクラムのイベントは実施できています。
また、具体的な機能が必ずできるわけではないのでスプリントレビューも実施してなかったりします。
そうなると検査が機能しなくなっていきます。元々SREチームは差し込みタスクが多いというのもあり、各インクリメントもなあなあになってくるところもあります。
とはいえスクラムをやることが目的では無いですし、プロダクトに対して価値を生み出せている自信はあるのでヤバすぎる状況では無いのかな〜と思ったりはしています。
一方でもう少し価値を最大化する方法があったりしないかな〜とは思ったりするので、今後も少しづつ向き合えたらと思います。
上記のような課題感を持てるのも当書籍のおかげです。基礎的な考えを学ぶのは大切ですね。
