まとまりがなくなったのでメモとして以下
スクラムを導入しようとする動き、「まず形から入ろう」「教科書的にやろう」とするなら最重要はタイムボックス切ってそこで達成された価値にフォーカスする（全体に対する進捗率ではなく）だと思ってる。そこが一番大事なわりに、変えるのが難しいポイントだから。
ツール導入や振り返りやPOとのすり合わせみたいなところを先にやるのは、変えやすい場所だからだと思う。でも生活リズムをスクラム的なものに変えたからといって、良いものが自動的に生み出されていくわけではない。戦術的にはタイムボックス切るようにする、スプリントゴールを設定するようにする、スプリントゴールは「達成」を検査するものとしていく、という段取りを描いたりするけど、日々の生活リズムを変えるところまではやればできるけど、マインドの変更は難しい。
タイムボックスに収まらない粒度の仕事ばかりなのでやりづらいという話を聞くことはある。でも、別に大きなタスクを持っていて完了状態にならないとしても、「ここまで進んだよ。この位置はこう解釈できるものだ」と達成は説明されうる。終わってるかどうかではなく、達成は何か、どういう価値があるものかって話で、仕掛かり中であってもゴールにどれだけ近づいたか、先の不確実をどれだけ減らせたか、全体のスケジュール感をどう進めたのか、そういうのが達成の価値であるから。しかしまあ、やりづらいから形だけ従おう、という考え方は手強い。なぜなら、そこを説明せずに進めたほうが楽だから。
打算に勝つためには別の打算か意思が必要である。
スプリントごとに生み出された価値の大きさとか、活動の正しさに対してフォーカスして改善を続けていって初めて適応プロセスが機能する。そのためには、チームは自分たちの出した価値に常に目を向けなければならない。漠然とやることやってるから役割を果たしているのだと言える、みたいな立ち位置から、このスプリントはこれだけのことをしたので我々はなかなかのもんだ、という見方に変える必要がある。
そこのマインドセットが変わらないうちは「スクラムのプラクティスを我々は利用しています」以上にはならない。プロセスは結果によって評価される。「うまく回っている感覚」に惑わされすぎないようにしたい。確実に日々前進する、チームの状態を自分たちで検査し、改善していく、どんな価値を出すかに自覚的である、やってることが正しいのか自分たちで考える、そういうチームであろうとする時「スクラム」は有効なプロセスだと思う。
ただそもそも「そういうチームであろう」とすることが難しいことじゃないかな、という感覚もある。サービス開発チームなどは自然とそうなっていくモチベーションがあるとして、保守運用や管理が中心のチームにおいて、これを内面化するのはこれまでの慣性に逆らうストーリーが必要そうである。
