スプリントへの割り込みに悩まされた時に考えること

前回の続き

そもそもゴールに集中したら何を追加するかわかるじゃんっていう話をこの後に書いた

割り込む理由／どんな状況か／何を見て判断するか／対処方法

※ここに書いてあること以外にもいっぱいあるはず。

※割り込みが絶対にあってはいけないとは言わないですが、ヒステリックにゼロイチでないといけないということもないと思うので、割り込みが多いなって思ったら気にするくらいで。完璧なんてないので。 ※目安はスプリントゴールがもう無理ってなるかどうか

計画が立てられるほど見通しが良くない

こんな状況
- スプリント期間で何をやればいいのかを決め打ちできるほど、チームの置かれている状況の見通しが高くない。
- 必然的に、スプリントを進んできたところで新たな発見・ないしはやらなければいけない仕事に出会い、修正を余儀なくされる。
- 結果、割り込み誘発される。
- ウォーターフォールは変化に対応しにくいけど、同じ理由で変化に合わせたサイクルでないスプリントも変化に対応できない。
兆候
- 割り込みはスプリント後半に発生している
対処
- スプリント期間を短くする。
- またはタイムボックスで仕事をすることを諦める（フローで仕事をする。カンバンとか）

こんな状況
- PO が開発者（というか規律）に対する甘えを持っている。スプリントの途中で頼めばいいだろう、という発想でいる。
- 結果としてデリバリーが混乱し、チームの規律を乱すことを許し、プロダクトのアウトプットも低下する。結果として、ROI を最大化するという PO の責務を果たせていない、ということに気付いていない
- PO は常に一歩先、二歩先を見越して何を解決すべきかを考え続ける必要があるが、受託請負メンタルの PO には難しい。役割名通り、オーナーシップを持っていないとこの辺りのことを考えられない。
兆候
- 割り込みを追加する際にチームとしてルールや規律を設けていない
- 開発者は割り込みを受け入れることで、ゴール達成できなくてもしょうがなくない？というコミットメント放棄がバーターとして許されるという甘い罠にハマっているので、スプリントゴールの達成がされない
- スクラムマスターは見て見ぬふりをしている
対処
- スクラムマスターを変える
- 規律として割り込みをどうするのか、チームで話してワーキングアグリーメントを定める

こんな状況
- スプリントのスコープがコロコロ変わる
- ドメインについてあまり理解していない PO や開発者で構成されている。受託みたいな。
兆候
- スプリントのいつでも割り込みがある
- PO はドメインについてあまり詳しくない
- スプリントレビューで初めてトンチンカンなもの作ってることに気づくことが多い
対処方法
- ドメインを理解している PO に交代する
- PO がドメインを理解する訓練をする
- チームが、言われたものを作ると言う態度から、なぜ作る必要があるのか、を問うように訓練する
  - レンガ職人の話と同じ
- 視点をソフトウェアを作る、システムを作る、と言う観点から、サービスや業務を作る、といった観点に引き上げる。
  - ユーザーストーリー形式の、”〜〜なぜならば、” の項を明確に書くようにする。ないと何が困るのか、誰が困るのかを理解する
  - 肩越しの視線：ユーザーが使っている場面を見に行く、とかもできるならやる
  - プロダクトバックログアイテムの向こう側にいる実際の人を見るきっかけを作る。映像で実感する。