スクラムとアジャイルを学び直したいんですよねという話を@yunon_physさんにしていたところおすすめいただいた本。最近なにかと忙しいことに託けて本が50%付近までしか読めないという病にかかってたんですが、なんとかTwitterの名前を書き換えて読み切ることができました（たぶん関係ない）。
読んでみて
本自体はめちゃくちゃ面白かったんですよ。著者がスクラムを作りあげたきっかけや体験、ヒントにしたものなどがストーリーで語られるため読み物として面白かった。
じゃあスクラムを学ぶという文脈でいうとどうだったかというと、私はスクラムの基本を知った後に読む本として最適なのではと思った。
スクラムを知らない人向けにも問題がないように書かれてるかもしれないけど、スクラムのことを知ってるとだいぶ話が入ってきやすい。スクラムのことを知っている人からするとスクラムの仕組みが作られたきっかけになった体験が描かれているため、スクラムを実行する上でやる目的像が明確になるという利点があるように感じた。この辺りは@yunon_physさんに薦められた時も同じことをおっしゃってて、もうまさにその通りだったなという感じでした。
本当は引用を出してそれについてあーだこーだやりたかったんだけど63箇所マークしてて分量的になかなか厳しそうなのでスキップ。
タイトルは実際に著者がスクラムを導入した際に生産性を4倍にした体験談から付けられていると思うが、実際にじゃあスクラムを取り入れ始めた時にそうなるかっていうと怪しいと思ってる。それは、一見すると今までのチームワークの形を否定する場合もあるかも知れないからだ。スクラムの型を綺麗に実行できない事情とかもチームによっては全然あると思ってる。
チームに何かを浸透させる時に原則やなぜそれをやることが求められるのかを説明できることはとても大事な要素だ。人は納得感がないことや理解ができてないことは中途半端になったり、実行できなかったりする。そこを根強く実行していくための論拠や表現がこの本にはたくさん詰まっている。
引用をtweetしたやつ
お馴染みのアジャイルな宣言なやつ。それに対応したフレームワーク。
振り返りに関する考え方。障害になったものは何かはすごい大事ですよね。
最近すごくスプリントレビューをやることでプロダクトへの良い影響を感じることが多くなった。これ単純に楽しいし、チームのプロダクトへの解像度がとても上がったりするんですよね。
これは本を読む前からよく思ってたこと。一歩でも前に進めてくれた人を称賛したい
職能横断チームに関してはInspiredでも読んでいて４月からのテーマでした。その考え方が補強されたような気持ちがあります。チームの中に試作実行のための機能を集中させるというのはできる範囲で継続的に今頑張ってる。
ユーザーストーリーの扱いがまだ自分は全然解像感が高くないなと思っていて、プロジェクトに関わることでここはもっと磨いていきたいなと思ってる。
最後に
そんな感じで自分のスクラムの理解が補強されたり、間違ってたら理解を正してもらえたりした一冊でした。