瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

リードタイム短縮のために、Readyになるまでの時間短縮の試み

スクラムコーチをしているようなマスタークラスの人と話すとよく話題になるのが下の話です。
未熟なスクラムチームはベロシティを「生産性」と勘違いしてとにかくその数字を伸ばそうとする
(実際には使われない機能が大量に作られるだけで意味がない)
熟練したスクラムチームはリードタイムを重視してとにかくその時間を短縮しようとする。
思い当たる節はないでしょうか?

さて、我がチームにおいてもリードタイム短縮は目下の急務でした。
生産性、というよりは機動性の高さに直結するからです。
リードタイムを妨げているのはタスクを ready に持って行くまでの「事前作業タスク」と当時呼称されていたタスクでした。
当時の計測で全体の9.7%の工数を食いつぶしていました。
機能追加に費やしていた工数が54%程度だったことを考えると20%弱あったことになります。
いったんreadyにさえすれば、高速でタスクは消化されていきます。
それはここまでで達成されていました。
問題はreadyにするまでのタスクの消化です。
そこで3スプリント使って「なぜreadyにならないか」「なぜこのタスクができたか」「回避方法はあるか」「どうすれば次のタスクからはこの作業をせずに済むか「どうすればこのタスクを生まずに済むか」を調べながら優先して消化することにしました。
当然のごとく当初は「事前作業タスク」の消化スピードが半減しましたし全体の消化スピードも低下しましたが、もはややむをえない、と判断していました。

3スプリント後には以下の効能が得られました。
・在庫だった「事前準備タスク」の87%減
・「事前準備タスク」の再生産ペースの54%減
・「事前準備タスク」所要工数の72%減
おそるべくして減っています。

なぜ俺たちは作業スピードを落とすこいつらを生んでしまったか?を意識したところ、「じゃあ生まないように作業しよう」という意識が浸透しました。
やはりメンバーの意識に染み込ませ、ボトムアップで進めた方が効果があるようです。
一部再生産やむなし、せめて消化スピードをあげようという方向で対応した部分もあるのですが、それはやむえないところです。
収穫逓減の法則に従っているので「撲滅」「根絶」に拘る意味がありません。

リードタイムそのものには6%程度の貢献と判断されましたが、開発ストレスが減ったことでそこは良しとされました。
また副産物として、事前準備タスクの根源は「歴史的経緯」「過去の負債」「惰性の不合理」にあったため、それらが除去されたことで一気に機動性は上がりました。
「生産性」や「スピード感」に拘ると積み上がっていく代物だったので、このタイミングで棚卸し&処分できたので良しとしています。