海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

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

前回の続き

bbbbashiko.hatenadiary.com


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

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

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


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

500m先を右に行こうとか見えてない先のことまで考えて運転しても途中でハンドルを切り直す羽目になる。

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

規律の乱れ

規律が乱れると地獄が始まる

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

お前の目は節穴か

視力が悪い人は視界が良くても速く走れない

  • こんな状況
    • スプリントのスコープがコロコロ変わる
    • ドメインについてあまり理解していない PO や開発者で構成されている。受託みたいな。
  • 兆候
    • スプリントのいつでも割り込みがある
    • PO はドメインについてあまり詳しくない
    • スプリントレビューで初めてトンチンカンなもの作ってることに気づくことが多い
  • 対処方法
    • ドメインを理解している PO に交代する
    • PO がドメインを理解する訓練をする
    • チームが、言われたものを作ると言う態度から、なぜ作る必要があるのか、を問うように訓練する

    • 視点をソフトウェアを作る、システムを作る、と言う観点から、サービスや業務を作る、といった観点に引き上げる。

      • ユーザーストーリー形式の、”〜〜なぜならば、” の項を明確に書くようにする。ないと何が困るのか、誰が困るのかを理解する
      • 肩越しの視線:ユーザーが使っている場面を見に行く、とかもできるならやる
      • プロダクトバックログアイテムの向こう側にいる実際の人を見るきっかけを作る。映像で実感する。

結局のところ、ドメインの不確実性のためにアジャイルな構えが必要というのは、1だったり3だったりで複合的、というか、相対的なものなのかもしれない。

同じシステムを新人や未経験のチームに任せるということは、相対的にそのドメインがチームから見て不確実性が上がっているように見える、のかもしれない。知らんけど。