とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想

www.scrumguides.org

• Product Goal という新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。
  • Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。
  • けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。
  • 実際、いい感じに Scrum の Sprint がワークしてるな、と思うのは、チームが Sprint Goal と Definition of Done を意識して動いてるときなので、Product Backlog にもその仕組を作りたくなる気持ちはとてもわかるし、実際にそうやって仕事をしている側面は多分にあるよね、というのは再確認。
  • しかし、Definition of Done の "相方" である "Acceptance Criteria" については、2017年にあった「完成を確認するテスト記述」という言葉すらなくなったのか、というのは意外。
• 冒頭セクションの「スクラムの中核をなす設計や思想を曲げたり、要素の一部を抜かしたり、スクラムのルールを遵守しないことで、問題が起きたり、得られる効果が限定されたりする。それを通じてスクラムが無用の長物だと言われる」という記述。
  • いわゆる「AKB48 と前田敦子」問題。スクラムを曲解したチームが悪いのに、スクラム自体が悪者にされる現象は、何度か目撃したことがある。
  • なんでこの文言をここに書いたんだろう。スクラムが考案から30年経ち、メジャーになって、上述のような経緯でスクラム嫌いな人も一定存在することを念頭に、その人達をスクラムガイドに引き込むためのアプローチを考えたのかな？
  • 実際、自分もスクラムアレルギーのある人にはこういう話をするなぁ、と思う。
• Sprint Planning が明確に3ステップに記述されるようになり、従前のステップの前に「スプリントゴールを明確にする」が入った。
  • とても良い。
  • やはりスプリントゴールの有無でチームの生産性は圧倒的に変わる。個人的にも最近の仕事でとても実感している。
• Sprint Review の記述がとてもシンプルになった
  • これまで「単なるステータスミーティングではない」と書かれていたのが「これは単に新機能プレゼンをするだけじゃない」と書かれたのは印象的。 官僚的なソフトウェア開発からの脱却ではなく、"Broken Scrum" や "なんちゃってアジャイル" からの脱却がスクラムガイドの念頭に置かれるようになったのかな？とエスパー邪推。
• 「一般的には、チームは小さい方がコミュニケーションを上手にできて生産性も高い」「より短いスプリントは学習サイクルや、費用や労力に対するリスクの軽減に役立つ」という点は明確に書かれている点
  • 全体的に抽象的に書かれている中で、この記述は結構鮮明だな
  • 流石に1ヶ月のスプリントを回すチームってそんなに聞かないけど、「1週間か2週間か」に迷うチームはよくある。 (自分のチームも最初はそうだった)
  • 実際にリモートで仕事するときって10人のチームは結構しんどいよね、というのも実感ある。 (この話はまたどこかで)

お酒飲みながら読んだのでハチャメチャだったら許してください。

ちょうど、2週間前から同僚の数名を対象に「スクラムガイドを音読する会」を実施していたので、2017年版のスクラムガイドも比較的鮮明に記憶に残っていて、Diff が取りやすかったです。