第22章 より効果的なアジャイル:ポートフォリオマネジメント
WSJFは、各フィーチャーまたはストーリーに関連している遅延コスト(Cost of Delay:CoD)を突き止めることから始まる。
ユーザー部門から出てくる数字(〇〇円経費が削減できます/〇〇円売上が上がりますみたいなの)を提示されるが、そこの精度が高くないと基準にしていいのか不安が…シーケンシャル開発でやっていることもあり、1個あたりが大きくなりがちなので外れてるとダメージが大きいのではと思ってしまう。
WSJFを大規模な見積もりでもう少し押し出しても良いなっておもってきた。(計画づくりに熱中する人がいないか心配になるけど。
図22-3はふつうにシーケンシャル開発のことか。。。
リーンの合言葉は「始めるのをやめよう!終わらせることを始めよう!」である。
めっちゃわかる。。。
(外部的な制約があり進行中の案件があっても)〇〇までにこれやってほしいんだよね…ってくることが多々あり…じゃあ今やってるのやめていいです?て聞くといやそれは続けてほしくて…ってなることが。シーケンシャル開発でやってるが故に途中でやめるとか見直すというのが難しくなっているイメージ。これを意識して優先順位付してくれると助かるなぁと
■推奨 リーダーシップ アクション
検査
あなたの組織で遅延コスト(CoD)を計算するのに十分なフィーチャー、要求、プロジェクトの大きさがどれくらいかをよく考えてみる。CoDとWSJFを利用すれば、チームのフィーチャーレベルのプランニングが改善されるだろうか。それとも、プロジェクトポートフォリオレベルのプランニングが改善されるだけだろうか。
最初の正式リリースレベルだと半年から1年くらいが多い気はする。うまくいけばチームのフィーチャーレベルのプランニングまで効果がでそうな気はするが、見積もりの確度をあげるための日々のトラッキングをスクラムマスターがサポートしたり、プロダクトオーナーが(各レベルの)バックログリファインメントに注力できる状態をつくるという当たり前のレベルのスクラムの実践が非常に重要だなーってあらためて感じた。
今の大きさが数か月や年単位の内容もあったりと、大きい単位でやってるのでもっと細かくして考えたほうが…と思う。が自分たちのリソースに対して依頼の数が多いので、終わったら次をいつやってもらえるかわからないので依頼側も大きくせざるをえない感じで悪循環になっているような気が…
CoDとWSJFを使って現在のプロジェクトポートフォリオを調べる。ビジネス側からCoDの情報を入手し、チームから開発期間を入手する。現在の優先順位での総遅延コストを計算する。WSJFに基づくポートフォリオの順序を割り出した後、ポートフォリオをその順序で並べ替えた場合の総遅延コストを計算する。
これはたしかにやってみてもいいかもしれない。コンサルティング業務でも必要だなーって思った。(やれている領域とやれていない領域がありそう)
こういうシンプルな指標でやったほうが納得感がある気はします。(イベント毎とかで優先度を変えようとされたりするので)
■適応
WSJF を 使っ て プロジェクト ポートフォリオ を 並べ 替える。
やってみたいプロジェクトがおもいつくので、近いうちに実践してみる
エピック などのより 細かい 単位 の アイテム に WSJF の アプローチ を 適用 する こと を 検討 する。
エピックレベルだったら十分にできそうな気がしていて、数少ないプロジェクトではフィーチャーレベルでもできそうな気がする。(プロダクト構想段階でなおかつ十分にプロダクトを小さくたもてそうな場合)